寫在前面
cassandra3.x官方文件的非官方翻譯。翻譯內容水平全依賴本人英文水平和對cassandra的理解。所以強烈建議閱讀英文版cassandra 3.x 官方文件。此文件一半是翻譯，一半是個人對cassandra的認知。儘量將我的理解通過引用的方式標註，以示區別。另外文件翻譯是項長期並有挑戰的工作，如果你願意加入cassandra git book,可以發信給我。當然你也可以加入我們的QQ群,104822562。一起學習探討cassandra.

Gossip

Gossip 是一個對等網路通訊協議，節點間斷性的交換他們自身的狀態資訊以及其他它們知道的節點資訊。gossip 每秒中和叢集中最多三個節點交換資訊。不僅交換他們自身資訊，而且還交換通過之前的gossip通訊瞭解的其他節點資訊，所以所有的節點能夠很快的瞭解叢集中的其他節點狀況。一條gossip 資訊會有一個相關聯的版本號，因此當進行gossip交換的時候，對於一個特定的節點，它的老資訊就會被最近的狀態所覆蓋。

為了阻止gossip通訊可能出現的問題，叢集中所有的節點都有相同的seed nodes列表。這一點在一個節點第一次啟動的時候尤其重要。預設情況下，一個節點在隨後的重啟過程中會記住已經gossip的其他節點。seed node就是為了新節點加入到叢集中，bootstrap過程中使用的。不是為了單點失敗，也沒有其他特別的目的。

注意:

在多資料中心叢集環境，確保每個資料中心至少有一個節點在seed list中。為了容錯建議每個資料中心指派多個seed node,否則當一個節點bootstrap時，需要同其他資料中心gossip。

不建議把每個節點都設定為seed node,因為會增加維護的成本以及降低了gossip的效能。gossip優化並不是特別重要，但是建議使用一個小的seed 列表(每個資料中心3個節點最佳)
 

失敗檢測和恢復

失敗檢測是一種為本地決策提供資訊的方法，從gossip的狀態和歷史獲取資訊，判斷系統中的一個節點是否down了或者已經恢復了。Cassandra 利用這個資訊避免將客戶端的請求路由到任何時候有可能不可到達的節點。(cassandra 同樣能夠通過Dynamic Snitch)避免將客戶端請求路由到那些存活的但是效能比較差的節點上。

gossip過程能夠跟蹤其他節點的狀態，通過直接(直接與某個節點gossip)或非直接(通過二手，三手等)方式。相比於一個固定的閾值來標記一個節點為fail，Cassandra 採用一個自然增長的檢測機制來計算每個節點的閾值，考慮到了網路、負載、歷史狀況等因素。當進行gossip交換時，每個節點維護了一個其他節點gossip資訊到達的滑動視窗時間。可以通過配置

節點失敗可能有各種各樣的原因造成的，比如硬體失敗，網路電力供應中斷。節點中斷經常是短暫的但是有可能持續很長時間的。因為一個節點中斷很少意味著永久離開叢集，不會自動從叢集ring中移除。其他的節點會週期性的嘗試和失敗的節點重新建立聯絡，看它們是否已經迴歸。想要永久的改變叢集節點的成員關係，需要管理員通過notetool明確的將節點新增進來或者移除出叢集。

當一個節點經過down到重新迴歸的，可能會丟失掉它需要維護的副本資料。repair可以幫助恢復這些資料，比如hinted handoffs以及手動repair.節點down掉的時間決定了通過哪種機制來保持資料的一致性。

注：

hintedhandoff有時間限制，預設三小時，超過此時間前面的資料會不斷的被覆蓋掉。必須要手動repair