閑話協議(Gossip)

Cassandra是一個有單個節點組成的集群 – 其中沒有“主”節點或單點故障-因此，每個節點都必須積極地確認集群中其他節點的狀態。它們使用一個稱為閑話（Gossip）的機制來做此事.每個節點每秒中都會將集群中每個節點的狀態“以閑話的方式傳播”到1-3個其他節點.系統為閑話數據添加了版本,因此一個節點的任何變更都會快速地傳播遍整個集群.通過這種方式,每個節點都能知道任一其他節點的當前狀態:是在正在自舉呢, 還是正常運行呢,等等.

提示移交(Hinted Handoff)

在關于寫操作的文章中,我提到Cassandra會存儲數據的拷貝到N個節點.客戶端可以根據數據的重要性選擇一個一致性級別(Consistency level),例如, ConsistencyLevel.QUORUM表示,只有這N個節點中的多數返回成功才表示這個寫操作成功.

如果這些節點中的一個宕機了,會發生什么呢?寫操作稍后將如何傳遞到此節點呢?Cassandra使用了一種稱為提示移交(Hinted Handoff)的技術來解決此問題,其中數據會被寫入并保存到另一個隨機節點X,并提示這些數據需要被保存到節點Y,并在節點重新在線時進行重放(記住,當節點Y變成在線時,閑話機制會快速通知X節點).提示移交可以確保節點Y可以快速的匹配上集群中的其他節點.注意,如果提示移交由于某種原因沒有起作用,讀修復最終仍然會“修復”這些過期數據，不過只有當客戶端訪問這些數據時才會進行讀修復.

提示的寫是不可讀的(因為節點X并不是這N份拷貝的其中一個正式節點),因此,它們并不會記入寫一致性.如果Cassandra的配置了3份拷貝,而其中的兩個節點不可用,就不可能實現一個ConsistencyLevel.QUORUM的寫操作.

逆熵(Anti-Entropy)

Cassandra的***一個眾所周知的秘密武器是逆熵(Anti-entropy).逆熵明確保證集群中的節點一致認可當前數據.如果由于默認情況,讀修復(read repair)與提示移交(hinted handoff)都沒有生效,逆熵會確保節點達到最終一致性.逆熵服務是在“主壓縮”(等價與關系數據庫中的重建表)時運行的,因此，它是一個相對重量級但運行不頻繁的進程.逆熵使用Merkle樹(也稱為散列樹)來確定節點在列族(column family)數據樹內的什么位置不能一致認可,接著修復該位置的每一個分支.

原文鏈接：http://www.dbthink.com/?p=430

1. 詳解NoSQL數據庫Apache Cassandra的配置
2. 漫談Cassandra客戶端的使用
3. 詳解Cassandra數據模型
4. 超越關系型數據庫 pureXML技術應用及展望
5. 新興數據庫打破整個舊規則
6. 探尋關系數據庫和ORM的***替代者