* Я не эксперт по распределенным системам, но постараюсь ответить на ваш вопрос.
В распределенных системах люди используют базовую модель, которая предполагает некоторые свойства во времени («сколько времени потребуется, чтобы прибыло это сообщение?») И некоторые свойства о типах ошибок («как узлы в протоколе могут делать не то? »).
Существует три основных типа временных моделей, обычно используемых для распределенных систем: синхронная модель, асинхронная модель и частично синхронная модель. Каждая из этих моделей дает некоторые гарантии относительно продолжительности («задержки»), которая может происходить между обменом сообщениями между узлами в данном раунде выполнения протокола. Эта категоризация важна, потому что в распределенной настройке один узел не может различить одноранговый узел, который вышел из строя, и одноранговый узел, который просто требует много времени для ответа.
В синхронной модели существует некоторое максимальное значение («верхняя граница») T для времени между тем, когда узел отправляет сообщение, и когда вы можете быть уверены, что принимающий узел слышит сообщение. У вас также есть верхняя граница P для относительной разницы в скорости между узлами (так что вы можете учесть машины с медленными процессорами).
В асинхронной модели мы удаляем как верхние границы T, так и P. Сообщения могут занять произвольное время для достижения одноранговых узлов, и каждому узлу может потребоваться произвольное количество времени для ответа. Когда мы говорим произвольно, мы включаем «бесконечность», что означает, что какое-то событие происходит вечно.
Частично синхронная модель в сочетании двух: верхние границы существуют для T и P, но разработчик протокола не знает их, и задача заключается в разработке механизмов, которые все еще приходят к консенсусу в свете этого факта. На практике разработчики протоколов могут создавать системы, напоминающие эту модель, с учетом реалистичных характеристик современных сетей / машин (сообщения обычно попадают туда, куда они направляются) и использования тактик, таких как тайм-ауты, для указания того, когда узел должен повторить попытку отправки сообщения.
Принимая во внимание вышеупомянутые факты, и Паксос, и Плот принадлежат к частичным синхронным моделям.
Проблема византийских генералов - это классическая проблема, с которой сталкивается любая сеть распределенных компьютерных систем. Цель состоит в том, чтобы поддерживать одинаковое состояние всех узлов-участников при наличии вредоносных узлов.
В распределенных системах существует множество сложных проблем, с которыми вам постоянно приходится сталкиваться.
Things fail. You can never count on anything being reliable. Even if you have
perfectly bug-free software, and hardware that never breaks, you’ve still got
to deal with the fact that network connections can break, or messages within a
network can get lost, or that some bozo might sever your network connection
with a bulldozer. (That really happened while I was at Google!)
Given (1), you can never rely on one copy of anything, because that copy might
become unavailable due to a failure. So you need to keep multiple copies, and
those copies need to be consistent – meaning that at any time, all of the
copies agree about their contents.
There’s no way to maintain a single completely consistent view of time between
multiple computers. Due to inconsistencies in individual machine performance,
and variable network delays, variable storage latency, and several other
factors, there’s no canonical way of saying that for two events X and Y, “X
happened before Y”. What that means is that when you try to maintain a consistent set of data, you can’t just say “Run all of the events in order”, because while one server maintaining one copy might “know” that X happened before Y, another server maintaining another copy might be just as certain that Y happened before X.
Короче говоря, все может потерпеть неудачу в любое время; после сбоя участники могут восстановиться и вернуться в систему; любая часть системы не действует активно враждебно (византийские сбои могут быть вызваны вредоносными программами).
Для решения этой проблемы у нас есть консенсусный алгоритм с целью заставить всех участников договориться об одном и том же состоянии.
Консенсус предполагает наличие нескольких серверов, согласующихся с ценностями. Как только они принимают решение о стоимости, это решение является окончательным. Типичные согласованные алгоритмы достигают прогресса, когда доступно любое большинство их серверов.
Paxos и Raft - это консенсусные алгоритмы, которые решают византийскую общую проблему в распределенных сетях, публичных или частных.