Низкая задержка, крупномасштабная организация очередей сообщений
Я прохожу что-то вроде переосмысления крупномасштабных многопользовательских игр в возрасте приложений Facebook и облачных вычислений.
Предположим, что я должен был создать что-то сверху существующих открытых протоколов, и я хочу служить 1 000 000 одновременных игроков, только определить объем проблемы.
Предположим, что у каждого плеера есть очередь входящего сообщения (для чата и этажерки), и в среднем еще одна очередь входящего сообщения (гильдии, зоны, экземпляры, аукцион...), таким образом, у нас есть 2 000 000 очередей. Игрок будет слушать 1-10 очередей за один раз. У каждой очереди будет в среднем, возможно, 1 сообщение в секунду, но у определенных очередей будет намного более высокий уровень, и более высокое количество слушателей (скажите, "очередь" местоположения объекта для экземпляра уровня). Давайте примем не больше, чем 100 миллисекунд системной задержки организации очередей, которая хорошо для мягко ориентированных на действие игр (но не игр как Quake или Нереальный Турнир).
От других систем я знаю, что обслуживание 10 000 пользователей на сингле 1U или блейд-поле является разумным ожиданием (предполагающий, что нет ничего иного дорогого продолжения, как моделирование физики или этажерка).
Так, с перекрестной кластерной системой, где клиенты соединяются со шлюзами соединения, которые в свою очередь соединяются с серверами очереди сообщений, мы получили бы 10 000 пользователей на шлюз с 100 машинами шлюза и 20 000 очередей сообщений на сервер очереди с 100 машинами очереди. Снова, только для общего обзора. Количество соединений на каждой машине MQ было бы крошечным: приблизительно 100, чтобы говорить с каждым из шлюзов. Количество соединений на шлюзах было бы намного выше: 10,100 для клиентов + соединения со всеми серверами очереди. (Вдобавок к этому добавьте некоторые соединения для игровых серверов моделирования мира или этажерки, но я пытаюсь разделить это на данный момент),
Если бы я не хотел создавать это с нуля, то я должен был бы использовать некоторый обмен сообщениями и/или организацию очередей инфраструктуры, которая существует. Эти два открытых протокола, которые я могу найти, являются AMQP и XMPP. Надлежащее использование XMPP немного больше похоже на то, в чем нуждалась бы эта игровая система, но издержки довольно примечательны (XML, плюс подробные данные присутствия, плюс различные другие каналы, которые должны быть основаны на вершине). Фактическая модель данных AMQP ближе к тому, что я описываю выше, но все пользователи, кажется, являются крупными, корпорации типа предприятия, и рабочие нагрузки, кажется, связанный рабочий процесс, не игровое связанное обновление в реальном времени.
У кого-либо есть дневной опыт с этими технологиями или реализации этого, которые можно совместно использовать?
5 ответов
@MSalters
Re 'очередь сообщений':
Операция RabbitMQ по умолчанию - это именно то, что вы описываете: переходный pubsub. Но с TCP вместо UDP.
Если вам нужна гарантированная конечная доставка и другие функции сохранения и восстановления, то вы МОЖЕТЕ получить и это - это вариант. В этом весь смысл RabbitMQ и AMQP - вы можете иметь множество вариантов поведения с помощью всего лишь одной системы доставки сообщений.
Модель, которую вы описываете, - это поведение DEFAULT, которое является временным, «запустил и забыл» и направляет сообщения куда угодно. получатели. Именно по этой причине люди используют RabbitMQ для обнаружения многоадресной рассылки на EC2. Вы можете получить поведение типа UDP через одноадресный TCP pubsub.
По UDP:
Я не уверен, что UDP будет здесь полезен. Если вы отключите Наглинг, то задержка при передаче одного сообщения RabbitMQ (клиент-брокер-клиент) будет измерена на уровне 250-300 микросекунд. См. Здесь сравнение с задержкой в Windows (которая была немного выше) http://old.nabble.com/High%28er%29-latency-with-1.5.1--p21663105.html
I не могу вспомнить многие многопользовательские игры, в которых требуется задержка в обоих направлениях менее 300 микросекунд. Вы можете получить менее 300 мкс с TCP. Окно TCP на дороже, чем необработанный UDP, но если вы используете UDP для ускорения работы и добавляете настраиваемый менеджер восстановления после потерь или менеджер seqno / ack / Resend, то это может снова замедлить вас. Все зависит от вашего варианта использования. Если вам действительно действительно нужно использовать UDP, ленивые подтверждения и т. Д., Тогда вы можете удалить TCP RabbitMQ и, вероятно, справиться с этим.
Джон, это звучит как идеальный вариант использования AMQP и RabbitMQ.
Я не уверен, почему вы говорите, что все пользователи AMQP - это крупные корпорации корпоративного типа. . Более половины наших клиентов работают в сети, от огромных до крошечных компаний. На основе RabbitMQ было создано множество игр, систем ставок, систем чата, систем типа twitter и инфра облачных вычислений. Есть даже приложения для мобильных телефонов. Рабочие процессы - лишь один из многих вариантов использования.
Мы стараемся отслеживать, что происходит здесь:
http://www.rabbitmq.com/how.html (не забудьте перейти по ссылке списки вариантов использования тоже на del.icio.us!)
Пожалуйста, взгляните. Мы здесь, чтобы помочь.info@rabbitmq.com или напишите мне в твиттере (@monadic).
Мой опыт был с закрытой альтернативой, BizTalk. Самый болезненный урок, который мы усвоили, заключается в том, что эти сложные системы НЕ быстрые. И, как вы поняли из требований к оборудованию, это приводит непосредственно к значительным расходам.
По этой причине даже близко не подходите к XML для основных интерфейсов. Ваш серверный кластер будет анализировать 2 миллиона сообщений в секунду. Это может быть 2-20 ГБ / сек XML! Однако большинство сообщений предназначено для нескольких очередей, в то время как большинство очередей фактически имеют низкий трафик.
Поэтому спроектируйте свою архитектуру так, чтобы было легко начать с серверов очередей COTS, а затем перемещать каждую очередь (тип) на настраиваемый сервер очереди при выявлении узкого места.
Также по тем же причинам не Предполагается, что архитектура очереди сообщений лучше всего удовлетворяет все потребности вашего приложения в общении. Возьмем, к примеру, «местонахождение объекта в экземпляре». Это классический случай, когда вам не нужна гарантированная доставка сообщений. Причина, по которой вам нужно поделиться этой информацией, заключается в том, что она все время меняется. Итак, если сообщение потеряно, вы не хотите тратить время на его восстановление. Вы бы отправили только старое местоположение затронутой сущности. Вместо этого вы хотите отправить текущее местоположение этого объекта. С технологической точки зрения это означает, что вам нужен UDP, а не TCP, и настраиваемый механизм восстановления после потерь.
Причина, по которой вам нужно поделиться этой информацией, заключается в том, что она все время меняется. Итак, если сообщение потеряно, вы не хотите тратить время на его восстановление. Вы бы отправили только старое местоположение затронутой сущности. Вместо этого вы хотите отправить текущее местоположение этого объекта. С технологической точки зрения это означает, что вам нужен UDP, а не TCP, и настраиваемый механизм восстановления после потерь. Причина, по которой вам нужно поделиться этой информацией, заключается в том, что она все время меняется. Итак, если сообщение потеряно, вы не хотите тратить время на его восстановление. Вы отправите только старое местоположение затронутой сущности. Вместо этого вы хотите отправить текущее местоположение этого объекта. С технологической точки зрения это означает, что вам нужен UDP, а не TCP, и настраиваемый механизм восстановления после потерь.FWIW, для случаев, когда промежуточные результаты не важны (например, информация о позиционировании) Qpid имеет "очередь последних значений", которая может доставить абоненту только самое последнее значение
.Я сейчас строю такую систему, вообще-то.
Я провел оценку нескольких MQ, в том числе RabbitMQ, Qpid и ZeroMQ. Латентность и пропускная способность любого из них более чем адекватна для данного типа приложений. Однако плохо то, что время создания очередей составляет полмиллиона и более очередей. Qpid, в частности, разлагается довольно сильно после нескольких тысяч очередей. Чтобы обойти эту проблему, Вам, как правило, придется создавать собственные механизмы маршрутизации (меньшее количество общих очередей, а потребители в этих очередях получают сообщения, которые их не интересуют).
Моя текущая система, вероятно, будет использовать ZeroMQ, но в довольно ограниченном смысле внутри кластера. Соединения от клиентов обрабатываются с помощью пользовательского sim. daemon, который я собрал с помощью libev и является полностью однопоточным (и показывает очень хорошее масштабирование -- он должен быть в состоянии обрабатывать 50,000 соединений на одном ящике без каких-либо проблем -- наш sim. tick rate довольно низок, и нет никакой физики).
XML (и, следовательно, XMPP) очень не подходит для этого, так как вы будете привязывать процессор, обрабатывающий XML, задолго до того, как вы окажетесь привязанным к вводу/выводу, а это не то, что вы хотите. В настоящее время мы используем буферы Google Protocol Buffers, и они, кажется, хорошо подходят для наших конкретных потребностей. Мы также используем TCP для клиентских соединений. У меня в прошлом был опыт использования и UDP, и TCP для этого, и, как указывали другие, у UDP есть некоторое преимущество, но работать с ним немного сложнее.
Надеюсь, когда мы будем чуть ближе к запуску, я смогу поделиться более подробной информацией.