我們已經開始在OneSpot使用Cassandra來作為我們下一代的存儲引擎(使用一個EC2的機器集群代替一臺非常大的PostgreSQL機器),因此,之前幾周的時間我一直在使用Cassandra. 由于我本人是一個基礎設施方面的書呆子,并且堅信需要理解系統堆棧的各個層面,因為我閱讀了部分關于Cassandra如何工作的資料,并且想寫出點總結以期對后來者有所幫助.由于Cassandra的寫性能表現卓越這一點眾所周知,我認為我的介紹應該由此開始.

需要理解的第一件事是,Cassandra最好運行在多臺機器上.據我所知,Twitter使用了一個45臺機器組成的集群.在一臺機器上運行Cassandra可能不是很有意義,因為你將失去沒有單點故障的系統的優勢.

客戶端向一個隨機的Cassandra節點發出一個寫請求.這個節點作為代理往集群寫入數據.節點的集群存儲在一個節點”環”上,寫會按照復制放置策略(replication placement strategy)復制到N個節點上.當使用RackAwareStrategy策略時,為了保證可靠性(reliability)與可用性(Availability), Cassandra會按照復制節點到當前節點的距離將復制節點分為3個桶:與當前節點位于同一機架、與當前節點位于同一數據中心、或位于不同的數據中心.你配置了Cassandra寫數據到N個節點來做冗余,Cassandra會將第一份拷貝寫入到此數據的主節點,第二份拷貝到環上的位于另一個數據中心的節點,剩余的其它拷貝到與代理節點位于同一個數據中心的機器上.這樣就可以確保單點故障不會導致整個集群不可用,即使在整個數據中心都不可用時集群仍然保持可用.

因此,寫請求從你的客戶端出發到單一隨機節點,此節點根據復制放置策略將寫操作發送到N個不同的節點.我沒有在此討論很多邊緣用例極端情況(節點宕機、集群中新增節點、等等),但是,節點需要等待N個節點返回成功并返回成功給客戶端.(此處的描述有問題,Cassandra中,還有另外一個W的參數,也就是需要等待幾份寫拷貝成功才返回成功給客戶端,譯者加).

節點中的每一個都會以”RowMutation”消息的形式接收到此寫請求.對于此消息,節點會采取以下兩種行動:

◆追加此變更到提交日志(Commit log)以滿足事務性目的

◆使用此變更修改一個內存內的Memtable 結構

它的工作就此結束.這就是為什么Cassandra的寫操作如此快的原因:最慢的部分就是追加變更日志到文件的操作.與關系型數據庫不同的是,Cassandra不會修改存儲在磁盤上的數據,也不會去更新索引,因此沒有密集的同步磁盤操作來阻塞這次寫操作.

還有多個定期發生的異步操作:

◆當Memtable結構數據滿的時候需要寫入到SSTable,一個基于磁盤的結構,因此我們不會有太多只存在于內存的數據.

◆每個給定列族(ColumnFamily)的一組臨時的SSTable會被合并到一個大的SSTable.此時,臨時的SSTable就沒有用了,它們會在將來的某個時間點被當作垃圾回收掉.

還有大量的邊緣用例極端情況與復雜情況,我都沒有在此討論,我強烈建議大家至少要去閱讀下Cassandra維基(Wiki)中關于ArchitectureInternals與Operations的相關描述.分布式系統相當復雜,Cassandra也不例外.

如果有發現錯誤或想要添加更多細節請留下意見,我不是Cassandra的開發者,因此我確定一定有1-2處的錯誤隱藏其中.