摘要：是一套開源分布式數(shù)據(jù)庫系統(tǒng)。的應(yīng)用場景具有常見分布式數(shù)據(jù)庫，其自帶的命令行工具完備，兼容性強(qiáng)，甚至機(jī)器都可以安裝，因此維護(hù)升級都相對比較簡單。使用數(shù)據(jù)的字節(jié)進(jìn)行有順分區(qū)。

Cassandra是一套開源分布式NoSQL數(shù)據(jù)庫系統(tǒng)。由Facebook開發(fā)，主要用于儲存收件箱等簡單格式數(shù)據(jù)，集GoogleBigTable的數(shù)據(jù)模型與Amazon Dynamo的完全分布式的架構(gòu)于一身。
2008年，F(xiàn)acebook將 Cassandra 開源，并被Digg、Twitter等知名公司引入，成為了一種流行的分布式結(jié)構(gòu)化數(shù)據(jù)存儲方案。
Cassandra是一個混合型的非關(guān)系的數(shù)據(jù)庫，類似于Google的BigTable。其主要功能比Dynamo （分布式的Key-Value存儲系統(tǒng)）更豐富，但支持度卻不如文檔存儲MongoDB（介于關(guān)系數(shù)據(jù)庫和非關(guān)系數(shù)據(jù)庫之間的開源產(chǎn)品，是非關(guān)系數(shù)據(jù)庫當(dāng)中功能最豐富，最像關(guān)系數(shù)據(jù)庫的。支持的數(shù)據(jù)結(jié)構(gòu)非常松散，是類似json的bjson格式，因此可以存儲比較復(fù)雜的數(shù)據(jù)類型）。

Cassandra的應(yīng)用場景
Cassandra具有常見NoSQL 分布式數(shù)據(jù)庫，其自帶的命令行工具完備，兼容性強(qiáng)，甚至Windows機(jī)器都可以安裝，因此維護(hù)、升級都相對比較簡單。它有著很人性化的Web管理界面，兼容大部分SQL語法。可以設(shè)置多個“中心”，這一點(diǎn)跟Hadoop based的HBase / Hive 很不一樣。
Cassandra讀寫性能和可擴(kuò)展非常好。由于它是一堆數(shù)據(jù)庫節(jié)點(diǎn)共同構(gòu)成的一個分布式網(wǎng)絡(luò)服務(wù)，只要對Cassandra 的一個節(jié)點(diǎn)就行寫操作，會被復(fù)制到其他節(jié)點(diǎn)上去。同理，對Cassandra的一個節(jié)點(diǎn)進(jìn)行讀操作，也會被路由到某個節(jié)點(diǎn)上面去讀取。因此，對于一個Cassandra群集來說，擴(kuò)展性能是比較簡單的事情，只管在群集里面添加節(jié)點(diǎn)就可以了。非常適合金融、電商等記錄系統(tǒng)日志、產(chǎn)品的目錄管理、實(shí)時(shí)數(shù)據(jù)存儲等等要求高的行業(yè)。
我們把Cassandra應(yīng)用在了數(shù)據(jù)對象服務(wù)的數(shù)據(jù)提供上，由于有多個“中心”，又減少了對于Hadoop環(huán)境的依賴，在維護(hù)管理上會非常便捷，又能大幅提升數(shù)據(jù)的存儲以及查詢性能。

Cassandra docker安裝初體驗(yàn)
啟動Cassandra docker實(shí)例：
$ docker run --name some-cassandra -d cassandra:tag
some-cassandra指定的容器名稱，tag是指定所需Cassandra版本的標(biāo)記。具體參考docker hub。
建立集群以及在已有集群上擴(kuò)展機(jī)器:
假設(shè)第一臺機(jī)器的IP地址是10.42.42.42第二臺機(jī)器人的IP地址10.43.43.43，請使用公開的八卦端口啟動第一臺機(jī)器：
$ docker run --name some-cassandra -d -e CASSANDRA_BROADCAST_ADDRESS=10.42.42.42 -p 7000:7000 cassandra:tag
然后在第二臺機(jī)器上啟動一個Cassandra容器，暴露的八卦端口和種子指向第一臺機(jī)器：
$ docker run --name some-cassandra -d -e CASSANDRA_BROADCAST_ADDRESS=10.43.43.43 -p 7000:7000 -e CASSANDRA_SEEDS=10.42.42.42 cassandra:tag
這樣就建立好了一個倆臺Cassandra機(jī)器的集群了，可以進(jìn)行cqlsh的體驗(yàn)了。

