Решения для обработки миллионов синхронизированных (запланированных) сообщений?

Question

Я оцениваю возможные решения для обработки большого количества сообщений в очереди, которые должны быть доставлены работникам в определенную дату и время. Результатом их выполнения в основном являются обновления хранимых данных, и они могут быть, а могут и не быть инициированы действием пользователя.

Например, подумайте, что бы вы реализовали на гипотетическом крупномасштабном игровом сервере StarCraft для хранения и выполнения действий пользователя, таких как модернизация здания, вывод из строя солдата, все из которых необходимо применить к состоянию игры. через несколько секунд или минут после того, как игрок их инициирует.

Проблема в том, что я не могу найти правильный термин для названия этой проблемной области. Есть несколько похожих, но разных:

cron / задача / планировщик заданий

• Содержимое очереди не динамическое , оно предопределено.
• Каждое задание запланировано .

очередь сообщений

• Содержимое очереди динамическое .
• Каждое задание предназначено для выполнения немедленно .

???

• Содержимое очереди динамическое .
• Каждое задание запланировано .

Если есть очереди сообщений, которые допускают условную доставку сообщений, это может быть и так.

Резюме:

1. Как называются такие технологии?
2. Какие есть решения?

Answer 1

Вы пробовали смотреть на очереди push-сообщений Iron.io?Содержимое очереди может быть любым, и вы указываете веб-крючок, куда будут отправляться сообщения.Вы также можете установить задержку для каждого из сообщений.

Веб-крючок статичен, хотя для каждой очереди и задержки не всегда точно вовремя (может быть до минуты).Если время важнее или важна возможность предоставления другого webhook для каждого сообщения, попробуйте посмотреть на boomerang.io.

Говорят, что они довольно точны по времени, вы можете предоставить задержку или метку времени unix для возврата веб-крючка, и это для каждого сообщения.Похоже, что любой из них может работать для вас.

Answer 2

Это звучит как тривиальная приоритетная очередь на поверхности. Приоритетом в этом случае является время завершения, и вы проверяете начало очереди, чтобы увидеть, когда наступит следующее событие. Практически каждый язык имеет очередь с приоритетами или что-то, что можно легко использовать как единое целое, поэтому я не уверен, в чем здесь проблема.

Вас беспокоит масштабируемость, когда речь идет о миллионах сообщений? Очевидно, что «миллионы» - это бессмысленный термин - если это миллионы в день, это тривиальная проблема. Если это миллионы в секунду, то вы можете просто масштабировать по горизонтали, разделяя очередь на несколько процессов. (И преимущество такой системы очередей в том, что это распараллеливание действительно просто.)

Держу пари, что при реализации крупномасштабного игрового сервера в реальном времени вы столкнетесь с проблемами в сети задолго до того, как начнете сталкиваться с проблемами в очереди сообщений.

Answer 3

Для StarCraft я бы использовал сервер Red Dwarf .

Для приложения Java EE я бы использовал Кварцевый планировщик .

Answer 4

Мне кажется, что решение на основе очередей будет лучше в этом случае по ряду причин:

• Управление.Большинство решений организации очередей предоставляют поддержку для проверки содержимого очередей, что облегчает отладку, облегчает выполнение действий при превышении определенного порога, ...
• Производительность.Вы можете разделить рабочую нагрузку, используя несколько процессов постановки / снятия с очереди (дает вам возможность масштабирования).
• Приоритизация.Большинство очередей поддерживают приоритезацию сообщений (вероятно, не все сообщения одинаково важны).
• ...

Остальной проблемой является немедленная доставка сообщений в очередь.У вас есть два способа решить эту проблему: либо задержать постановку в очередь сообщений, либо задержать выполнение отложенных сообщений.Я пошел бы с первым подходом, отложенным помещением в очередь.

У сообщения тогда есть два свойства: (содержание, задержка).Вы передаете сообщение компоненту в вашей системе, который ставит сообщение в очередь в соответствующее время.

Я не уверен, какой язык программирования вы используете, но среда MS .NET 4 поддерживает такой сценарий (отложено выполнение заданий).