?對于一個分布式存儲系統來說，數據是分散存儲在多個節點上的。如何讓數據均衡的分布在不同節點上，來保證其高可用性？所謂均衡，是指系統中每個節點的負載是均勻的，并且在發現有不均勻的情況或者有節點增加/刪除時，能及時進行調整，保持均勻狀態。本文將探討Elasticsearch的數據分布方法，文中所述的背景是Elasticsearch 5.5。
　　
　　??在Elasticsearch中，以Shard為最小的數據分配/遷移單位。數據到節點的映射分離為兩層：一層是數據到Shard的映射（Route），另一層是Shard到節點的映射（Allocate）。
　　
　　??一方面，插入一條數據時，ES會根據指定的Key來計算應該落到哪個Shard上。默認Key是自動分配的id，可以自定義，比如在我們的業務中采用CompanyID作為Key。因為Primary Shard的個數是不允許改變的，所以同一個Key每次算出來的Shard是一樣的，從而保證了準確定位。
　　
　　shard_num = hash(_routing) % num_primary_shards
　　
　　1
　　
　　??另一方面，Master會為每個Shard分配相應的Data節點進行存儲，并維護相關元信息。通過Route計算出來的Shard序號，在元信息中找到對應的存儲節點，便可完成數據分布。Shard Allocate的映射關系并不是完全不變的，當檢測到數據分布不均勻、有新節點加入或者有節點掛掉等情況時就會進行調整，稱為Relocate。那么，Elasticsearch是根據什么規則來為Shard選取節點，從而保證數據均衡分布的？概括來看，主要有三方面的影響：節點位置、磁盤空間、單個節點上的Index和Shard個數。
　　
　　節點位置
　　
　　?? 對于一個ES節點來說，它可能是某臺物理機器上的一個VM，而這個物理機器位于某個Zone的某個機架（Rack)上。通過將Primary Shard和Replica Shard分散在不同的物理機器、Rack、Zone，可以盡可能的降低數據丟失和系統不可用的風險，這一點幾乎在所有的分布式系統中都會考量。
　　
　　?? Elasticsearch是通過設置awareness.attribute對集群中的節點進行分組，從而實現Rack和Zone的發現。比如按照下列方式對elasticsearch.yml進行配置，再啟動相應的節點，即可實現Zone的區分。
　　
　　// elasticsearch.yml
　　
　　cluster.routing.allocation.awareness.attributes: zone
　　
　　// 啟動ES
　　
　　./bin/elasticsearch -Enode.attr.zone=zone_one
　　
　　./bin/elasticsearch -Enode.attr.zone=zone_two
　　
　　??實踐中，如果使用了這樣的Awareness機制，應該保證不同分組類的機器個數一致，不會發生傾斜。比如，在Zone Awareness下，如果集群有10臺機器，應該保證每個Zone各有5臺機器（2個Zone）。
　　
　　磁盤空間
　　
　　??磁盤空間是制約存儲的硬性條件，單機的可用磁盤空間決定了能否繼續往這個節點寫入新數據、分配新Shard以及是否需要遷移數據等。在ES中，有三個參數用來控制與此相關的特性，默認每30秒檢查一次。
　　
　　cluster.routing.allocation.disk.watermark.low: 默認為85%，超過這個閾值后，就不允許往這個節點分配Shard。
　　
　　cluster.routing.allocation.disk.watermark.high：默認為90%，超過這個閾值后，就需要將該節點的Shard遷移出去。
　　
　　cluster.routing.allocation.disk.watermark.flood_stage：默認為95%，超過這個閾值后，與該節點上的Shard有關的Index都變成只讀，不允許寫入數據。
　　
　　單個節點上的Index和Shard個數
　　
　　??在滿足節點位置和磁盤空間的條件后，單個節點上的Index和Shard個數是否均勻，決定了Shard可以分配/遷移到哪個節點。ES通過計算權值來量化這樣的分配方式。
　　
　　??以檢測某個Shard是否需要遷移到其他節點為例，ES會先計算該Shard所在節點（A）的權值，然后依次跟其他節點的權值比較，如果與節點B的差值（Delta-A）超過了閾值，再進一步計算節點A去掉該Shard后的權值與節點B增加該Shard后的權值之間的差值（Delta-B），如果Delta-A大于Delta-B，則表明Shard可以遷移到節點B。
　　
　　??這里的權值計算簡化如下，其中indexBalance與shardBalance分別由參數控制，而閾值由cluster.routing.allocation.balance.threshold設置，默認為1.0f。當然，這里只描述了核心思想，詳細邏輯請閱讀BalancedShardsAllocator.java中的源碼。通過調整三個參數，可以控制策略的松緊。
　　
　　// indexBalance = cluster.routing.allocation.balance.index, default is 0.55f
　　
　　// shardBalance = cluster.routing.allocation.balance.shard, default is 0.45f
　　
　　float sum = indexBalance www.yinmaoyule178.com+ shardBalance;
　　
　　float theta0 = shardBalance / sum;
　　
　　float theta1 = indexBalance / sum;
　　
　　private float weight(Balancer balancer, ModelNode node, String index, int numAdditionalShards) {
　　
　　final float weightShard www.dfgjpt.com= node.www.ysyl157.com numShards(www.dasheng178.com) + numAdditionalShards - balancer.avgShardsPerNode();
　　
　　final float weightIndex = node.numShards(index) + numAdditionalShards - balancer.avgShardsPerNode(index);
　　
　　return theta0 * weightShard + theta1 * weightIndex;
　　
　　Primary與Replica分布
　　
　　??最初關注Elasticsearch的數據分布，是因為在性能調優時遇到了一個與Primary/Replica分布有關的問題。背景是這樣的，為了能夠復用單個節點上的Disk Cache，我們對查詢請求進行了限制，只允許其訪問Primary Shard。然而總是有那么一兩臺機器的查詢會被Queue住，通過調研發現，這些機器上面的Primary Shard比其他機器多（對某一個Index而言），即下圖中左邊所示，而我們希望的是右圖所示的均勻分布。
　　
　　??引起這個問題的根源是，Elasticsearch中的Shard均勻分布是針對Primary+Replica整體而言的，也就是說沒法做到只針對Primary Shard單方面做均勻分布，所以才會出現下圖左邊所示，某個節點上有3個Primary Shard，而另一個節點只有1個。目前尚未發現可以調節的地方。

總結

以上是生活随笔為你收集整理的谈Elasticsearch下分布式存储的数据分布的全部內容，希望文章能夠幫你解決所遇到的問題。

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