Перейти к содержимому

Производительность и надежность

Редактировал(а) Alexandr Fokin 2026/07/27 03:11
 Примеры
 
Технологические решения

Полная целостность.

TriggerEvent sql TransactionalInbox
+ TriggerEvent sql TransactionalOutbox
+ sql store.

Полная ACID целостность (отсутствие проблем), но меньшая пропускная способность из-за ограничений производительности sql БД. 
Меньшие гарантии

Использование меньших гарантий требует дополнительных проверок:

  • Дополнительные проверки условия -> обнаружения инцидента ложного сигнала.
    В случае обнаружения инцидента:
    • Попытка пересчитать временный счетчик (количество необработанных значений не менее N).
    • Реагирование на каждый поступающий сигнал (возможно с задержкой после срабатывания).
  • Страхующая проверка завязанная на таймер (периодическая) -> обнаружения инцидента потери сигнала.

Основывается на том, что вероятность исключительных ситуаций не велика.

  
Проблемы и риски при использовании меньших гарантий.
ТипПричинаПример
Потеря данных в хранилище.Падение ненадежного (например InMemory) хранилища.Потеря счетчика сигналов.
Потеря сигнала.Отправка TriggerEvent без sql TransactionalOutbox.
  • TriggerEvent не был отправлен (no gracefull shutdown)

-> Счетчик не был изменен.
-> Зависание обработки.

Ложный или дублирующий сигнал.Обработка TriggerEvent без sql TransactionalInbox.

TriggerEvent был обработан более одного раза (Гарантии доставки).

  • Отвал и переподключение consumer. Транзакция БД закомичена, а сообщение брокера нет.
  • Дублирование сообщений на отправке.
    • Проблемы с сетью (доставка подтверждения отправки).
    • Падение сервиса после публикации сообщения (без фиксации).

-> Счетчик был уменьшен более чем на 1.
-> Ложное, преждевременное срабатывание триггера.

  
Выводы
  • Более производительные решения возможны только с использованием InMemory (NoSQL) хранилища. Что ведет к потере полной целостности и отсутствию полного ACID. При этом корретная обработка возможна (хоть она и будет более долгой).
  • Решение на основа только реляционной БД (SQL) не может гарантировать такой же высокий уровень производительности. Возможно смещение в сторону периодической перепроверки по таймеру (увеличение задержки между завершением работы и реакций на это).