Strong and Efficient Consistency with Consistency-Aware Durability(组会讲解)
一、介绍
- 一致性划分
（1）按照一致性的强弱程度
一致性
（2）一般划分
另一种划分
2. 持久化模型
-
跨客户端单调读一致性：
从客户端读取的状态至少与之前从任何客户端读取时返回的状态是一样新的，不管是否有故障，也不管是否跨会话。 -
内容：
实现跨客户端单调读取一致性的方案，高性能+强一致性，支持在副本读取。对于可容忍写完后数据同步到大多数成员组之前机器故障导致数据丢失的应用来说，可以解决问题。
二、CAD(consistency-aware durability)
- 主要思想：
（1）异步完成写入，读取时强制执行持久性。（将持久性的点从写转移到了读）
通过延迟写入的持久性，CAD实现了高性能。
通过确保数据在被读取之前是持久的，CAD可以实现单调的读取，甚至跨故障。 - 状态持久性保证：
当读取一个key时，CAD保证直到修改key的最后一次更新的整个状态都是持久的，而不仅仅是这个key。
例如：[a,b1,c,b2,d]。 - 基本流程
（1）索引：
（2）写操作：跟随者在响应中包含persisted-index，领导者在请求或心跳中向跟随者发送 durable-index
(3)读操作（持久性检查机制）：
Leader：当读key请求到达,比较key的update-index与durable-index。
update-index>durable-index:强制将update-index之前的
未被复制的日志同步复制到大多数节点并持久化，
更新durable-index
update-index<=durable-index:直接服务
Follower:
update-index>durable-index:转发给Leader节点
update-index<=durable-index:直接服务
三、跨客户端单调读取
- 保证
这个属性保证了从一个客户端读取的状态，无论服务器和客户端是否故障，总是会返回一个至少和之前从任何客户端读取的状态一样新的状态，而且是跨会话的。 - 允许在副本处读取
（1）在Follower上读取的问题：（S5分区，虽然持久性检查成功）
四、ORCA设计
1.保证
使用异步持久性，能够保证顺序一致性，提供在所有故障下和跨会话的跨客户端单调读取。但是，ORCA不能保证永远不会看到陈旧的数据。其实ORCA是基于ZooKeeper的修改版本，它包含了CAD和跨客户端单调读取，又通过持久性检查机制、基于租约的活动集技术以及两步断租机制来保证其正确性。
2.解决方案-----活动集（Active set）
（1）至少包含大多数节点
（2）当Leader持久化数据时，必须确保活动集内的所有节点都已经持久化了。
（3）只有活动集内的节点才能允许提供读服务。
那么，我们可以知道，活动集的大小在可扩展性和延迟性之间存在着权衡。
就上述问题，为了确保正确性，一个Follower必须在Leader将其从活动集中移除之前将自己标记出来。
3. 解决方案----两步断租机制：
（1）内容：
首先，一个断开的Follower将自己从活动集中标记出来；然后Leader将Follower从活动集中移除。
（2）两个超时：
标记超时（mark-out timeout , mt）：一旦mt过后，Follower将自己标记出；时间与心跳间隔相同。
移除超时（removal timeout, rt）:一旦rt过后，Leader将Follower从活动集中移除。 rt>=5∗mt(时钟问题)
五、测评
1.CAD与同步和异步持久性相比表现如何？（CDF:累积分布函数）
CAD延迟比同步持久性低，并与异步持久性性能相似。（0.8%触发同步持久性的读的百分比）
2.与weak-ZooKeeper和strong-ZooKeeper相比，ORCA的表现如何？
ORCA表现良好的原因：
1.避免了写入过程中同步复制和持久化的成本
2.允许在许多副本处进行读取
ORCA比Weak-Zookeeper慢的原因:
1.访问非持久化项目的读取必须在活动集的所有节点上持久化数据
2.在Follower处访问非持久化数据的读取会产生额外的往返，因为它们被重定向到Leader
3.ORCA是否能保证在故障情况下的跨客户端单调读取？
如果节点被领导者删除，则拒绝读请求。若重新恢复，则返回最新数据。因此，可以是现跨客户端单调读。
4.ORCA是否为应用提供了更好的保证？
位置共享应用：一组用户在存储系统上更新他们的位置，而另一组用户读取这些位置。
开源的Twitter克隆：发布文章、观看时间线。（读取为主）