前言
- 算法的场景让我们理解更容易。
- Master/Leader 架构设计方式。
- 什么叫被Chosen的值。
有序的确定多个值
- 实例的对齐(Learn)
解决不同机器,实例编号不一致的问题。
- 按照 《微信PaxosStore:深入浅出Paxos算法协议》1的说法。如果第二阶段B Accepted 没有通过,但是已经有机器Accepted了怎么办。?
。。。
- 是因为B机刚刚参与完成实例5的值的确定,但是他并不知道这个值被确定了。怎么知道的?机制
。。。
- A 宕机,C和B重新确定了5怎么办?
。。。
- 这些角色(Proposer,Acceptor,Learner,State machine)可以通过任意的通信方式进行状态共享。比如呢。
TCP连接,通信的方式,信号量,共享内存,通道,?
工程化
- 由于Acceptor和Proposer在同一个进程里面,微信的方式是什么?
等看源码后一切知晓。
- 我们需要严格的落盘,实现方式?。万一丢失还怎么办。
fsync
产生拜占庭问题,需要一些列的检测措施。 - 我们需要一个Leader
保证只有一个Proposer进行写入,减少冲突。
生产级的paxos库
-
同时运行多个paxos group
-
流式传输 这个是啥,找个时间看看。
-
如何删除Paxos数据,
镜像数据针对一台新的机器,那么恢复的机器怎么办。
首先程序会根据磁盘使用情况自动删除paxos log。不是仅仅保存最大的Paxos log。
正确性保证
- 方法:运行前的测试,运行中的对账,拜占庭问题的细化解决。
- 模拟异步通信环境
进程通过内存队列来通信。使其支持出队的延迟,丢失,以及乱序.
- 运行时的对账
采用crc32算法,对有序的多个值进行累加校验。
- 防止拜占庭问题带来的错误。对于所有磁盘写入的数据,都需要进行二次校验。
怎么校验,怎么做。看不懂