Подскажете по архитектуре системы уведомлений?

Question

[Di Lee]

В рамках веб сайта пишется система уведомлений пользователей по различным каналам (telegram/email/push/sms.. и т д) . Предлагается такой вариант архитектуры. Подскажите пожалуйста слабые стороны

Общая архитектура нотификатора:

1. На каком-либо этапе создается уведомление(-я) в виде добавления записи(-ей) в БД (сущность NotificationMessage)
   
2. CRON раз в 1-5 минут достает из БД все(или часть) уведомлений со статусом "не отправлено"
   и погружает эти уведомления в очередь RabbitMQ
   
3. Консюмер достает из очереди уведомления и отправляет их по различным каналам (в зависимости от настроек пользователей, уведомлений и т д) и проставляет статусы "отправлено" в БД всем отправленным сообщениям
   

Вопросы:

• На сколько надежна/логична такая схема нотификатора?
  
• Какой возможен программный потолок количества отправляемых уведомлений в единицу времени, при такой архитектуре на одном сервере?
  

Comments

[Дмитрий]

А почему на этапе создания уведомления - сразу не класть в очередь? и от 2 этапа избавиться к чертям?

[Di Lee]

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

[Дмитрий]

Di Lee, и зачем? на третьем этапе если отправка не получилась - вы можете вернуть сообщение в очередь если причина временная, можете с задержкой если есть представление о том насколько временная.

[Di Lee]

Дмитрий, понял, спасибо

[Alexpwnz]

Дмитрий, если что то пойдет не так при отправке, сообщение будет потеряно.

P.S.
Архитектура надежная.

[Сергей]

Если есть механизм повторной отправки задачи в очередь, то есть и шанс повторной отправки пользователю, проверяйте актуальное состояние записи в БД перед отправкой.

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

[Дмитрий]

Alexpwnz, не понял? с чего бы это сообщение будет потеряно?

Answer 1

[mayton2019]

При данной схеме тебе база и крон вообще не нужны. Пиши сразу в Rabbit. Если consumer обладает логикой неуспеха обработки - то пускай кидает необработанное вообщение в специальную мусорку (Dead-Letter-Quee) для анализа ошибок впоследствии.

Какой возможен программный потолок количества отправляемых уведомлений в единицу времени, при такой архитектуре на одном сервере?

На этот вопрос невозможно ответить. Цифры могут отличаться в разы в зависимости от выбранного железа. Но современные MQ настолько быстрые что с большей вероятностью твой софт не сможет их загрузить событями.
Узким местом в такой системе будет скорее всего твой софт.

Comments

[Di Lee]

Нашел информацию по сравнению производительности RabbitMQ и Kafka.
RabbitMQ - 30-40 тыс сообщений / сек, Kafka - 2 млн сообщений / сек
Понятно, что это относительные показатели, характеризующие конкретный тест. Но для общего понимания думаю этой информации достаточно.

[mayton2019]

Di Lee, у Кафки есть 3 разных режима подтверждения сообщений. Это в некторой степени регуляторы скорости. Но мы можем рассуждать о них как о гарантах надежности а скорость здесь просто побочный эффект. Кроме того Кафка при отсуствии перебалансировок может достигать бесконечной скорости если ты используешь partitioning. Это архитектурный вопрос и саму возможность партишенинга надо обсуждать с разработчиками продюсеров и консюмеров. У кафки свой собсвтенный ни с чем не совместимый сетевой протокол. Это недостаток. А RabbitMQ использует AMQP. Это стандарт обмена сообщений в банковской среде. Старый. Консервативный. Его любят за это. Если смотреть широко - и искать совместимости то кролик будет предпочтительнее.