在本章中，我們將構建第一個集羣，並查看配置Cassandra的可用選項。開箱即用，Cassandra完全沒有配置;您可以簡單地下載和解壓縮，然後執行程序以使用其默認配置啓動服務器。然而，使Cassandra成爲如此強大的技術的一個原因是它強調可配置性和定製。與此同時，選項的數量一開始可能會讓人感到困惑。
我們將關注影響集羣中節點行爲的Cassandra方面以及分區，故障和複製等元操作。性能調優和安全性是在第12章和第13章中得到自己處理的其他配置主題。
Cassandra集羣管理
爲了練習構建和配置集羣，我們將利用名爲Cassandra Cluster Manager或ccm的工具。該工具由Sylvain Lebresne和其他幾個貢獻者構建，是一組Python腳本，允許您在一臺計算機上運行多節點集羣。這使您可以快速配置羣集，而無需配置其他硬件。
該工具可在GitHub上獲得。一個快速入門的方法是使用Git克隆存儲庫。我們將打開一個終端窗口並導航到我們要創建克隆的目錄並運行以下命令：
$ git clone https://github.com/pcmanus/ccm.git
然後我們可以使用管理級權限運行安裝腳本：
$ sudo ./setup.py install
我們在這裏提供了一個簡化的指令視圖，用於開始使用ccm。您需要檢查網頁上的依賴關係以及Windows和MacOS X等平臺的特殊說明。由於ccm是一個積極維護的工具，因此這些細節可能會隨着時間的推移而發生變化。
一旦安裝了ccm，它應該在系統路徑上。要獲取支持的命令列表，可以鍵入ccm或ccm -help。如果需要有關特定羣集命令的選項的更多信息，請鍵入ccm -h。在創建和配置集羣時，我們將在以下部分中使用其中的幾個命令。
您可以深入瞭解Python腳本文件，以瞭解有關ccm正在執行的操作的更多信息。您還可以直接從自動化測試套件調用腳本。
創建羣集
您可以在一臺計算機上運行Cassandra，這在您學習如何讀取和寫入數據時很適合入門。但Cassandra專門設計用於許多機器的集羣，這些機器可以在非常大量的情況下共享負載。在本節中，我們將瞭解使多個Cassandra實例在一個環中相互通信所需的配置。用於配置羣集中每個節點的密鑰文件是cassandra.yaml文件，您可以在Cassandra安裝下的conf目錄中找到該文件。
配置集羣的關鍵值是集羣名稱，分區程序，告警和種子節點。參與羣集的所有節點中的羣集名稱，分區程序和snitch必須相同。對於整個羣集中的每個節點，種子節點並不嚴格要求完全相同，但這樣做是個好主意;我們將立即瞭解配置的最佳實踐。
Cassandra集羣的名稱是爲了防止一個集羣中的計算機加入另一個集羣，而不希望它們成爲其中的一部分。 cassandra.yaml文件中默認集羣的名稱是“Test Cluster”。您可以通過更新cluster_name屬性來更改集羣的名稱 - 只需確保在要參與此節點的所有節點上完成此操作簇。
如果您已將數據寫入現有的Cassandra集羣，然後更改集羣名稱，Cassandra會在嘗試在啓動時讀取數據文件時發出集羣名稱不匹配錯誤警告您，然後它將關閉。
讓我們嘗試使用ccm創建一個集羣：
$ ccm create -v 3.0.0 -n 3 my_cluster --vnodes
Downloading http://archive.apache.org/dist/cassandra/3.0.0/
apache-cassandra-3.0.0-src.tar.gz to
/var/folders/63/6h7dm1k51bd6phvm7fbngskc0000gt/T/
ccm-z2kHp0.tar.gz (22.934MB)
24048379 [100.00%]
Extracting /var/folders/63/6h7dm1k51bd6phvm7fbngskc0000gt/T/
ccm-z2kHp0.tar.gz as version 3.0.0 ...
Compiling Cassandra 3.0.0 ...
Current cluster is now: my_cluster
此命令根據我們選擇的Cassandra版本創建一個集羣 - 在本例中爲3.0.0。 該羣集名爲my_cluster，有三個節點。 我們指定要使用虛擬節點，因爲ccm默認創建單個令牌節點。 ccm將我們的集羣指定爲將用於後續命令的當前集羣。 您會注意到ccm下載了請求運行的版本的源並進行編譯。 這是因爲ccm需要對Cassandra源進行一些小的修改，以支持在一臺機器上運行多個節點。 我們也可以使用我們在第3章中下載的源代碼副本。如果您想研究創建集羣的其他選項，請運行命令ccm create -h。
一旦我們創建了集羣，我們就可以看到它是我們集羣列表中的唯一集羣（並標記爲默認集羣），我們可以瞭解它的狀態：
$ ccm list
*my_cluster
$ ccm status
Cluster: 'my_cluster'
---------------------
node1: DOWN (Not initialized)
node3: DOWN (Not initialized)
node2: DOWN (Not initialized)
此時，沒有任何節點已初始化。 讓我們啓動我們的集羣，然後再次檢查狀態：
$ ccm start
$ ccm status
Cluster: 'my_cluster'
---------------------
node1: UP
node3: UP
node2: UP
這相當於使用bin / cassandra腳本（或用於包安裝的service start cassandra）啓動每個單獨的節點。 要深入瞭解單個節點的狀態，我們將輸入以下命令：
$ ccm node1 status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 127.0.0.1 193.2 KB 256 ? e5a6b739-... rack1
UN 127.0.0.2 68.45 KB 256 ? 48843ab4-... rack1
UN 127.0.0.3 68.5 KB 256 ? dd728f0b-... rack1
這相當於在單個節點上運行命令nodetool status。 輸出顯示所有節點都已啓動並報告正常狀態（UN）。 每個節點都有256個令牌，並且沒有數據，因爲我們還沒有插入任何數據。 （爲簡潔起見，我們稍微縮短了主機ID。）
我們可以運行nodetool ring命令以獲取每個節點擁有的令牌列表。 要在ccm中執行此操作，請輸入以下命令：
$ ccm node1 ring
Datacenter: datacenter1
==========
Address Rack Status State ... Token
9205346612887953633
127.0.0.1 rack1 Up Normal ... -9211073930147845649
127.0.0.3 rack1 Up Normal ... -9114803904447515108
127.0.0.3 rack1 Up Normal ... -9091620194155459357
127.0.0.1 rack1 Up Normal ... -9068215598443754923
127.0.0.2 rack1 Up Normal ... -9063205907969085747
該命令要求我們指定一個節點。 這不會影響輸出; 它只是指示節點nodetool連接到哪個節點以獲取環信息。 如您所見，令牌在我們的三個節點中隨機分配。 （和以前一樣，爲簡潔起見，我們縮寫了輸出並省略了Owns和Load列。）
有趣的是，瞭解ccm所做的配置更改，以便在本地計算機上運行集羣。 默認情況下，ccm將羣集的元數據和配置文件存儲在主目錄下名爲.ccm的目錄中; 它還使用此目錄存儲您運行的Cassandra版本的源文件。 我們來看看這個目錄，看看我們在那裏可以找到什麼：
$ cd ~/.ccm; ls
CURRENT my_cluster repository
存儲庫目錄包含ccm下載的源。 深入瞭解my_cluster目錄，我們將看到每個節點的目錄：
$ cd my_cluster; ls
cluster.conf node1 node2 node3
cluster.conf文件包含我們在創建集羣時選擇的選項列表。 要查看節點之間不同的配置選項，請嘗試使用diff命令比較目錄的內容。 例如：
$ cd ~/.ccm/my_cluster
$ diff node1/conf/ node2/conf/
輸出突出顯示配置文件中的差異，包括用於存儲數據的目錄，提交日誌和輸出日誌，用於網絡通信的偵聽和RPC地址，以及爲遠程管理公開的JMX端口。在我們繼續本章的其餘部分時，我們將更詳細地研究這些設置。
種子節點
集羣中的新節點需要所謂的種子節點。種子節點用作其他節點的聯繫點，因此Cassandra可以瞭解羣集的拓撲結構 - 即主機具有哪些範圍。例如，如果節點A充當節點B的種子，則當節點B聯機時，它將使用節點A作爲從中獲取數據的參考點。此過程稱爲自舉或有時自動引導，因爲它是Cassandra自動執行的操作。種子節點不會自動引導，因爲假定它們將是羣集中的第一個節點。
默認情況下，cassandra.yaml文件只有一個種子條目設置爲localhost：
- seeds: "127.0.0.1"
要向集羣添加更多種子節點，我們只需添加另一個種子元素。 我們可以通過指示節點的IP地址或主機名來將多個服務器設置爲種子。 舉個例子，如果我們查看一個ccm節點的cassandra.yaml文件，我們會發現以下內容：
- seeds: 127.0.0.1, 127.0.0.2, 127.0.0.3
在生產羣集中，這些將是其他主機的IP地址，而不是環回地址。爲了確保Cassandra的自舉過程的高可用性，每個數據中心至少有兩個種子節點被認爲是最佳實踐。如果在數據中心之間的網絡分區期間其中一個本地種子節點發生故障，則這增加了使至少一個種子節點可用的可能性。
您可能已經注意到，如果查看cassandra.yaml文件，種子列表實際上是種子提供程序的更大定義的一部分。 org.apache.cassandra.locator.SeedProvider接口指定必須實現的合同。 Cassandra提供SimpleSeedProvider作爲默認實現，它從cassandra.yaml文件加載種子節點的IP地址。
Partitioners
分區程序的目的是允許您指定分區鍵的排序方式，這對數據在節點中的分佈方式有重大影響。它還會影響查詢行範圍的選項。您可以通過更新cassandra.yaml文件中partitioner屬性的值來設置分區程序。您可以使用幾種不同的分區程序，我們現在看一下。
將數據插入羣集後，無法更改分區程序，因此在偏離默認值之前請務必小心！
Murmur3分區
默認分區程序是org.apache.cassandra.dht.Murmur3Partitioner。 Murmur3Partitioner使用雜音哈希算法生成令牌。這樣做的好處是可以在整個羣集中均勻地分佈密鑰，因爲分佈是隨機的。它具有導致低效範圍查詢的缺點，因爲指定範圍內的密鑰可能被放置在環中的各種不同位置，並且密鑰範圍查詢將以基本上隨機的順序返回數據。
通常，新羣集應始終使用Murmur3Partitioner。但是，Cassandra提供了幾個較舊的分區程序以實現向後兼容。
隨機分區
隨機分區程序由org.apache.cassandra.dht.RandomPartitioner實現，是Cassandra在Cassandra 1.1及更早版本中的默認設置。它使用BigIntegerToken並應用MD5加密哈希來確定將鍵放置在節點環上的位置。雖然RandomPartitioner和Murmur3Partitioner都基於隨機散列函數，但RandomPartitioner使用的加密散列要慢得多，這就是爲什麼Murmur3Partitioner將其替換爲默認值。
Order-Preserving Partitioner
保留訂單的分區程序由org.apache.cassandra.dht.OrderPreservingPartitioner實現。使用這種類型的分區器，令牌是基於密鑰的UTF-8字符串。因此，行按鍵順序存儲，將數據的物理結構與排序順序對齊。配置列族以使用順序保留分區（OPP）允許您執行範圍切片。
值得注意的是，OPP對範圍查詢的效率不如隨機分區 - 它只是提供排序。它的缺點是創建一個可能非常不平衡的環，因爲實際數據通常不是均勻寫入的。例如，考慮在Scrabble遊戲中分配給字母的值。 Q和Z很少使用，因此它們具有很高的價值。使用OPP，您最終可能會在某些節點上獲得大量數據，而在其他節點上獲得的數據則更少。存儲大量數據的節點，使得環不平衡，通常被稱爲熱點。由於訂購方面，用戶有時會被OPP吸引。但是，在實踐中使用OPP意味着您的運營團隊需要使用nodetool loadbalance或移動操作更頻繁地手動重新平衡節點。由於這些因素，不鼓勵使用訂單保留分區程序。相反，使用索引。
ByteOrderedPartitioner
ByteOrderedPartitioner是一個保持順序的分區程序，它將數據視爲原始字節，而不是像保留順序的分區程序和整理順序保留分區程序那樣將它們轉換爲字符串。如果您需要一個不將密鑰驗證爲字符串的訂單保留分區程序，建議使用BOP來提高性能。
雖然Murmur3Partitioner隨機選擇令牌，但它仍然可能對熱點敏感;但是，與訂單保留分區器相比，問題顯着減少。事實證明，爲了最小化熱點，需要額外的拓撲知識。 3.0中添加了對令牌選擇的改進以解決此問題。使用特定鍵空間的名稱在cassandra.yaml中配置allocate_ tokens_ keyspace屬性可指示分區程序根據該鍵空間的複製策略優化令牌選擇。這在羣集具有單個鍵空間或所有鍵空間具有相同複製策略的情況下最有用。從3.0版本開始，此選項僅適用於Murmur3Partitioner。
Snitches
飛賊的工作只是確定相對主機的接近程度。 Snitches收集有關您的網絡拓撲的一些信息，以便Cassandra可以有效地路由請求。金色飛賊將弄清楚節點與其他節點的關係。推斷數據中心是複製策略的工作。您可以通過更新cassandra.yaml文件中的endpoint_snitch屬性來配置要使用的端點snitch實現。
Simple Snitch
默認情況下，Cassandra使用org.apache.cassandra.locator.SimpleSnitch。這個小故障不是機架感知（這個術語我們將在一分鐘內解釋），這使得它不適合多數據中心部署。如果您選擇使用此snitch，則還應該爲鍵空間使用SimpleStrategy複製策略。
Property File Snitch
org.apache.cassandra.locator.PropertyFileSnitch是所謂的機架感知小部件，這意味着它在名爲cassandra-topology.properties的標準Java密鑰/值屬性文件中使用您提供的有關集羣拓撲的信息。 cassandra-topology.properties的默認配置如下所示：
# Cassandra Node IP=Data Center:Rack
192.168.1.100=DC1:RAC1
192.168.2.200=DC2:RAC2
10.0.0.10=DC1:RAC1
10.0.0.11=DC1:RAC1
10.0.0.12=DC1:RAC2
10.20.114.10=DC2:RAC1
10.20.114.11=DC2:RAC1
10.21.119.13=DC3:RAC1
10.21.119.10=DC3:RAC1
10.0.0.13=DC1:RAC2
10.21.119.14=DC3:RAC2
10.20.114.15=DC2:RAC2
# default for unknown nodes
default=DC1:r1
在這裏，我們看到有三個數據中心（DC1，DC2和DC3），每個數據中心都有兩個機架（RAC1和RAC2）。此處未標識的任何節點將被假定爲默認數據中心和機架（DC1，r1）。
如果您選擇使用此snitch或其他一個支持機架的小部件，則這些機架和數據名稱將用於爲每個數據中心配置NetworkTopologyStrategy設置以用於密鑰空間複製策略。
更新此文件中的值以記錄羣集中的每個節點，以指定哪個機架包含具有該IP的節點以及它所在的數據中心。雖然如果您希望添加或刪除具有某些頻率的節點，這似乎很難維護，請記住它是一種替代方案，它可以帶來一點靈活性和易維護性，以便爲您提供更多控制和更好的運行時性能，因爲Cassandra無需弄清楚節點的位置。相反，你只需告訴它們在哪裏。
Gossiping Property File Snitch
org.apache.cassandra.locator.GossipingPropertyFileSnitch是另一個機架感知的小故障。數據通過八卦與其他節點交換有關其自己的機架和數據中心位置的信息。機架和數據中心位置在cassandra-rackdc.properties文件中定義。 GossipingPropertyFileSnitch還使用cassandra-topology.properties文件（如果存在）。
Rack Inferring Snitch
org.apache.cassandra.locator.RackInferringSnitch假定羣集中的節點以一致的網絡方案佈局。它通過簡單地比較每個節點的IP地址中的不同八位字節來操作。如果兩個主機在其IP地址的第二個八位字節中具有相同的值，則確定它們位於同一數據中心。如果兩個主機在其IP地址的第三個八位字節中具有相同的值，則確定它們位於同一個機架中。 “決定是”真的意味着Cassandra必須根據您的服務器如何位於不同的VLAN或子網中進行猜測。
Cloud Snitches
Cassandra附帶了幾個設計用於雲部署的小故障：
-
org.apache.cassandra.locator.Ec2Snitch和Ec2MultiRegionSnitch設計用於Amazon的Elastic Compute Cloud（EC2），它是Amazon Web Services（AWS）的一部分。 Ec2Snitch對於單個AWS區域中的部署或區域位於同一虛擬網絡上的多區域部署非常有用。 Ec2MultiRegionSnitch專爲多區域部署而設計，其中區域通過公共互聯網連接。
-
org.apache.cassandra.locator.GoogleCloudSnitch可用於Google Cloud Platform上的一個區域或多個區域。
-
org.apache.cassandra.locator.CloudstackSnitch旨在用於基於Apache Cloudstack項目的公共或私有云部署。
EC2和Google Cloud snitch使用cassandra-rackdc.properties文件，其中機架和數據中心命名約定因環境而異。我們將在第14章重溫這些故障。
Dynamic Snitch
正如我們在第6章中討論的那樣，Cassandra使用org.apache.cassandra.locator.DynamicEndpointSnitch包裝您選擇的snitch，以便爲查詢選擇性能最高的節點。 dynamic_snitch_badness_threshold屬性定義用於更改首選節點的閾值。默認值0.1表示首選節點必須比最快節點執行10％以便丟失其狀態。動態snitch根據dynamic_snitch_update_interval_in_ms屬性更新此狀態，並在dynamic_snitch_reset_interval_in_ms屬性指定的持續時間內重置其計算。重置間隔應該比更新間隔長得多，因爲它是一個更昂貴的操作，但它確實允許節點重新獲得其首選狀態，而不必證明性能優於不良閾值。
節點配置
除了我們之前討論過的與集羣相關的設置外，還有許多其他屬性可以在cassandra.yaml文件中設置。我們將在本章中查看與網絡和磁盤使用相關的一些要點，並在第12章和第13章中保存其他一些用於處理的內容。
我們建議您查看適用於您的版本的DataStax文檔，該文檔提供了有關配置cassandra.yaml文件中各種設置的有用指南。本指南從最常配置的設置構建到更高級的配置選項。
令牌和虛擬節點
默認情況下，Cassandra配置爲使用虛擬節點（vnodes）。給定節點將服務的令牌數由num_tokens屬性設置。通常，這應保留爲默認值（當前爲256，但請參閱後面的註釋），但可以增加以將更多令牌分配給功能更強的計算機，或者減少將更少的令牌分配給功能較弱的計算機。
許多Cassandra專家已經開始建議將默認的num_tokens從256更改爲32.他們認爲每個節點有32個令牌可以在令牌範圍之間提供足夠的平衡，同時需要更少的帶寬來維護。在將來的版本中查找對此默認值的可能更改。
要禁用vnode並配置更傳統的令牌範圍，您首先需要將num_tokens設置爲1，或者您也可以完全註釋掉該屬性。然後，您還需要設置initial_token屬性以指示該節點將擁有的標記範圍。對於羣集中的每個節點，這將是不同的值。
3.0之前的Cassandra版本提供了一個名爲令牌生成器的工具，您可以使用該工具計算集羣中節點的初始令牌值。例如，讓我們爲包含三個節點的單個數據中心的集羣運行它：
$ cd $CASSANDRA_HOME/tools/bin
$ ./token-generator 3
DC #1:
Node #1: -9223372036854775808
Node #2: -3074457345618258603
Node #3: 3074457345618258602
對於具有多個數據中心的配置，只需提供與每個數據中心中的節點數相對應的多個整數值。 默認情況下，令牌生成器爲Murmur3Partitioner生成初始令牌，但它也可以使用–random選項爲RandomPartitioner生成令牌。 如果您決定使用初始令牌並且您的版本中沒有令牌生成器，則可以在http://www.geroba.com/cassandra/cassandra-token-calculator上找到一個方便的計算器。
通常，強烈建議使用vnodes，因爲在添加或刪除單令牌節點時需要額外計算令牌和重新平衡羣集所需的手動配置步驟。
網絡接口
cassandra.yaml文件中有幾個屬性，這些屬性與用於與客戶端和其他節點通信的端口和協議方面的節點組網相關：
$ cd ~/.ccm
$ find . -name cassandra.yaml -exec grep -H 'listen_address' {} \;
./node1/conf/cassandra.yaml:listen_address: 127.0.0.1
./node2/conf/cassandra.yaml:listen_address: 127.0.0.2
./node3/conf/cassandra.yaml:listen_address: 127.0.0.3
如果您更喜歡通過接口名稱綁定，則可以使用listen_interface屬性而不是listen_address。例如，listen_interface = eth0。您可能無法設置這兩個屬性。
storage_port屬性指定用於節點間通信的端口，通常爲7000.如果您將在遍歷公共網絡的網絡環境中使用Cassandra，或者在雲部署中使用多個區域，則應配置ssl_storage_port（通常爲7001）。配置安全端口還需要配置節點間加密選項，我們將在第14章中討論。
從歷史上看，Cassandra支持兩種不同的客戶端接口：原始Thrift API，也稱爲遠程過程調用（RPC）接口，以及首先在0.8中添加的CQL接口，也稱爲本機傳輸。對於2.2版本，默認情況下支持並啓用這兩個接口。從3.0版本開始，默認情況下禁用Thrift，將來的版本將完全刪除。
start_native_transport屬性啓用或禁用本機傳輸，默認爲true。本機傳輸使用端口9042，由native_transport_port屬性指定。
cassandra.yaml文件包含一組用於配置RPC接口的類似屬性。 RPC默認爲端口9160，由rpc_port屬性定義。如果您有使用Thrift的現有客戶端，則可能需要啓用此接口。但是，鑑於自1.1以來CQL以其當前形式（CQL3）可用，您應該盡一切努力將客戶端升級到CQL。
有一個屬性rpc_keepalive，RPC和本機接口都使用它。默認值true表示Cassandra將允許客戶端跨多個請求保持連接打開。其他屬性可用於限制線程，連接和幀大小，我們將在第12章中介紹。
數據存儲
Cassandra允許您配置其各種數據文件存儲在磁盤上的方式和位置，包括數據文件，提交日誌和已保存的緩存。默認值是Cassandra安裝下的數據目錄（$ CASSANDRA_HOME / data或％CASSANDRA_HOME％/ data）。較舊的版本和一些Linux軟件包發行版使用目錄/ var / lib / cassandra / data。
您將從第6章中記得，提交日誌用作傳入寫入的短期存儲。當卡桑德拉收到更新時，每個寫入值都會以原始順序文件追加的形式立即寫入提交日誌。如果關閉數據庫或意外崩潰，則提交日誌可確保數據不會丟失那是因爲下次啓動節點時，會重放提交日誌實際上，這是唯一一次讀取提交日誌;。客戶從不讀它但是對提交日誌的正常寫入操作會阻塞，因此會損壞性能以要求客戶端等待寫入完成。提交日誌存儲在commitlog_directory屬性指定的位置。
數據文件表示排序字符串表（SSTables）。與提交日誌不同，數據以異步方式寫入此文件.SSTables在主要壓縮期間定期合併以釋放空間。爲此，Cassandra將合併鍵，組合列並刪除墓碑。
數據文件存儲在data_file_directories屬性指定的位置。如果您願意，可以指定多個值，卡桑德拉會將數據文件均勻地分佈在它們之間。這就是卡桑德拉支持“只是一堆磁盤”或JBOD部署的方式，其中每個目錄代表不同的磁盤掛載點。
您無需更新的Windows的默認存儲文件位置，因爲的Windows將自動調整路徑分隔符並將它們放在C：\下當然，在真實環境中，如圖所示，分別指定它們是個好主意。
對於測試，您可能不需要更改這些位置。但是，在使用旋轉磁盤的生產環境中，建議您將數據文件和提交日誌存儲在不同的磁盤上，以獲得最佳性能和可用性。
Cassandra非常強大，可以在沒有整個節點關閉的情況下處理一個或多個磁盤的丟失，但是爲您提供了幾個選項來指定磁盤故障時節點的所需行爲。影響數據文件的磁盤故障行爲由disk_failure_policy屬性指定，而提交日誌的故障響應由commit_failure_policy指定。默認行爲停止是禁用客戶端接口，同時保持活動以通過JMX進行檢查。其他選項包括die，它完全停止節點（JVM退出）和ignore，這意味着記錄並忽略文件系統錯誤。建議不要使用ignore。 best_effort的附加選項可用於數據文件，允許對仍可用的磁盤上存儲的SSTable進行操作。
啓動和JVM設置
到目前爲止，我們在本章中花了大部分時間來檢查cassandra.yaml文件中的設置，但是我們還應該檢查其他配置文件。
Cassandra的啓動腳本體現了許多來之不易的邏輯，可以優化各種JVM選項的配置。要查看的密鑰文件是環境腳本conf / cassandra.env.sh（或Windows上的conf / cassandra.env.ps1 PowerShell腳本）。此文件包含用於配置JVM版本（如果系統上有多個版本），堆大小和其他JVM選項的設置。除了JMX設置之外，您很少需要更改其默認設置中的大多數選項。環境腳本允許您設置JMX端口並配置遠程JMX訪問的安全設置。
Cassandra的日誌記錄配置位於conf / logback.xml文件中。此文件包括日誌級別，郵件格式設置和日誌文件設置（包括位置，最大大小和輪換）等設置。 Cassandra使用Logback日誌框架，您可以在http://logback.qos.ch上了解更多信息。在2.1版本中，日誌記錄實現已從Log4J更改爲Logback。
我們將在第10章和第12章中的JVM內存配置中更詳細地研究日誌記錄和JMX配置。
將節點添加到羣集
現在您已瞭解配置Cassandra集羣的每個節點的內容，您已準備好了解如何添加節點。正如我們已經討論過的，要手動添加新節點，我們需要爲新節點配置cassandra.yaml文件以設置種子節點，分區器，告警和網絡端口。如果您已選擇創建單個令牌節點，則還需要計算新節點的令牌範圍並調整其他節點的範圍。
因爲我們使用的是ccm，所以添加新節點的過程非常簡單。我們運行以下命令：
$ ccm add node4 -i 127.0.0.4 -j 7400
這將創建一個新節點node4，其中另一個環回地址和JMX端口設置爲7400.要查看此命令的其他選項，可以鍵入ccm add -h。 現在我們已經添加了一個節點，讓我們檢查一下我們集羣的狀態：
$ ccm status
Cluster: 'my_cluster'
---------------------
node1: UP
node3: UP
node2: UP
node4: DOWN (Not initialized)
新節點已添加但尚未啓動。 如果再次運行nodetool ring命令，您將看到沒有對令牌進行任何更改。 現在我們準備通過鍵入ccm node4 start來啓動新節點（在仔細檢查是否啓用了額外的環回地址之後）。 如果再次運行nodetool ring命令，您將看到類似於以下內容的輸出：
Datacenter: datacenter1
==========
Address Rack Status State ... Token
9218701579919475223
127.0.0.1 rack1 Up Normal ... -9211073930147845649
127.0.0.4 rack1 Up Normal ... -9190530381068170163
...
如果將其與之前的輸出進行比較，您會發現一些事情。 首先，令牌已經在所有節點上重新分配，包括我們的新節點。 其次，令牌值已經改變，代表較小的範圍。 爲了給我們的新節點提供256個令牌（num_tokens），我們現在在集羣中總共有1,024個令牌。
我們可以通過檢查日誌文件來觀察node4啓動時對其他節點的看法。 在獨立節點上，您可能會查看/ var / log / cassandra（或$ CASSANDRA_HOME / logs）中的system.log文件，具體取決於您的配置。 因爲我們正在使用ccm，所以我們可以使用一個方便的命令來檢查來自任何節點的日誌文件。 我們將使用以下命令查看node1日誌：ccm node1 showlog。 這將顯示類似於標準unix more命令的視圖，該命令允許我們翻閱或搜索日誌文件內容。 在接近結尾的日誌文件中搜索與gossip相關的語句，我們發現以下內容：
INFO [GossipStage:1] 2015-08-24 20:02:24,377 Gossiper.java:1005 –
Node /127.0.0.4 is now part of the cluster
INFO [HANDSHAKE-/127.0.0.4] 2015-08-24 20:02:24,380
OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.4
INFO [SharedPool-Worker-1] 2015-08-24 20:02:24,383
Gossiper.java:970 - InetAddress /127.0.0.4 is now UP
這些語句顯示node1與node4成功閒聊，並且node4被認爲是up並且是集羣的一部分。 此時，引導過程開始將令牌分配給node4，並將與這些令牌相關聯的任何數據流式傳輸到node4。
Dynamic Ring Participation
可以關閉Cassandra集羣中的節點並將其恢復，而不會中斷羣集的其餘部分（假設合理的複製因子和一致性級別）。 假設我們已經啓動了一個雙節點集羣，如前面“創建集羣”中所述。 我們可能會導致發生錯誤，從而關閉其中一個節點，然後確保羣集的其餘部分仍然正常。
我們將使用ccm node4 stop命令將我們的一個節點關閉來模擬這個。 我們可以運行ccm狀態來驗證節點是否已關閉，然後像我們之前通過命令ccm node1 showlog一樣檢查日誌文件。 檢查日誌文件，我們會看到如下所示的一些行：
INFO [GossipStage:1] 2015-08-27 19:31:24,196 Gossiper.java:984 -
InetAddress /127.0.0.4 is now DOWN
INFO [HANDSHAKE-/127.0.0.4] 2015-08-27 19:31:24,745
OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.4
現在我們重新啓動node4並重新檢查node1上的日誌。 果然，Cassandra已自動檢測到其他參與者已返回羣集並再次開始營業：
INFO [HANDSHAKE-/127.0.0.4] 2015-08-27 19:32:56,733 OutboundTcpConnection
.java:494 - Handshaking version with /127.0.0.4
INFO [GossipStage:1] 2015-08-27 19:32:57,574 Gossiper.java:1003 -
Node /127.0.0.4 has restarted, now UP
INFO [SharedPool-Worker-1] 2015-08-27 19:32:57,652 Gossiper.java:970 -
InetAddress /127.0.0.4 is now UP
INFO [GossipStage:1] 2015-08-27 19:32:58,115 StorageService.java:1886 -
Node /127.0.0.4 state jump to normal
node4的狀態跳轉到正常狀態表示它再次成爲集羣的一部分。 作爲最後的檢查，我們再次運行status命令，看到該節點已備份：
$ ccm status
Cluster: 'my_cluster'
---------------------
node1: UP
node2: UP
node3: UP
node4: UP
複製策略
雖然我們花了很多時間來了解我們的集羣和節點的各種配置選項，但Cassandra還提供了鍵空間和表的靈活配置。 這些值可以使用cqlsh訪問，也可以通過正在使用的客戶端驅動程序訪問，我們將在第8章中瞭解。
cqlsh> DESCRIBE KEYSPACE my_keyspace ;
CREATE KEYSPACE my_keyspace WITH replication =
{'class': 'SimpleStrategy',
'replication_factor': '1'} AND durable_writes = true;
durable_writes屬性允許您繞過寫入密鑰空間的提交日誌。此值默認爲true，表示將在修改時更新提交日誌。將值設置爲false會增加寫入速度，但如果在將數據從memtables刷新到SSTables之前節點出現故障，則還有丟失數據的風險。
選擇正確的複製策略很重要，因爲策略確定哪些節點負責哪些鍵範圍。這意味着您還要確定哪些節點應該接收哪些寫操作，這會對不同情況下的效率產生很大影響。如果您設置羣集，使所有寫入都轉到兩個數據中心 - 一個在澳大利亞，一個在弗吉尼亞州的雷斯頓 - 您將看到匹配的性能下降。選擇可插拔策略可以提供更大的靈活性，以便您可以根據網絡拓撲和需求調整Cassandra。
第一個副本將始終是聲明令牌落入範圍的節點，但其餘的副本將根據您使用的複製策略進行放置。
正如我們在第6章中學到的，Cassandra提供了兩種複製策略，SimpleStrategy和NetworkTopologyStrategy。
SimpleStrategy
SimpleStrategy將副本放置在單個數據中心中，其方式是不知道它們在數據中心機架上的位置。這意味着實現理論上很快，但是如果具有給定密鑰的下一個節點與其他節點位於不同的機架中則不行。如圖7-1所示。
這裏發生的是選擇環上的下N個節點來保存副本，而策略沒有數據中心的概念。圖中顯示了第二個數據中心，以突出該策略未意識到的事實。
NetworkTopologyStrategy
現在假設您希望在多箇中心之間傳播複製品，以防其中一個數據中心遭受某種災難性故障或網絡中斷。 NetworkTopologyStrategy允許您請求將某些副本放在DC1中，而某些副本放在DC2中。在每個數據中心內，NetworkTopologyStrategy在不同的機架上分發複製副本，因爲同一機架（或類似的物理分組）中的節點通常由於電源，冷卻或網絡問題而同時發生故障。
NetworkTopologyStrategy按如下方式分發副本：根據所選分區器替換第一個副本。通過遍歷環中的節點放置後續副本，跳過同一機架中的節點，直到找到另一個機架中的節點。該過程重複進行其他複製，將它們放在單獨的機架上。將副本放置在每個機架中後，跳過的節點將用於放置副本，直到滿足複製因子。
NetworkTopologyStrategy允許您爲每個數據中心指定複製因子。因此，將存儲的副本總數等於每個數據中心的複製因子的總和。 NetworkTopologyStrategy的結果如圖7-2所示。
細心的觀察者會注意到Cassandra實際上有兩個額外的複製策略：OldNetworkTopologyStrategy和LocalStrategy。
OldNetworkTopologyStrategy類似於網絡拓撲策略，因爲它將副本放置在多個數據中心中，但其算法不太複雜。它將第二個副本放置在與第一個，第三個副本位於第一個數據中心的不同機架中的不同數據中心中，以及通過遍歷環上的後續節點放置任何剩餘的副本。
LocalStrategy保留給Cassandra自己的內部使用。顧名思義，LocalStrategy僅在本地節點上保留數據，並且不會將此數據複製到其他節點。 Cassandra將此策略用於存儲有關本地節點和集羣中其他節點的元數據的系統密鑰空間。
更改複製因子
您可以通過cqlsh或其他客戶端更改現有鍵空間的複製因子。要使更改完全生效，您需要在每個受影響的節點上運行nodetool命令。如果增加羣集（或數據中心）的複製因子，請在羣集（或數據中心）中的每個節點上運行nodetool repair命令，以確保Cassandra生成其他副本。只要修復需要，一些客戶端可能會收到通知，如果數據連接到尚未包含數據的副本，則數據不存在。
如果減少羣集（或數據中心）的複製因子，請在羣集（或數據中心）中的每個節點上運行nodetool clean命令，以便Cassandra釋放與不需要的副本相關聯的空間。我們將在第11章中瞭解有關修復，清理和其他nodetool命令的更多信息。
作爲一般準則，您可以預期您的寫入吞吐量容量將是節點數除以複製因子。因此，在一個10節點的集羣中，通常每秒執行10,000次寫入，複製因子爲1，如果將複製因子增加到2，則可以期望每秒執行大約5,000次寫入。
總結
在本章中，我們研究瞭如何創建Cassandra集羣並向集羣添加其他節點。 我們學習瞭如何通過cassandra.yaml文件配置Cassandra節點，包括設置種子節點，分區器，snitch和其他設置。 我們還學習瞭如何爲鍵空間配置複製以及如何選擇適當的複製策略。