zookeeper 同城双活 zookeeper两阶段提交

• 两阶段提交 two-phase commit (2PC)
• 三阶段提交 three-phase commit (3PC)
• Paxos 算法
• ZAB 算法

2PC

两阶段提交，强一致性算法。常用在分布式数据库中，如分布式事务（tcc）。
undo 记录原始数据的样子，事务失败了恢复，成功了记入 redo 日志。
比如把增加数据库表字段 A 的 SQL 提交给 DBA，DBA 不会执行，需要把删除 A 字段的 SQL 也提交给 DBA 才行。

第一阶段所有数据库源都返回 ok 了，在执行第二阶段，提交。

优点：原理简单、实现方便
缺点：同步阻塞、单点故障、数据不一致（commit 时有一个数据库的链接断了）、容错机制不完善
大多使用改善过的 2PC，有事务补偿。

3PC

• 与2PC区别：

• 第二阶段才写undo和redo事务日志
• 第三阶段协调者出现异常或网络超时参与者也会commit

• 优点：

• 改善同步阻塞
• 改善单点故障

• 缺点：

• 同步阻塞
• 单点故障
• 数据不一致
• 容错机制不完善

因为有这么多问题，3PC 用的并不多。

Paxos 算法

• 少数服从多数
• 角色轮换避免单点故障

ZAB

ZAB 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性。

ZAB 协议两种模式：消息广播和崩溃恢复。

消息广播

1. Leader 接收到消息请求后，将消息赋予一个全局唯一的 64 位自增 id，叫做：zxid，通过 zxid 的大小比较即可实现因果有序这一特性。
2. Leader 通过先进先出队列(通过 TCP 协议来实现，以此实现了全局有序这一特性)将带有 zxid 的消息作为一个提案(proposal)分发给所有 follower。
3. 当 follower 接收到 proposal，先将 proposal 写到硬盘，写硬盘成功后再向 leader 回一个 ACK。
4. 当 leader 接收到合法数量的 ACKs 后，leader 就向所有 follower 发送 COMMIT 命令，会在本地执行该消息。
5. 当 follower 收到消息的 COMMIT 命令时，就会执行该消息。

崩溃恢复

1. 每个Server会发出一个投票,第一次都是投自己。投票信息：（myid，ZXID）
2. 收集来自各个服务器的投票
3. 处理投票并重新投票，处理逻辑：优先比较ZXID（确保事务是最新的），然后比较myid
4. 统计投票，只要超过半数的机器接收到同样的投票信息，就可以确定leader
5. 改变服务器状态