Cassandra應(yīng)用實(shí)踐
Cassandra沒有像BigTable或Hbase那樣選擇中心控制節(jié)點(diǎn)，而選擇了無中心的P2P架構(gòu)，網(wǎng)絡(luò)中的所有節(jié)點(diǎn)都是對等的，它們構(gòu)成了一個環(huán)，節(jié)點(diǎn)之間通過P2P協(xié)議每秒鐘交換一次數(shù)據(jù)，這樣每個節(jié)點(diǎn)都擁有其它所有節(jié)點(diǎn)的信息，包括位置、狀態(tài)等。

客戶端可以連接集群中的任一個節(jié)點(diǎn)來連接整個集群，和客戶端建立連接的節(jié)點(diǎn)叫協(xié)作者(coordinator)，Cassandra相當(dāng)于一個代理，負(fù)責(zé)定位該次請求要發(fā)到哪些實(shí)際擁有本次請求所需數(shù)據(jù)的節(jié)點(diǎn)上去獲取，但如何獲取并返回，主要根據(jù)客戶端要求的一致性級別（Consistency Level）來確定。
比如：ONE指只要有一個節(jié)點(diǎn)返回?cái)?shù)據(jù)就可以對客戶端做出響應(yīng)，QUONUM指需要返回幾個根據(jù)用戶的配置數(shù)目，ALL指等于數(shù)據(jù)復(fù)制份數(shù)的所有節(jié)點(diǎn)都返回結(jié)果才能向客戶端做出響應(yīng)，對于數(shù)據(jù)一致性要求不是特別高的可以選擇ONE，這是最快的一種方式。
Cassandra的數(shù)據(jù)分發(fā)和復(fù)制通常是一起的，數(shù)據(jù)用表的形式來組織，用主鍵來識別應(yīng)該存儲到哪些節(jié)點(diǎn)上，行的copy稱作replica。當(dāng)一個集群被創(chuàng)建時(shí)，至少要指定如下幾個配置：Virtual Nodes，Partitioner，Replication Strategy，Snitch。
數(shù)據(jù)復(fù)制策略有兩種，一種是SimpleStrategy，適合一個數(shù)據(jù)中心的情況，第一份數(shù)據(jù)放在Partitioner確定的節(jié)點(diǎn)，后面的放在順時(shí)針找到的節(jié)點(diǎn)上，它不考慮跨數(shù)據(jù)中心和機(jī)架的復(fù)制。另外一種是NetworkTopologyStargegy，第一份數(shù)據(jù)和前一種一樣，第二份復(fù)制的數(shù)據(jù)放在不同的機(jī)架上，每個數(shù)據(jù)中心可以有不同數(shù)據(jù)的replicas。
Partitioner策略有三種，默認(rèn)是Murmur3Partitioner，使用MurmurHash。RandomPartitioner，使用Md5 Hash。ByteOrderedPartitioner使用數(shù)據(jù)的字節(jié)進(jìn)行有順分區(qū)。Cassandra默認(rèn)使用MurmurHash，這種有更高的性能。
那么如果Cassandra集群動態(tài)擴(kuò)展怎么辦？數(shù)據(jù)怎么流動呢？如果是依次按順序流動那么效率非常低下。這里就要提到Cassandra 的一個Vnode （virtual nodes）概念。就是把一個節(jié)點(diǎn)分成默認(rèn)是256個Vnode來擁有較多不連續(xù)的hash值范圍，以達(dá)到數(shù)據(jù)的負(fù)載的目的。

Cassandra 的寫請求

先為了能夠持久化與宕機(jī)恢復(fù)會寫入CommitLog

– 對應(yīng)的配置： commitlog_directory
同時(shí)寫入Memtable
– Memtable ： 內(nèi)存之中的數(shù)據(jù)結(jié)構(gòu)

每當(dāng)Memtable的數(shù)據(jù)達(dá)到一定條件時(shí)將數(shù)據(jù)Flush到SSTable
– 條件在配置文件之中定義
? memtable_heap_space_in_mb
? memtable_offheap_space_in_mb
– SSTable
? 真正存儲到了硬盤之上：data_file_directories
? SSTable是不可變的，每次會將SSTable完全刪除再新寫一個

Flush之后，CommitLog會被自動刪除。
如果客戶端配置了Consistency Level是ONE，意味著只要有一個節(jié)點(diǎn)寫入成功，就由代理節(jié)點(diǎn)(Coordinator)返回給客戶端寫入完成。當(dāng)然這中間有可能會出現(xiàn)其它節(jié)點(diǎn)寫入失敗的情況，Cassandra自己會通過Hinted Handoff或Read Repair 或者Anti-entropy Node Repair方式保證數(shù)據(jù)最終一致性。

