Как подойти к синхронизации сервисов wcf?

Я внедрил службу wcf, и теперь мой клиент хочет, чтобы у нее было три копии, работающие независимо на разных машинах. Подход «хозяин-раб». Мне нужно найти решение, которое позволит поведение:

первая созданная служба «спрашивает» две другие «живы ли они?» - если нет, то он становится мастером и именно он активен в сети. Двое других, однажды созданные, видят, что хозяин уже жив, поэтому они становятся рабами и начинают спать. Должны быть какие-то механизмы, чтобы периодически проверять, не умер ли мастер, и если да, то выбирает следующую копию, которая жива, чтобы стать мастером (пока она не станет мертвой соответственно).

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

Благодарность


wcf synchronization
person Łukasz Podolak    schedule 19.02.2009    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я бы предложил посмотреть одноранговый канал WCF (System.Net.PeerToPeer), чтобы каждый узел знал о других узлах. Вот ссылка, которая предлагает достойное введение.

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

Наконец, что касается проверки того, жив ли мастер, я бы предложил использовать основанный на событиях механизм, описанный здесь. Мастер может отправлять периодические события состояния и работоспособности, на которые будут регистрироваться другие узлы. Я бы поместил блок try/catch/finally в точку входа кода, чтобы в случае сбоя мастера он мог опубликовать одно последнее событие MasterClosing, чтобы ведомые устройства знали, что оно уходит. Это не учитывает системный сбой, например, сбой питания и т. д. Чтобы справиться с этим, предоставьте тайм-аут в ведомых устройствах, чтобы по истечении времени ожидания ведомые устройства могли запросить ведущее устройство, чтобы узнать, существует ли оно. Если нет, подчиненные могут договориться между собой, используя ваш детерминированный алгоритм, о том, кто должен быть следующим хозяином.

person Matt Davis    schedule 19.02.2009