走進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是實現最終一致性的一個優化措施，能夠減小最終一致的時間窗口。