走进cassandra之七 最终一致性

关于这个最终一致性，咱们仍是举打仗的那个例子。
一个师，下辖三个团，一个独立营。
你们知道，在战斗的时候，突发事件不少，时间也很紧迫。
来自师部的做战命令，可能没有办法及时到达各个营。
尤为是在八路的军队里，通信基本靠吼，通信员去传令的时候，说不定走在半路就被打死了。
得想办法应对此类问题。

这个跟cassandra是一个样的，它也有不少节点，多个节点，同时在向外服务，它也须要通信员去传达命令给各个节点，通信员在半路遇到打劫的怎么办呢？死掉了怎么办呢？节点没反应了怎么办呢？

针对这些问题， cassandra是有一套本身的机制的。
1.Read Repair
2.Anti-Entropy Node Repair
3.Hinted Handoff

#1 read repair.
coordinator 发送给每个 replica的读请求，有两种：
direct read request
background read repair request

direct read request 会送给谁呢？
你的一致性level所规定的那些节点（one,quorum,all）

background read repair request 送给谁呢？
送给剩余的那些节点（direct read request没有送到的节点）

读取Key A的数据时，系统会读取Key A的全部数据副本，若是发现有不一致，则进行一致性修复。
若是读一致性要求为ONE，会当即返回离客户端最近的一份数据副本。而后会在后台执行Read Repair。这意味着第一次读取到的数据可能不是最新的数据。
若是读一致性要求为QUORUM，则会在读取超过半数的一致性的副本后返回一份副本给客户端，剩余节点的一致性检查和修复则在后台执行。
若是读一致性要求高(ALL)，则只有Read Repair完成后才能返回一致性的一份数据副本给客户端。
该机制有利于减小最终一致的时间窗口

2.Anti-Entropy Node Repair
有一个叫node tool的东东，专门负责管理维护各个节点，它的任务之一就是经过Anti-Entropy这种办法，来进行node repair，把不一致的数据弄成一致的。
数据的最终一致性由AntiEntropy（逆熵）所生成的MerkleTrees对比来发现数据复制的不一致，经过org.apache.cassandra.streaming来进行完整的一致性修复。
Merkle Tree是一种Hash Tree，叶子节点是Key的hash值，父节点是全部子节点值的hash值，经过判断父节点的异同能够知道全部子节点的异同。
经过判断root的异同能够快速判断全部叶子节点数据的异同。
执行nodetool?repair能够启动Anti-Entropy，此操做须要扫描全部数据，对系统的IO有较大压力，建议在业务低峰期按期执行

3.Hinted Handoff
Writes are always sent to all replicas for the specified row regardless of theconsistency level
specified by the client. If a node happens to be down at the time of write, itscorresponding replicas will save hints
about the missed writes, and then handoff the affected rows once the node comesback online。
举例来讲：
Key A按照规则首要写入节点为N1，复制到N2
假 如N1宕机，若是写入N2能知足ConsistencyLevel要求，则Key A对应的RowMutation将封装一个带hint信息的头部（包含了目标为N1的信息），而后随机写入一个节点N3，此副本不可读。同时正常复制一份 数据到N2，此副本能够提供读。若是写N2不知足写一致性要求，则写会失败。
N1恢复后，本来应该写入N1的带hint头的信息将从新写回N1。
HintedHandoff是实现最终一致性的一个优化措施，能够减小最终一致的时间窗口。