今天看了一下Cassandra，安裝運行起來還是很簡單的。Cassandra中的4個結構如下：

Column是Cassandra中最小的單元：{name，value，timestamp}。

SuperColumn（那么對應的value有一組值）：{name，value：{{}，{}，{}...}}。

ColumnFamily可以看做數據庫中的表：{key1：{{}，{}...}，key2：{{}，{}....}...}。

KeySpace（我對這個的理解是從字面上猜的），每個KeySpace可以包括多個表（ColumnFamily）。

在cassandra.thrift文件中定義了各種程序和Cassandra交互的數據結構。一點題外話：Thrift是一種可伸縮的跨語言服務的發展軟件框架。它結合強大的軟件堆棧的代碼生成引擎，以建設服務，工作效率和無縫地與C++、C#、Java、Python、PHP和Ruby組合。允許定義一個簡單的定義文件中數據類型和服務接口。以作為輸入文件，編譯器生成代碼用來方便地生成RPC客戶端和服務器通信的無縫跨編程語言。一個簡單的流程吧。

用地址、端口初始化TSocket。

將用戶傳入的對象轉化為相應的Column。

cassandraClient.batch_mutate將數據發送給Cassandra。

Cassandra對一致性哈希的實現：

個人理解：普通的哈希是根據key對集群數量取模，然后根據這個值來判斷在哪個服務器上。這是如果其中的一個服務器掛掉了，那么就調整這個的均衡負載方法很麻煩。但是如果是根據key在一個圓圈上取值的話，那就沿著找一個或者的節點（除非所有的節點都掛掉，不然總能找到）。

每個節點都對應一個唯一的Token。

一個節點負責處理一致性哈希圓環中的一段數據保存為Range。

Partitioner用于管理Token在一致性哈希圓環中的生成規則，并且決定每一臺機器中SSTable數據的排序規則。其中5種不同的實現：

用MD5生成Token，Token的排序規則和BigTable的排序規則相同。

轉換為UTF-8編碼的字符串，Token的排序規則與String的排序規則相同。

生成LocalToken，排序規則與AbstractType的排序規則相同。

轉化成ButesToken，排序規則與byte的排序規則相同。

與2轉化方法相同，但是排序順序與4相同。

Gossip：

消息在網絡中的傳播類似于流行病在易感人群中傳播的方式。節點N將消息m隨機地發送給B個鄰居。Gossip在初始化的時候構造四個集合：存活的節點、失效的節點、種子節點、各個節點信息。

從存活的節點中隨機選擇一個節點發送GossipDigestSynMessage。

根據一定概率從失效節點中隨機選擇一個節點發送GossipDigestSynMessage。

如果之前發送GossipDigestSynMessage消息的節點中不包括種子幾點，或者當前活著的節點數少于種子節點數則隨機想一個種子節點發送GossipDigestSynMessage消息。

GossipDigestSynMessage中包括所有節點的地址、心跳版本號和節點狀態版本號。接收到消息的節點將進行以下操作：

根據接收到的GossipDigest集合調用FailureDetector的report方法更新集群鎮南關節點的狀態。

對收到的GossipDigestSynMessage消息中的GossipDigest進行排序。

對比接收到的GossipDigest信息與本節點的GossipDigest差異，本節點需要進一步獲取的節點信息由deltaGossipDigestList保存，本節點需要告訴發送GossipDigest信息節點的信息由deltaEpStateMap保存。

利用deltaGossipDigestList和deltaEpStateMap構建GossipDigestAckMessage，并將其發送給發送GossipDigestSynMessage消息的節點。

然后就開始處理GossipDigestAckMessage消息：

在本地更新GossipDigestAckMessage消息中包含需要本節點更新的節點信息，并調用FailureDetector的report方法更新集群中節點的狀態。

將發送GossipDigestAckMessage消息的節點需要的其他節點的信息構成GossipDigestAck2Message消息。

將GossipDigestAck2Message發送給發送GossipDigestAckMessage消息的節點。

最后是GossipDigestAck2Message消息的處理：在本地更新GossipDigestAck2Message消息中包含需要本節點更新的節點信息并調用FailureDetector的report方法更新集群中節點的狀態。

怎么感覺這個過程有點像TCP中的三次握手。。。

數據備份

在數據備份的時候需要考慮節點位置上的關系，EndpointSnitch根據需要由近到遠排列地址。有四種實現方法：

SimpleSnitch：對節點距離排序。

PropertyFileSnitch：為每一個節點的地址指定對應的數據中心和機架的名稱，對節點排序也會考慮數據中心和機架的因素。

RackInferringSnitch：與PropertyFileSnitch相似，不同的地方在于判斷節點所屬機架和數據中心的邏輯。

DynamicEndpointSnitch：在前面三種的基礎上，記錄節點與節點之間通信的時間間隔... ...

通過ReplicationStrategy可以知道任意一份數據備份的節點信息，同時在節點失效的時候，能夠計算出應該接收HINT消息的節點。Cassantra中的三種實現ReplicationStrategy的機制：

SimpleStrategy：根據一致性哈希圈中按順時針方向找出下N個需要備份的節點。

OldNetworkTopologyStrategy：與SimpleStrategy不同的是在選擇第二個備份節點時找和第一個節點不在同一個數據中心的，選第三個時選擇第二個節點在同一個數據中心但不在同一個機架的，剩下的就和SimpleStrategy一樣了。

NetworkTopologyStrategy：在OldNetworkTopologyStrategy的基礎上，指定一個數據中心需要備份的數據份數。如果在一個數據中心要存多份會盡可能讓他們在不同的機架上。

集群狀態的變化機制

在Cassandra中，如果節點之間通過Gossiper協議發現集群中的狀態發生了變化，將以事件的形式通知這些事件的訂閱者。

StorageLoadBalancer能夠計算集群中每一個節點的負載，并提供Cassandra集群的負載均衡。每當集群狀態發生變化的時候StorageLoadBalancer就將節點負載變化傳播下去。StorageService抽象整個Cassandra集群的關系，可以通過它來管理整個集群。MigrationManager用于動態改變Schema。

轉載于:https://www.cnblogs.com/ggzwtj/archive/2011/07/20/2112045.html

總結

以上是生活随笔為你收集整理的Cassandra的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。