如下圖，一個擁有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 操作的過程中墓碑將被刪除。