#cloud #message-queue #event-sourcing #nosql
#облако #очередь сообщений #поиск событий #nosql
Вопрос:
В сценарии с источником событий сбойный клиент-потребитель событий должен получать все пропущенные события-сообщения, опубликованные источником, когда он был отключен.
Алгоритм восстановления (при условии, что он правильный) будет следующим:
-
подпишитесь на источник события (подключение 1)
-
запрашивайте сервер (соединение 2) обо всех пропущенных сообщениях («missed-pack») с заданной временной отметки (непосредственно перед сбоем); и применяйте пропущенные события локально
-
начните читать сообщения из подключения по подписке, применяя те, у которых временная метка больше, чем у последнего, примененного из пропущенного пакета. (Здесь мы предполагаем, что все сообщения, опубликованные между подпиской и первым чтением, будут доставлены клиенту. Возможно, некоторые из первых прочитанных сообщений будут последними в пропущенном пакете, отсюда и предостережение).
Какие брокеры (брокеры сообщений, базы данных без sql, …) поддерживают программирование этого процесса восстановления «из коробки», т. Е. без необходимости программирования на стороне сервера (источника событий).
Спасибо.
Ответ №1:
Возможно, то, что вы ищете, — это возможность «догнать подписку». Это полностью поддерживается хранилищем событий Get. Но на самом деле это база данных, но она обладает отличными функциями pub / sub на основе тематических разделов, а также http API.
Чего вы, возможно, еще не знаете, так это того, что вы можете сделать это самостоятельно, просто создайте подписку, управляемую потребителем, где потребитель знает последнюю контрольную точку (никогда не временную метку, что может привести к неприятным проблемам параллелизма), которая была успешно обработана, а не производитель. Таким образом, клиент всегда может возобновить работу с того места, где он остановился.
Надеюсь, это поможет