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

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

Версия 1.4 от Alexandr Fokin на 2026/07/27 02:41
 Примеры
 
Проблемы и риски
ТипПричинаПример
Потеря данных в хранилище.Падение ненадежного (например InMemory) хранилища.Потеря счетчика сигналов (не знаем сколько сигналов осталось получить).
Потеря сигнала.Отправка TriggerEvent без sql TransactionalOutbox.TriggerEvent не был отправлен (no gracefull shutdown) / Счетчик не был изменен
-> Зависание обработки.
Ложный или дублирующий сигнал.Обработка TriggerEvent без sql TransactionalInbox.TriggerEvent был обработан более одного раза (consumer reconnect) / Счетчик был уменьшен более чем на 1
-> Ложное, преждевременное срабатывание триггера.
  
Технологические решения

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

TriggerEvent sql TransactionalInbox
+ TriggerEvent sql TransactionalOutbox
+ sql store.

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

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

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

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

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