Vnodes簡短歷史
Vnodes又叫Virtual Nodes，是Cassandra在1.2版本里引入的功能，已經在生產環境中使用了近8年了，從2.0版本開始，因為默認配置里num_tokens一般會設成256，所以如果你沒有修改過默認引數，那很有可能你一直都在使用這個功能，
當初引入vnodes主要是為了改善增加節點時的靈活性，在pre-1.2時代（也就是沒有vnodes功能的時候），每次集群擴容都必須要讓節點數翻倍，比如3個節點擴容到6個節點，下次需要擴容的時候再增加到12個節點，這是因為每個節點都只擁有一個token范圍，增加新節點的時候就是把每個token范圍一分為二，讓每個新節點都負責一半的token范圍，但是，如果要保證整個集群的token范圍是均勻分布的，每次新增加的節點數需要跟已有的節點數一致，這樣每次翻倍的擴容方式顯然對運維和資源計劃造成了很大的挑戰，
有了vnodes以后，默認情況下每個物理節點會負責256個token范圍，增加一個新的節點只需要從每個已有節點的256個token范圍中取出若干個，合起來湊成256個新token范圍分配給新來的節點就好了，整個集群的token范圍分布還是均勻的，
Vnodes功能在1.2版推出以后，受到了廣大生產環境Cassandra運維人員的歡迎，所以在2.0版里，vnodes功能被默認啟用，而且這個num_tokens引數默認的被配置成了256，
Vnodes帶來的問題
可是，隨著越來越多的Cassandra集群開始在生產環境里使用vnodes，它的一些不盡如人意的地方逐漸開始體現出來，
最大的一個問題，體現在運行nodetool repair的時候：因為repair是按照節點的token范圍來安排一個個的小任務，以進行副本之間的比較和修復作業；一個節點擁有的token范圍的數量越多，這樣的小任務就越多；當一個節點擁有了256個token范圍，并且存盤了幾百GB資料的時候，每個keyspace的repair小任務加起來所花的時間動輒就會達到幾小時甚至數天；生產環境中一般會有幾個keyspace，再加上nodetool repair -pr需要10天之內在所有的節點上都運行一輪，這會對運維帶來比較大的困難，
另外，當一個節點擁有了256個token范圍時，增加新節點的bootstrap程序也會帶來多得多的SSTable數量，需要消耗大量的CPU才能把這些大量的小SSTable消化掉，
比較棘手的是，這些問題并不是簡單的在配置中降低num_tokens取值就可以解決的，把num_tokens設定成一個更小的值比如16，當然會大大改善repair和bootstrap，但是這樣面臨著兩個主要的挑戰：
- Cassandra 1.2原有的vnodes演算法設計一般假設每個節點會有數百個token范圍，使用的是隨機重新分配的演算法，token范圍數量多的時候沒問題，但是token范圍數量降低到十幾個的時候，很容易出現資料不均勻分配的情況(如下圖所示)，而且節點增加的越多，這種不均勻的現象會越嚴重；
- 一個資料中心的vnodes數量在資料中心初始化的時候就確定了，將來想要改的話，只能啟用新的資料中心遷移資料，
Datacenter: us-east-1 ===================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 172.1*.3*.1* 1.55 TiB 16 4.1% f683ab0e-a687-400f-80fb-28f7b4471ffc b UN 172.1*.3*.1** 1.05 TiB 16 2.9% 2097cd01-4161-44a9-a944-d5445e8c5e02 c UN 172.1*.3*.2* 720.26 GiB 16 3.0% e6593e3a-bb1c-499c-a99b-73781cfcd076 c UN 172.1*.3*.2* 1.3 TiB 16 4.0% 99670a7c-a55f-4a43-8e4b-a3cccc71f08f a UN 172.1*.3*.1** 961.67 GiB 16 3.2% a4bb1648-3582-4f05-a1e6-3125e9c3c46c b UN 172.1*.3*.1** 1.29 TiB 16 4.4% 890e98d3-d88d-4d8c-89b4-7e9444bb69be a UN 172.1*.3*.2* 1.42 TiB 16 4.0% 3f2817da-9dc5-4122-8977-5d3d93669b4e c UN 172.1*.3*.1** 710.53 GiB 16 4.9% 72405162-f121-46d4-a220-a1fd2db868e8 b UN 172.1*.3*.3* 2.38 TiB 16 7.1% f15c768c-0175-4646-bc68-7b20a74d7f0d b UN 172.1*.3*.1** 2.68 TiB 16 7.3% 2f444803-7787-474a-9ed9-8555147023d3 c UN 172.1*.3*.1** 1.59 TiB 16 5.2% bd838966-23e2-44b2-986c-729ede679604 c UN 172.1*.3*.5* 808.48 GiB 16 4.3% 1fe83c82-1fb2-4570-9aae-7805370f24b0 b
新版本是怎樣解決問題的
針對上面提到的第一個挑戰，Cassandra 3.0里啟用了新的token分配演算法，并且增加了一個新的引數allocate_tokens_for_keyspace，這個貪心演算法雖然不能完全避免token范圍熱點的情況出現，但是它的最大好處是，在集群中繼續增加節點的話，token范圍的熱點會越來越少，資料分配會越來越均勻，
Cassandra 4.0在此基礎之上又做了更多的改進，3.0里的引數allocate_tokens_for_keyspace將被allocate_tokens_for_local_replication_factor取代，這樣配置的作業更加簡單，因為不再需要在初始化一個資料中心的時候提供一個keyspace的名字，
有了這樣演算法的加持，社區也逐漸開始建議所有用戶在新建資料庫的時候，把num_tokens引數直接改成一個比256小得多的取值，最新的討論可以看這個JIRA和這個郵件串列的討論，社區現在達成的共識是在4.0版本中把默認的num_tokens設定成16，并且默認啟用新的token分配演算法，如果4.0 release測驗程序不再發現新的問題，在4.0正式版發布以后，所有運行新版本的集群將會是每節點擁有16個token范圍，以兼顧運維操作的高效，和資料分配的均勻，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/5502.html
標籤：NoSQL
上一篇：軟體架構師都做些什么