Проблема в том, что если брокер M не работает?
Если брокер не работает, A и B не могут использовать его для связи.
То, что A и B должны делать в этом сценарии, будет очень сильно зависеть от деталей вашего конкретного приложения / варианта использования.
Есть ли полезная работа, которую они могут выполнять в этом сценарии?
Если нет, то они могли бы просто перестать пытаться обрабатывать какие-либо работы / транзакции на данный момент, и вместо этого просто сидеть и ждать, пока М вернется.Рекомендуется, чтобы они периодически выполняли пинг / запросы M (чтобы узнать, вернулся ли он), в то время как в этом состоянии это хорошая идея.
Если они могут сделать что-то полезное в этом сценарии, вы можете заставить их продолжать работатьв каком-то «автономном режиме» кэширование их результатов локально в ожидании повторного появления М в какой-то момент в будущем.Конечно, это может стать проблематичным, особенно если M не возвращается в течение долгого времени - например,
- , что если набор кэшированных локальных результатов становится неоправданно большим, таким образом, A / B работаетне хватает места для его хранения?
- Или что, если A и B кэшируют локальные результаты, которые будут применяться к одной и той же структуре (структурам) данных в пределах M, так что, когда M возвращается в оперативный режим, некоторые результаты A перезаписывают B (или наоборот)в зависимости от того, в каком порядке они переподключаются)?(Это аналогично тому, с чем сталкиваются серверы контроля исходного кода после того, как несколько разработчиков работают в автономном режиме, внося изменения в одни и те же строки в одном и том же файле, а затем оба возвращаются в оперативный режим и хотятзафиксировать свои изменения в этом файле. Он может быть немного сложным, и не всегда существует очевидный «правильный» способ разрешения конфликтов)
- Наконец, что если это было что-то, сказанное А или В, которое вызвало сбой Мна первом месте?В этом случае повторная загрузка тех же запросов в M после его возвращения в оперативный режим может привести к его аварийному завершению и т. Д. В бесконечном цикле, что делает службу постоянно недоступной.(В этом случае, конечно, правильным решением будет отладка M)
Другой подход может состоять в том, чтобы попытаться избежать проблемы с помощью нескольких избыточных посредников (например, M1, M2, M3,....) такой, что пока хотя бы один из них еще доступен, продуктивная работа может продолжаться.Или, возможно, разрешить А и В общаться друг с другом напрямую, а не через посредника.
Что касается того, лучше ли обрабатывать подобные вещи потоками или реактивным программированием, то это вопрос личных предпочтений - личноЯ предпочитаю реактивное программирование, потому что стиль с несколькими потоками обычно означает операции blocking-RPC, а поток, который блокируется внутри операции блокировки, является замороженным / беспомощным потоком до тех пор, пока удаленная сторона не ответит (например, если для ответа M требуется 2 минутыв ответ на запрос RPC вызов RPC A для M не может вернуться в течение 2 минут, что означает, что вызывающий поток вообще ничего не может сделать в течение 2 минут).При реактивном подходе поток А мог также выполнять другие действия в течение этого периода (например, пинговать M, чтобы убедиться, что все в порядке, или связываться с резервным брокером, или что-то еще) в течение этого 2-минутного периода, если он этого хотел.