предисловие
Алгоритм Paxos основан на передачи сообщений и высокая степень отказоустойчивости является последовательным алгоритмом , в настоящее время считается одним из наиболее эффективных для решения задачи распределенного алгоритма на основе консенсуса.
В типичной распределенной системе, ситуация всегда будет иметь место, например, время простоя машины или сетевых аномалий.
Paxos задача алгоритма должна быть решена как отклонение от нормы может происходить в распределенной системе, быстро и правильно согласовать значения данных в кластере, и убедитесь , что больше , чем происходит ли какое - либо исключение, а не разрушит всю систему консистенция.
Алгоритм Паксос описывает
тип узла
- Инициатор ( автор предложения) : значение предложения
- Приемник (акцептор) : голосование по каждому предложению
- Проинформировать человека (Learner) : Слушайте голос, но не голосовать
Изображенные выше базовая структура алгоритма Paxos, многие сторонники (к предлагающему) представить предложения к приемнику (акцептор), когда приемник (акцептор), чтобы принять определенное значение, то результат сообщается Learner.
процесс внедрения
Одно предложение содержит заранее определенные два поля: [N, V], где п порядковый номер (уникальный), v является предлагаемым значением.
Этап I: Подготовка фазы
Каждый отправляется Предлагающим Подготовить запрос ко всему акцептанту.
Подготовка Acceptor Когда запрос получен, предложение содержится в [n1, v1], и не получил до Подготовить запрос, посылает Подготовьте ответ, полученный в настоящее время предложение [n1, v1], и не гарантирует , что нет Мы примем число предложений менее n1.
举个例子，看下面这张图，Acceptor Y 在收到 [n=2, v=8] 的 Prepare 请求时，由于之前没有接收过提议，因此就发送一个 [no previous] 的 Prepare 响应，设置当前接收到的提议为 [n=2, v=8]，并且保证以后不会再接受序号小于 2 的提议。其它的 Acceptor 类似。
如果 Acceptor 接收到一个 Prepare 请求，包含的提议为 [n2, v2]，并且之前已经接收过提议 [n1, v1]。
那么有两种情况
- 如果 n1 > n2，那么就丢弃该提议请求
- 否则，发送 Prepare 响应，该 Prepare 响应包含之前已经接收过的提议 [n1, v1]，设置当前接收到的提议为 [n2, v2]，并且保证以后不会再接受序号小于 n2 的提议。
如下图所示
Acceptor Z 收到 Proposer A 发来的 [n=2, v=8] 的 Prepare 请求，由于之前已经接收过 [n=4, v=5] 的提议，并且 n > 2，因此就抛弃该提议请求。
Acceptor X 收到 Proposer B 发来的 [n=4, v=5] 的 Prepare 请求，因为之前接收到的提议为 [n=2, v=8]，并且 2 <= 4，因此就发送 [n=2, v=8] 的 Prepare 响应（之前接受的提议），设置当前接收到的提议为 [n=4, v=5]，并且保证以后不会再接受序号小于 4 的提议。
阶段二：Accept 阶段
当一个 Proposer 接收到超过一半 Acceptor 的 Prepare 响应时，就可以发送 Accept 请求。
也是两种情况：
- Proposer A 接收到两个 Prepare 响应之后，就发送 [n=2, v=8] Accept 请求。该 Accept 请求会被所有 Acceptor 丢弃，因为此时所有 Acceptor 都保证不接受序号小于 4 的提议。
- Proposer B 过后也收到了两个 Prepare 响应，因此也开始发送 Accept 请求。需要注意的是，Accept 请求的 v 需要取它收到的最大提议编号（这里指的是 Proposer B 收到的响应里最大 v 值）对应的 v 值，也就是 8。因此它发送 [n=4, v=8] 的 Accept 请求。
阶段三：Learn 阶段
Acceptor 接收到 Accept 请求时，如果序号大于等于该 Acceptor 承诺的最小序号，那么就发送 Learn 提议给所有的 Learner。当 Learner 发现有大多数的 Acceptor 接收了某个提议，那么该提议的提议值就被 Paxos 选择出来。
2PC/3PC/Paxos 对比
- 二阶段提交协议（2PC）解决了分布式事务的原子性问题，保证了分布式事务的多个参与者要么都执行成功，要么都执行失败。但是，存在诸如同步阻塞、无限期等待、网络分区等问题。
- 三阶段提交协议（3PC）在 2PC 基础上，添加了 preCommit 过程，从而避免了 2PC 的无限期等待问题。
- Алгоритм Paxos ввел «более половины» идея популярна в большинстве . В то же время Paxos алгоритм поддерживает вращение между распределенными узлами, и это в значительной степени предотвращает появление распределенной одной точки , таким образом , Paxos алгоритм решает не только проблему ждать до бесконечности, но и решить проблему раздела сети , в настоящее время, это лучший один из распределенного протокола когерентности.
Список литературы
«от Паксоса к Zookeeper: Распределенная Консенсус Принципы и практика» - Ni Ультра