Cassandra的讀請求
上面提到，Cassandra在讀取數(shù)據(jù)有優(yōu)勢。在讀取時(shí)，Cassandra首先檢查Bloom filter，每一個SSTable都有一個Bloom filter用來檢查partition key是否在這個SSTable，這一步是在訪問任何磁盤IO的前面就會做掉。如果存在，再檢查partition key cache，然后再做如下操作：
如果在cache中能找到索引，到compression offset map中找擁有這個數(shù)據(jù)的數(shù)據(jù)塊，從磁盤上取得壓縮數(shù)據(jù)并返回結(jié)果集。如果在cache中找不到索引，搜索partition summary確定索引在磁盤上的大概位置，然后獲取索引入口，在SSTable上執(zhí)行一次多帶帶的尋道和一個順序的列讀取操作，下面也是到compression offset map中找擁有這個數(shù)據(jù)的數(shù)據(jù)塊，從磁盤上取得壓縮數(shù)據(jù)并返回結(jié)果集。讀取數(shù)據(jù)時(shí)會合并Memtable中緩存的數(shù)據(jù)、多個SSTable中的數(shù)據(jù)，才返回最終的結(jié)果。

讀請求(Read Request)分兩種，一種是Rirect Read Request，根據(jù)客戶端配置的Consistency Level讀取到數(shù)據(jù)即可返回客戶端結(jié)果。一種是Background Read Repair Request,除了直接請求到達(dá)的節(jié)點(diǎn)外，會被發(fā)送到其它復(fù)制節(jié)點(diǎn)，用于修復(fù)之前寫入有問題的節(jié)點(diǎn)，保證數(shù)據(jù)最終一致性。
客戶端讀取時(shí)，Coordinator首先聯(lián)系Consistency Level定義的節(jié)點(diǎn)，發(fā)送請求到最快響應(yīng)的復(fù)制節(jié)點(diǎn)上，返回請求的數(shù)據(jù)。如果有多個節(jié)點(diǎn)被聯(lián)系，會在內(nèi)存比較每個復(fù)制節(jié)點(diǎn)傳過的數(shù)據(jù)行，如果不一致選取最近的數(shù)據(jù)（根據(jù)時(shí)間戳）返回給客戶端，并在后臺更新過期的復(fù)制節(jié)點(diǎn)，這個過程被稱作Read Repair。

Cassandra的數(shù)據(jù)整理

更新操作不會立即更新，這樣會導(dǎo)致隨機(jī)讀寫磁盤，效率不高，Cassandra會把數(shù)據(jù)順序?qū)懭氲揭粋€新的SSTable，并打上一個時(shí)間戳以標(biāo)明數(shù)據(jù)的新舊。它也不會立馬做刪除操作，而是用Tombstone來標(biāo)記要刪除的數(shù)據(jù)。Compaction時(shí)，將多個SSTable文件中的數(shù)據(jù)整合到新的SSTable文件中，當(dāng)舊SSTable上的讀請求一完成，會被立即刪除，空余出來的空間可以重新利用。
雖然Compcation沒有隨機(jī)的IO訪問，但還是一個重量級的操作，一般在后臺運(yùn)行，并通過限制它的吞吐量來控制，`compaction throughput mb per sec參數(shù)可以設(shè)置，默認(rèn)是16M/s。另外，如果key cache顯示整理后的數(shù)據(jù)是熱點(diǎn)數(shù)據(jù)，操作系統(tǒng)會把它放入到page cache里以提升性能。簡單來說，它的合并的策略有兩種。
1、SizeTieredCompactionStrategy ：每次更新不會直接更新原來的數(shù)據(jù)，這樣會造成隨機(jī)訪問磁盤，性能不高，而是在插入或更新直接寫入下一個sstable，這樣是順序?qū)懭胨俣确浅？欤m合寫敏感的操作。但是，因?yàn)閿?shù)據(jù)分布在多個sstable，讀取時(shí)需要多次磁盤尋道，讀取的性能不高。為了避免這樣情況，會定期在后臺將相似大小的sstable進(jìn)行合并，這個合并速度也會很快，默認(rèn)情況是4個sstable會合并一次，合并時(shí)如果沒有過期的數(shù)據(jù)要清理掉，會需要一倍的空間，因此最壞情況需要50%的空閑磁盤。
2、LeveledCompactionStrategy：創(chuàng)建固定大小默認(rèn)是5M的sstable，最上面一級為L0下面為L1，下面一層是上面一層的10倍大小。這種整理策略讀取非常快，適合讀敏感的情況，最壞只需要10%的空閑磁盤空間，它參考了LevelDB的實(shí)現(xiàn)。

后記
從Demo搭建到擴(kuò)展到生產(chǎn)環(huán)境上，充分體驗(yàn)到了Cassandra的易用和可擴(kuò)展性。它極大降低了環(huán)境的配置和解決問題之間的運(yùn)維時(shí)間，能把更多的時(shí)間轉(zhuǎn)到實(shí)際開發(fā)中。