分析基于日志的一致性协议还是从两方面，副本间数据一致性 & client看到的线性一致性
- 副本一致性靠日志复制确保顺序性，领导选举保证日志不会丢
- 线性一致性依靠故障检测机制确保不会有stale read
特点
- io视图管理与数据复制分离
如raft就是数据复制与数据主副本都是replica group内根据raft协议完成的，pacificA是通过独立的如zk来管理主副本信息
- 去中心化的故障检测和触发切主
论文中说的是对比GFS, BigTable而言，pacificA副本之间相互检测是否故障，并触发切主
- 强调local -are-network cluster 环境
可能是由于需要所有副本确认ack的缘故
日志复制
- configuration version : 当前io视图版本
- serial number : 对每个update, 主副本都会生成一个连续单调递增的sn
- prepared list : 请求列表，相当于raft中的log，list是按照sn有序的
- committed point :已提交的请求位置，与raft同
- committed list : prepared list中committed point及之前的部分
update步骤：
- client 发送update请求给主
- 主收到请求，生成sn，将<configuration version, sn> 和请求一起持久化到本地并加入prepared list
- 主将<configuration version, sn> & request复制个备
- 备收到请求持久化到本地后，回ack给主
- 主收到所有ack后，更新committed point，回复响应给client
什么时候通知备更新committed point呢 ？
在后续的prepared msg中带过去。
Commit Invariant
p表示主，q表示备，那么：
committed(q) <= committed(p) <= prepared(q)
配置变更（领导选举）
- global configuration manager : 相当于metadata server，维护着每个replica group的io视图和版本
- 变更场景： 检测到某个副本异常、新扩节点
- 变更方式：某个副本携带configuration version发送proposed new configuration给global configuration manager， manager确定发送过来的configuration version与自己维护的version一致后，接受这个变更提议。
网络分区场景下，主和备可能都检查到对方异常了，都发出变更提议，此时manager检查到变更提议冲突，以收到的第一个提议为准，拒绝后面一个。
Primary Invariant
任何时候，只有manager认为某个副本为主时，它才会是主。
但是上面配置变更的方法是无法保证这点的，就有了下面的故障检测机制。
故障检测
stale read
各个数据副本之间，IO视图并非每时每刻都是一致的；可能出现一个老主不知道已经选出了新主，而继续提供读服务的情况。
pacificA的lease机制
- 主副本周期发送心跳给各个备，只要一个备出现没有在周期内答复的情况，主就认为自己失效了，不会再处理读写请求；并且提议manager将这个备移除
- 备只有在发送心跳的副本是主的情况下，才会回复给主副本心跳ack。超过grace period，没有收到主的心跳，备将提议manager移除老主，自己成为新主
只要lease period <= grace period，那么新的主一定是在老的主不提供服务后才升上来的，这就保证了Primary Invariant。
当然这里也要考虑clock drift
文中说GFS, BigTableye也是基于lease机制的，但是是一种centralized检测方法，这个留到后面看
恢复
上文中配置变更只介绍了切主，没有介绍恢复的方法，这个也是影响数据一致性的关键因素
切主场景
- 新主只有在reconciliation做完之后才会处理新的请求
有这个必要吗
- 新主将prepared list中所有的uncommited请求发给备，备上有多余的uncommitted请求会删掉，不足的会补起来，最终各个备的prepared最大的sn将等于新主的最大的committed sn。
Reconfiguration Invariant
新主在t时刻完成reconfiliation，那么任何一个备在t时刻之前的committed list都是t时刻新主的committed list的前缀
节点加入
要么走catchup, 要么走rebalence.