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

需要理解的第一件事是,Cassandra最好運(yùn)行在多臺機(jī)器上.據(jù)我所知,Twitter使用了一個(gè)45臺機(jī)器組成的集群.在一臺機(jī)器上運(yùn)行Cassandra可能不是很有意義,因?yàn)槟銓⑹]有單點(diǎn)故障的系統(tǒng)的優(yōu)勢.

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

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

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

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

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

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

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

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

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

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

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