Реализация мастер-раб
Работает на Ubuntu. Программа на C ++.
У меня есть 2 процесса, выполняющихся на разных хостах, когда один является главным, а другой — ведомым (между ними нет приоритета, только один запрос на обработку).
Только один процесс может быть основным и обработать запрос.
Два процесса всегда работают, и в случае их сбоя есть сторожевая собака, которая перезапускает их.
Хосты соединены сетевым кабелем.
Мой план состоит в том, чтобы просить поддерживать жизнь от одного к другому, и в случае, если раб перестает получать поддержку от хозяина, он должен изменить свое состояние на хозяина.
Когда мастер запускается снова, сначала нужно дождаться, чтобы он оставался в живых, а в случае, если он не получил его, назначьте роль мастера. если получить его, установите роль в качестве раба.
Я буду рад узнать ваше мнение о:
как помешать обоим быть мастером одновременно? Это мое главное беспокойство. При запуске и при сбое подключения, как вы предотвращаете 2 мастера одновременно?
Считаете ли вы, что будет лучше запросить сохранить или отправить сохранить? (по моему мнению, лучше просить сохранить в живых, чем толкать)
любые другие полезные советы и подводные камни будут более чем приветствоваться.
Решение
Я сделал так, чтобы каждый процесс порождал поток пульса, который раз в секунду отправляет пакет UDP, и прослушивает входящие пакеты UDP от другого процесса. Если поток пульса не получает никаких пакетов UDP от другого процесса в течение определенного периода времени (например, 5 секунд), он предполагает, что другой процесс не работает, и уведомляет родительский поток, что он должен стать мастером сейчас.
Причина, по которой отправка / прослушивание сердцебиения выполняется в выделенном потоке, заключается в том, что если основной поток занят длительными вычислениями, это не приведет к временной отправке UDP-пакетов сердцебиения. Таким образом, алгоритмы в основном потоке не должны быть в режиме реального времени, чтобы избежать запуска ложных отказов.
Здесь есть еще одна проблема, о которой стоит подумать … что произойдет, если проблема с сетью временно прервет связь между двумя хостами? (например, какой-то джокер или тестер QA отключает кабель Ethernet на 1 минуту, а затем снова подключает его). В этом случае оба процесса прекратят прием пакетов UDP от другого процесса, поэтому оба процесса будут думать, что другой процесс завершен, и оба станут основным процессом. Затем при повторном подключении сетевого кабеля у вас одновременно запускаются два главных процесса, а это не то, что вам нужно. Таким образом, вам нужно каким-то образом для двух главных процессов решить, какой из двух должен перейти обратно в статус раба, чтобы удовлетворить Принцип Горца («может быть только один!»). Это может быть так же просто, как «хост с наименьшим IP-адресом должен оставаться главным», или вы можете иметь каждый пакет контрольного сигнала, содержащий время безотказной работы отправляющего процесса, а хост с большим временем работы должен оставаться главным, или т. Д.
Другие решения
Типичным способом решения этой проблемы является проведение выборов. Каждый в системе делится данными, которые они будут использовать в качестве входных данных для алгоритма, чтобы каждый мог прийти к одному и тому же выводу.
Например: все равноправные узлы (оба) отправляют друг другу какой-то уникальный идентификатор (MAC-адрес или pid или время начала высокоточного процесса, например). Затем каждый пир использует одно и то же сравнение, чтобы определить победителя (например, наибольшее значение). Затем они информируют друг друга о результатах.
Информацию о проблемах с временными сбоями подключения см. В Византийские генералы.
Смотрите также: