# 简介
说白了就是 CR 的加强版，将读请求分摊到链上的每个 replicas，搭配 zookeeper 实现了分布式容错机制。
# 基本模型
CRAQ (Chain Replication with Apportioned Queries), 只会提供两个原语，读和写。
两种一致性：
强一致性：所有读操作都能读到最新的数据。
最终一致性：所有节点 apply write order 相同，但是读操作可能读到 stale data。
CRAQ 能够保证强一致性。
# Chain Replication
这张图足够解释 Chain Replication：
所有的 write request 都必须通过 head 来处理，head 处理 write，也就是修改对应的 object。注意每个 object 都有一个 version 。修改 object 后 version 也会随之改变。当 head 收到了 write 请求之后就会将这个 write operation 通过 chain 传递下去。在 tail 处才会 commit 这个 write，并且把 reply 返回给 client。
# Chain Replication with Apportioned Queries
Object 在 replicas 上有不同的 version，每个 version 有两种状态： clean 与 dirty 。
clean ：当 object 被创建时，它的对应 version 是 clean。只有 clean 状态 version 才能被读取。
dirty ：当 object 被修改后 version 后增加。如果节点不是 tail，那么它需要将这个 version 的 object append。并将这个 version 标为 dirty 。
只有 tail 的 committed 才能将 version 从 dirty 转换为 clean
Figure 3 很好地解释了 Query 方式，对于一个 Query 来说：
- 如果查询的这个 object 的最新的 version 是 clean，那么就将这个 object 返回。
- 如果对应的 version 是 dirty，那么 replicas 向 Tail 询问哪个 version 是 clean 的。tail 返回 clean 的 version 号。
- replicas 将对应 clean version 的 object 返回给 client。
注意：如果一个 version 被确认为 clean，它会删除之前所有 dirty version。但 clean version 之后的却不会被删除！
将像图 3 所示，V1 被确认为 clean version，它会删除 V0（如果有 V0 的话），而不会删除 V2。
通过这样的机制就可以让每一个 replicas 承担 read，并且还保证了强一致性。
# Scaling CRAQ
这一块有点模糊，大致是看懂了。。。
一个 object 的 identifier 有两个组成
chain identifier ：决定有哪些节点会构成这条链
key identifier ：决定这个 object 在这条链中的唯一标识
# 链放置策略
第一种：指定确定数量的 num_datacenters 将会构成链，总共有 chain_size 的链，使用一致性 hash 来决定 datacenter identifier。
第二种：链的头部是 dc1，链的尾部是 dcN。严格按照这个顺序定义链。
第二种：虽然链的顺序定义了，但是每个 datacenter 能放置的链数量也是限定的。
# CRAQ within a Datacenter
一个 datacenter 中如何选择或者说处理多个链通过该 datacenter。这里有两种方法：
- 一致性 hash。
- 类似于 GFS 的 membership management。
# CRAQ Across Multiple Datacenters
CRAQ’s ability to read from any node improves its latency when chains stretch across the wide-area.
CRAQ 能够显著降低延迟，当 CRAO across wide area。
