小 T 導讀：為什么我的集群數據分布得不均勻？這篇文章就是為了解決這個問題而寫的。但即便是沒有遇到“TDengine集群數據不均勻分布”這個現象的用戶，我們也推薦一讀。因為可能你目前只是在通用場景下使用集群，當一些特殊的場景出現時，深入地了解集群參數和數據庫架構原理才會真正地讓你做到游刃有余。至於集群如何搭建並不是本文主題，請嚴格根據官方文檔指示操作即可。
為了充分理解文章內容，首先大家一定要先了解vnode這個概念——每個 vnode 都是一個相對獨立的工作單元，是存儲時序數據（表）的基本單元，具有獨立的運行線程，內存空間與持久化存儲的路徑。
如果覺得不夠清晰的話，接着往下讀，隨着知識點的串聯，或許您會豁然開朗起來。現在，我們來根據不同的場景給出具體分析：
通常來說，數據分配不均勻有兩種。
場景一：表分布不均勻
需要測試表數量很少的數據庫性能時比較容易發生這個現象：你建了1200張表，但是卻發現有1000張表都在同一個vnode里面，只有200張表在另一個vnode里面。這種場景的壞處是，大部分表都進入了同一個vnode數據分布不均勻。此外還會導致只有兩個線程在為TDengine工作，因此無法利用計算機的多核（假設你的服務器CPU是雙核以上），從而浪費了TDengine的橫向擴展性。
我先來簡單說說導致上述情況的原因——在TDengine中有這樣三個參數：
-
maxVgroupsPerDb: 每個數據庫中能夠使用的最大vnode個數（單個副本），默認為0；
-
minTablesPerVnode: 每個vnode中必須創建的最小表數，即是說這是第一輪建表用的步長（就是滿多少表寫下一個vnode），默認1000；
-
tablelncStepPerVnode：每個vnode中超過最小表數后的遞增步長（即是后續滿多少表寫下一個vnode），默認1000。
在持續的建表過程中，TDengine就是靠這三個參數來控制表的分布的。大家可以在使用taosdemo批量建表的時候觀察一下：打開另一個taos窗口，在建表的時候一直輸入show vgroups命令，就能看到上述參數所控制的建表過程了：在第一個vnode中，表數量從0開始逐漸遞增，隨着數量達到minTablesPerVnode后，開始創建下一個vnode並繼續在其中建表。之后，重復該過程直到vnode數量達到maxVgroupsPerDb。之后，TDengine將回到第一個vnode繼續創建新表，在補充每個vnode的表數達到tablelncStepPerVnode數量后，后續以tablelncStepPerVnode為步長繼續在vnode中依次創建表，直到建完全部表。（描述看着繁瑣，自己動手跑一遍會很直觀）
明白了這個邏輯后，我們可以再來回頭看為什么會出現場景一的情況。答案已經很簡單了，因為minTablesPerVnode這個參數的值默認是1000，所以前1000個表肯定會只出現在第一個vnode里，這就給用戶造成了數據分配並不平均的錯覺。
那么要如何調整成我們預期的效果呢。
別急——在此之前我們還需要再多了解一下這個參數：maxVgroupsPerDb。
大家可能在taos.cfg中留意過maxVgroupsPerDb這個參數的值默認是0，根據參數描述，0代表的是自動配置。但是關於這個自動配置的詳情在官網上是有解釋的：“每個 Database 可以創建固定數目的 vgroup，默認與 CPU 核數相同，可通過 maxVgroupsPerDb 配置”。
如果不了解vgroup概念，建議到官網查看：
https://www.taosdata.com/cn/documentation/architecture
結合文章開頭說過的vnode概念——每個vnode都是具有獨立的運行線程的，這樣就一目了然了——如此設計默認值的原因就是希望vnode數等於cpu核數，從而充分地利用CPU資源，達到最大化服務器性能的目的。
好，現在我們終於可以回到場景一並提出我們的解決方案了。
假設我們是4核服務器，那么默認的最大vgroups就是為4個。進入場景一當中，每個vnode只要存儲300個表就好了。這時候只需要調整minTablesPerVnode值為300，這樣就可以做到表均勻分布在數據節點中了。
場景一屬於相對特殊的情況，而默認配置卻只能針對最通用的一個場景。對於大部分用戶來說，只要你的測試場景是創建萬表級別，都是可以看到表在vnode中按序且平均分配的。比如你有一台4核CPU的機器，計划創建4萬個表。那么使用默認配置就會生成4個vnode，最終的結果就是每個vnode存儲1萬張表，就不會出現數據不均的現象了。
這里我們可以多討論一下，既然默認配置的maxVgroupsPerDb是可以充分利用CPU的話。那么這個參數還有什么修改價值呢？如果沒有修改價值的話它為什么還會是一個對外公開的參數呢？
別急，我們接下來進入下一個場景。
假設你的CPU核數為4，但是我們把maxVgroupsPerDb設成8。其中只有前4個vnode的數據會比較熱，后續4個vnode中的數據的使用頻率則比較低。看似多開了很多vnode，但是這樣的設置和使用默認配置比起來，反而會降低前四個vnode的負擔從而增加性能。所以，默認參數雖然通用，但是有時候適當的修改會讓數據庫變得更好，這就需要使用者結合實際業務場景做評估了。目前，該參數仍是一個全局變量，未來或許會變成數據庫級別的變量以方便不同數據庫之間業務的差異。
而minTablesPerVnode，tablelncStepPerVnode這兩個變量由於使用相對復雜，所以目前並沒有出現在taos.cfg當中，屬於標題中提到的“神秘參數”。雖然它們設置了適當的默認值（1000）來應對大多數場景，但是當業務場景發生變動出現不適配的時候，就需要我們自己手動修改這些參數了。具體修改方式如下：打開taos.cfg后在空白區域添加如下內容，重啟數據庫服務進程即可。如果是集群環境，那么需要在每一個節點的taos.cfg中都做一樣的配置后重啟數據庫服務進程。
場景二：vnode分布不均勻
這種情況就比較簡單了，在批量創建完很多表后，有時候你可能會發現：“咦？為什么這個數據節點上有6個vnode，另外一個節點只有2個vnode。”
在解釋這種情況之前，我們需要知道另一個TDengine相當重要的概念——mnode（管理節點）。
關於mnode，官方文檔的描述十分清晰：
“管理節點(mnode): 一個虛擬的邏輯單元，負責所有數據節點運行狀態的監控和維護，以及節點之間的負載均衡。同時，管理節點也負責元數據(包括用戶、數據庫、表、靜態標簽等)的存儲和管理，因此也稱為 Meta Node。在集群中，為了保證mnode的高可用，可以配置多個mnode副本，副本數由系統配置參數numOfMnodes決定，有效范圍為1-3。”
可以看出，mnode和vnode一樣，都是以master-slave的模式分布在節點中的。因此，在做數據的負載均衡的時候，mnode也會是被計算在內的，而具體的計算方式就是，一個mnode等價於n個vnode，這個n就是由下面這個參數控制的。
而查看mnode的分配情況的命令如下：
這回我們就知道為什么會出現場景二的情況了——只有2個vnode分布的數據節點上一定是有mnode在工作的。
正是它，頂替了原本應該出現在這的vnode名額。
尾記
寫到這里就差不多了，但作為作者很想和大家閑聊幾句。
TDengine雖然使用簡單方便，但是想要最大化它的價值還是需要一番研究的。而官方文檔是作為TDengine的百科全書而存在的，某種程度上，它可能並不適合串聯實際應用場景。所以，為了填補這塊空白，所以我們在推送的文章中會很注意產品與實際場景的結合以及串聯。最終的目標，是讓我們的文章能夠形成在很多實際使用場景下的閉環說明書。這樣，就可以讓TDengine用戶的使用體驗大幅上升。
空口無憑，我們如何做到串聯不同實際的應用場景呢。很簡單，讀完本篇文章可能您已經了解了如何正確的配置集群的數據分布了。結合文章《TDengine 的用戶如何優化數據的寫入速度？》，想必您又已經對寫入數據的性能調試有了一定的認知。再文章《【社區精選】在Docker環境下，TDengine的客戶端為什么連不上集群？》，您又對在docker環境下搭建TDengine集群搭建有了一定的了解。
搭建TDengine的知識體系，就和搭建TDengine的集群一樣，需要一步一步慢慢積累起來。
開源文化的本質就是互相幫助，社區用戶為我們貢獻了很多。因此，我們也希望可以用同樣的方式回報大家。