Нужно ли архитектуре источника событий использовать очереди сообщений? - PullRequest
Новая
       61

Нужно ли архитектуре источника событий использовать очереди сообщений?

0 голосов
/ 30 апреля 2019

Рассмотрим этот простой пример.Скажем, у вас есть таблица событий TBL_EVENTS с фф.столбцы:

  • eventId (int)
  • dateTime (datetime)
  • eventName (строка)
  • данные (json)

Теперь фф.произошло событие:

$UserService->registerUser();

Событие USER_REGISTERED теперь сохраняется в TBL_EVENTS с помощью ff.data: 

eventId: 1
dateTime: 2019-04-30 00:00:00
eventName: USER_REGISTERED
data: {"userId":1, "name":"foo"}

1-й вопрос: делать прослушиватели событий непосредственно или каждые 10 секунд запрашивать / прослушивать TBL_EVENTS или очередь сообщений необходима, чтобы не "бомбардировать" TBL_EVENTS с запросами на опрос?

Например, $UserService->registerUser(); помещает "событие" в отдельную очередь сообщений (например, AWS SQS) в дополнение к TBL_EVENTS, затем $UserService->listener(); опросов SQS вместо TBL_EVENTS?Или прямой опрос к TBL_EVENTS используется в приложениях реального мира?

2-й вопрос: Когда $UserService->listener(); получает событие USER_REGISTERED, создается ли оно только одно новоепользователь в отдельную таблицу TBL_USERS или он воспроизводит все события с 0 до настоящего времени, тем самым создавая всех пользователей в TBL_USERS каждый раз?

1 Ответ

0 голосов
/ 30 апреля 2019

Для аналогичного варианта использования в моем проекте реализован следующий подход -

[1] СИСТЕМА ИСТОЧНИКА СОБЫТИЙ - вызывает -> ПРОКСИ СОБЫТИЯ -- записывает запись -> ТАБЛИЦА ЭТАП СОБЫТИЙ

[2] ТАБЛИЦА ЭТАП СОБЫТИЙ - триггеры -> ПРОЦЕДУРА БД - пишет -> QUEUE EVENT

[3] HANDLER EVENT (S) - polls -> QUEUE EVENT

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

Теперь, что касается вашего Вопрос 2 ;Я не понимаю вашу необходимость создавать пользователей с нуля всегда.Тем не менее, если это требуется по какой-либо причине, то при вышеупомянутом подходе вам потребуется другая процедура БД (в точке № 2), которая будет выполнять итерацию существующих строк таблицы и вызывать существующую процедуру, которая записывает в очередь событий..

Другой альтернативный подход, который можно рассмотреть здесь, - это запись в БД и параллельная обработка событий -

[1] СИСТЕМА ИСТОЧНИКА СОБЫТИЙ - трансляция по -> КАНАЛ СОБЫТИЙ

[2] ПРОЦЕДУРА БД - прослушивание -> КАНАЛ СОБЫТИЙ

[3] DB PROCEDURE - пишет в -> USER TABLE

[4] EVENT CONTROLLER - прослушивает -> КАНАЛ СОБЫТИЙ

[5] КОНТРОЛЛЕР СОБЫТИЙ - вызывает -> УПРАВЛЕНИЕ СОБЫТИЯМИ (S)

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

...