Нарушение шаблона - как ведущие и подчиненные узлы хранятся в синхронизации?

Question

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

На репликаторе мастер-узла записывает события в БД (хотя все мы можем думать более эффективные механизмы, чем писать в db- это не очень важно постановка задачи). Получатель подчиненного узла считывает из БД и помещает события в кольцевой буфер подчиненного узла.

Выходные события подчиненного узла игнорируются.

Теперь есть вероятность, что процессор бизнес-логики главного узла будет медленнее, чем бизнес-логический процессор подчиненного узла. Для примера BL основного узла может быть в слоте 102, где в качестве подчиненного узла может быть значение 106. (Это может произойти из-за того, что репликатор считывает событие из кольцевого буфера перед процессором бизнес-логики).

В таком случае, если главный узел терпит неудачу, и подчиненный узел теперь становится главным узлом, некоторые важные события могут быть упущены внешними системами. Это может произойти, потому что Node 2, когда он работал как подчиненный узел, проигнорировал его вывод.

Martin Fowler утверждает, что задача репликатора заключается в том, чтобы синхронизировать узлы: «Раньше я упоминал, что LMAX запускает несколько копий своей системы в кластере, чтобы поддерживать быстрый переход на другой ресурс. sync "

Но я не уверен, как он может синхронизировать бизнес-логику процессора? Есть идеи?

Answer 1

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

http://www.infoq.com/presentations/LMAX

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

Answer 2

Если низкая стоимость, чтобы отбросить события, вы можете просто игнорировать ее (?).

В качестве простой реализации у вас может быть выходной прерыватель на первичной оповещении о том, что ведомое устройство завершило отправку пакета. Подумайте об этом как о двухэтапном репликаторе - о том, чтобы воспроизвести событие, и о втором репликаторе, чтобы подтвердить, что событие отправлено.

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

Предположим, что на вашем исходящем канале теряется один пакет или ваша интернет-линия идет вниз? Даже если он успешно отправлен из разрушителя, он все равно может быть потерян. Это зависит от вашего конкретного приложения и требует гораздо больше мысли, чем может пойти здесь о том, какие сценарии вы можете терпеть.