Ваша интуиция верна насчет объединения репликации и ведения журнала в компонент Raft. Но протокол Raft точно определяет, когда что-то нужно хранить на диске.

Вот два разных взгляда на это.

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

Лично я бы сделал первый, потому что он разделяет задачи на разные процессы. Если бы я реализовывал Raft для себя, я бы взял первую половину второго сценария и поместил его в отдельный процесс.

Внешняя репликация плота

В котором Raft реализуется внешним процессом.

Компонент репликации передает внешний процесс репликации на аутсорсинг. Через какое-то время Raft отвечает компоненту репликации, что он, по сути, реплицируется. Компонент репликации обновляет элементы в кольцевом буфере и перемещает опубликованный курсор вперед. Бизнес-логика видит опубликованный курсор (через waitFor) и использует только что реплицированные данные.

В этом сценарии компонент репликации, вероятно, имеет много событий в процессе обработки, поэтому его курсор чтения намного опережает курсор, который он публикует в бизнес-логике.

В этом сценарии нет необходимости в компоненте ведение журнала, потому что внешняя система raft выполняет ведение журнала за вас.

Обратите внимание, репликация может быть самым медленным компонентом системы!

Интегрированная репликация плота

В котором плот реализован в том же процессе, что и "Реальная бизнес-логика".

С точки зрения Raft, репликация является бизнес-логикой. На самом деле у вас есть несколько уровней бизнес-логики или, что то же самое, несколько этапов бизнес-логики.

Я собираюсь использовать два входных разрушителя и два выходных разрушителя для этого, чтобы подчеркнуть отдельную бизнес-логику. Вы можете комбинировать, разделять или переставлять по своему усмотрению. Или контент вашего профилировщика.

Первый этап, как я уже упоминал, — это репликация Raft. События клиента поступают в прерыватель ввода репликации. Логика Raft собирает его, возможно, в пакетах, и отправляет последователям на прерывателе вывода репликации. Все сообщения Raft также попадают в Replication Input Disruptor. Логика Raft также улавливает их и отправляет соответствующие ответы соответствующим Последователям/Мастерам на Разрушителе вывода репликации).

Компонент журнала зависает от входного кольцевого буфера; он должен обрабатывать только определенные типы сообщений, как это продиктовано Raft. Вероятно, это будет самая медленная часть системы.

Когда данные считаются реплицированными, они перемещаются на второй этап с помощью прерывателя ввода «Real Business Logic». Там он обрабатывается, отправляется в Client Outbound Disruptor, а затем отправляется одному из ваших миллионов довольных платящих клиентов.