Алгоритм Bully - обнаружение сбоя

Question

Описание алгоритма хулигана обычно не распространяется на фактическое обнаружение сбоя.

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

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

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

Может ли кто-нибудь увидеть проблему с этим?

Answer 1

Предположим, что в вашей распределенной системе есть 4 узла A, B, C и D. Предположим, что нынешним лидером является A. Выборы происходят только в том случае, если какой-либо из узлов B, C или D указывает, что координатор A не отвечает. Неисправность лидера A понимается из-за таймаутов сообщения или отказа координатора инициировать рукопожатие. В отличие от вашего алгоритма в стандартном алгоритме хулиганов, выборы проводятся только в случае сбоя координатора или когда вводится новый узел с более высоким идентификатором процесса.

Answer 2

Как правило, выборы лидера начинаются, когда член подозревает, что лидера больше нет, т. Е. После (локального) таймаута. Часто локальный тайм-аут недостаточно, но, кроме того, ожидаемое действие лидера.

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