В системе, управляемой событиями, какова наилучшая практика в отношении количества событий и размера/атомарности?
Если оставить в стороне термин «лучшая практика», есть несколько соображений.
Во-первых, когда дело доходит до обмена сообщениями, забудьте о любых ваших идеях о «гарантированной» доставке и т. д. Очень часто сообщения «теряются» или неправильно обрабатываются в таких системах. Почти каждый раз, когда я работал с кем-то, кто плохо знаком с обменом сообщениями, они не понимали, что получение сообщения из очереди — небезопасная операция. То есть, в отличие от чтения строки из БД, чтение сообщения из очереди/темы изменяет состояние очереди/темы, по крайней мере, с точки зрения потребителей. Если вы не сможете успешно обработать сообщение, но зафиксируете чтение, это сообщение будет «исчезло». Это очень часто бывает причиной ошибок.
По этой причине я очень осторожно отношусь к использованию очередей в качестве основного средства отслеживания работы, которую необходимо выполнить, и использование их в качестве основного механизма хранения этой работы — просто ужасная идея для всего, что имеет значение.
Тот факт, что вы используете БД для хранения, означает, что последнее здесь не имеет значения. Но первое вызывает беспокойство. Вы должны отслеживать статус обработки абзаца в БД, если вы этого еще не делаете.
Это подводит меня к вопросу о дизайне вашей БД. Есть ли причина, по которой вы не храните абзацы отдельно в БД? То есть, почему бы не разделить абзацы в БД и не хранить их отдельными строками? Это позволит вам независимо отслеживать их статус и в случае сбоя позволит вам повторно обработать только ошибочные строки. Это также значительно упрощает отслеживание обработки в распределенном дизайне.
И это подводит нас к следующему пункту: для чего тогда хорош обмен сообщениями? Основная ценность обмена сообщениями в распространенных современных системах (64-битных) заключается в простоте очень гибкого распределения работы. Они хорошо работают с моделями вытягивания, где вы можете увеличивать и уменьшать количество рабочих по мере необходимости, чтобы не отставать от нагрузки. Они также хорошо справляются со скачками нагрузки, так что могут принять большую нагрузку, которую вы можете обрабатывать в течение коротких периодов времени без сбоев.
Я бы порекомендовал разделить абзацы в БД, что выведет вас из зоны LOB на основе вашего описания размера абзаца. Тогда я бы, вероятно, опубликовал и событие для каждого абзаца. Содержит ли событие содержимое абзаца или просто ссылку на то, где его можно получить, немного нюансов. С одной стороны, возможно, что чтение из очереди связано с такими же системными и сетевыми издержками, как и получение из БД. Предположение, что очередь «приближает» содержимое сообщения к клиенту, не обязательно верно, но что-то в этом может быть в реализации с несколькими регионами. Если у вас большое количество рабочих процессов, у вас могут возникнуть конфликты при чтении из БД, что укажет на размещение контента прямо в очереди. Вы должны немного прочитать о том, как SQS управляет сообщениями и распределяет их, а также понимать, что может обрабатывать ваша БД. Затем выполните профилирование и отслеживайте производительность, как только у вас будет рабочее решение.
Прикрепляю к посту несколько видео по теме: