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

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

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

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

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

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

◆使用此變更修改一個內(nèi)存內(nèi)的Memtable 結(jié)構(gòu)

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

還有多個定期發(fā)生的異步操作:

◆當(dāng)Memtable結(jié)構(gòu)數(shù)據(jù)滿的時候需要寫入到SSTable,一個基于磁盤的結(jié)構(gòu),因此我們不會有太多只存在于內(nèi)存的數(shù)據(jù).

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

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

如果有發(fā)現(xiàn)錯誤或想要添加更多細(xì)節(jié)請留下意見,我不是Cassandra的開發(fā)者,因此我確定一定有1-2處的錯誤隱藏其中.