Cassandra探究（一）

如下圖，一個擁有3個Node的Cassandra叢集。Cassandra是不分主從節點的，也就是說，叢集中每一個節點的地位都是相同的。

複制因子 Replication factor

如果複制因子設定為2，則儲存資料時，每一份資料會被存兩份到其中兩個節點上。官方推薦：複制因子大小最好與叢集節點數一樣，這樣，每個節點都有一份副本資料。

讀一緻性與寫一緻性

由複制因子引發的讀一緻性與寫一緻性。

讀一緻性

如果讀一緻性設定為1，則随機讀取到任意一個節點上的資料就認為讀取成功；為2則需要讀取到兩個節點的資料才認為成功；讀一緻性參數設定的越大，效率越低，但查詢結果的可靠性就越大。如果讀一緻性過小，則可能讀取到的節點正好是需要被修改過但還沒有進行同步的舊資料。

寫一緻性

寫入一個節點成功即認為成功（Cassandra自己的節點内部通信去同步到整個叢集。Cassandra使用點對點通訊協定gossip在叢集中的節點間交行位置和狀态資訊，gossip程序每秒運作一次，與至多3個其他節點交換資訊。 Gossip:一個點對點協定，用于發現和共享在Cassandra叢集中别的節點的資料的狀态等資訊。）。

memtable與sstable

Cassandra的設計目的是通過沒有單點故障的多節點模式去處理海量資料工作負載，它的架構是基于了解系統和硬體故障是可以而且會發生的基礎上的。Cassandra通過peer-to-peer分布式系統來解決故障問題，該系統中的節點是平等同類的，資料都分布在所有節點上。通過gossip通信協定，叢集中的每一個節點頻繁地交換着狀态資訊。每個節點上的commit log捕獲寫行為來確定資料的持久化。

資料會被索引并寫入一個名為memtable的記憶體結構，每當記憶體結構滿了後，資料就會被寫到一個叫SSTablede 磁盤檔案中。所有的寫入都是自動分區和複制的。Cassandra會通過一個叫Compaction的程序周期性的整合SSTables，準備丢 棄的過期無用資料會标記上tombstone以待删除。為了確定所有資料在叢集上保持一緻，各種各樣的修複機制被利用。

 Cassandra是一個分區的面向行存儲的資料庫。Cassandra的架構允許任何授權了的使用者連接配接任何資料中心的任何節點，并使用cql通路資料。用戶端的讀寫請求可以到達叢集的任意節點。當一個用戶端連接配接到一個節點做一個請求時，那個節點伺服器就作為這個特定的客戶操作的一個coordinator，coordinator扮演了客戶應用和擁有使用者請求的資料的節點之間的代理的角色。coordinator會根據叢集中的配置決定哪些節點應該響應請求。相當于用戶端連到哪個節點，哪個節點就是一個協調者，去所有節點中查詢資料。

墓碑 tombstone

Cassandra删除資料是給待删除的資料打一個tombstone标記，說明該資料已經無用，但為了保證所有節點上的資料的一緻性，是以不會直接去實體删除。

考慮這樣的情況：複制因子為3，即3個節點上都有一個副本，删除資料時，有兩個節點的副本删除成功，一個節點的副本删除失敗，整個删除操作仍然被認為成功的（因為有兩個節點應答成功，使用CL.QUORUM一緻性）。接下來如果讀發生在該節點上就會變的不明确，因為結果傳回是空，還是傳回資料，沒有辦法确定哪一種是正确的。

注意：這個問題沒有完全解決，即便使用了墓碑，是以假設你的叢集有删除操作的話我們還要有如下操作: Cassandra運維人員必須在每個gc_grace_seconds周期内對整個叢集進行repair操作。

Repair操作

為什麼要Repair?

在gc_grace_seconds設定的時間到達之前（一般為10天的秒數），每一次查詢都會将符合條件是資料（包含已删除的）都給查詢出來，然後Cassandra再将有墓碑标記的資料給過濾掉，這其實浪費了大量的計算資源。

Repair對Cassandra叢集是極為重要的，因為頻繁的資料删除以及機器Down掉（盡管有Hinted Handoff機制）都會可能導緻資料不一緻（多個副本之間）。在Cassandra日常維護中，我們要例行對叢集進行Repair操作，使用nodetool的Repair指令，在每個節點上都執行一遍repair操作，使資料一緻。

删除墓碑

墓碑的寬限期結束後，Cassandra在壓縮過程中會删除墓碑。

邏輯删除的寬限期由屬性gc_grace_seconds設定。它的預設值是864000秒（十天）。每個表都可以有自己的屬性值。

在截止時間結束時，Cassandra在執行compaction 操作的過程中墓碑将被删除。