01 前言
在上文《大資料基礎-原來這就是路由分片》中，我們簡單介紹了什麼是路由和分片、講述了通用的路由分片模型，并介紹了路由分片的常用方法，包括哈希分片和範圍分片。
在哈希分片這類路由分片的解決方案中，有幾種被廣泛熟知和應用的實作方式：
- hash 取模法
- 虛拟桶
- 一緻性hash
從本篇開始我們就詳細的原理和實作方法來一一講述。
02 哈希取模大法—真香！
我們首先詳細說下第一種最為常見的方法hash取模法，這個名字可能有些同學比較陌生，我相信輪詢（Round Robin）這個名詞你肯定是知道的。用最直白的話來說就是“雨露均沾”，盡量平均配置設定到所有節點。這種路由方法的方法在很多服務中都有使用，比如Nginx、LVS等場景，大資料場景下也有很多，比如kafka 的producer選擇partition寫資料的時候，實際上也是使用的hash取模法，後面聊到各個服務的時候再說。當然各自服務又針對場景有不同的定制，但原理并不複雜，比較适用于無狀态或邏輯相對簡單的業務場景。（最基本的周遊循環不在本次讨論範圍）
此時我們有100個節點，此時有若幹個請求過來，我們希望的是盡量将請求平均的配置設定到後端的節點上，以達到均衡的目的，可以通過哈希函數即可實作資料分片,核心代碼隻有3行。話不多說我們來簡單實作一下。
如下所示，modRequestID得到了對應的節點編号，以此可以将請求相對平均的路由到不同的節點上。基礎輪詢實作完成。
03 基礎輪詢的弊端
上面我們闡述了基礎輪詢的實作原理，實際上邏輯很簡單。這裡我們脫離哈希分片的範疇再向外擴充一下，假設我們将基礎輪詢應用在實際服務中，我們就會發現一個問題，當一個服務長期存在且健壯發展時，必然會擴容節點，而機器配置更新換代是很常見的事情，如果我們使用上述方式輪詢所有節點則會帶來後端節點的壓力不均衡，當請求落在較為繁忙的機器上時，會影響處理請求的效率。如何解決呢？
- 多擴容節點，将請求分散到更多節點上，控制節點的實際壓力，小于門檻值的壓力位，這樣就可以一定程度上緩解這個問題。當然由此帶來的問題就是資源的浪費，随之而來的也就是成本的壓力。
- 除了多擴容之外，還有什麼辦法呢？我們來分析一下沖突點，由于機器異構導緻處理性能有差異，最終導緻請求配置設定在高性能機器上，請求處理速度非常快，而低性能機器上則處理的相對較慢。如果此時我們秉持着“能者多勞”的想法，高性能機器多處理一些，那麼通過一些幹預方式有針對性的将請求配置設定，是不是就可以解決這個問題呢？由此我們引入權重輪詢的概念。
04 權重輪詢—加菜！
同樣的，閑話少許，我們直接來實作一把。
運作結果如下所示，是完全符合我們設定的權重規則的。
至此我們通過權重輪詢的方式，實作了将請求根據不同權重有針對性的進行配置設定，解決了叢集節點異構帶來的問題。
05 基礎輪詢和權重輪詢的制約
基礎輪詢，其優點在于邏輯比較簡單，也比較好上手，但是面臨着兩難的境地，靈活性比較差。如上述所叙，基礎輪詢通過将requestID 的hash值對節點數量取模後，進行路由節點選擇 。
如果此時增加擴容了一台機器，那麼會出現什麼問題呢？那就意味着一輪大洗牌，擴容一台機器将全部的映射關系打亂，請求隻能按照新的映射關系重新配置設定一遍,如下所示
那究竟為什麼Round Robin 的靈活性那麼差呢？我們不妨回到上一篇《大資料基礎-原來這就是路由分片》中，
------------------劃重點啦！------------------
Round Robin實際上是将實體節點和資料分片的功能合二為一了，也就意味着每個實體節點和資料分片是1:1的關系，是以在通用模型中Key-Partition 和Parition-Machine映射由同一個hash函數來負責了，這也就導緻實體節點和分片強耦合，實體節點變動代表着分片變動。這就是hash取模靈活性缺失的最大原因。
權重輪詢，準确的說，并不屬于哈希分片，但也存在類似的問題，新加入節點後映射關系全部打亂。
寫到最後，本來寫到這裡有關輪詢篇就已經寫完了，但是在寫的時候發現一個有趣的事情，如果結合第一篇《大資料基礎-原來這就是路由分片》來對權重輪詢進行一定的抽象是什麼樣子呢？可以把你的想法回複到留言中，請繼續關注後面的文章，相信會讓你發現架構之美。
原創不易，覺得有點用的話，就請你為本文點個贊吧。
你的支援是我寫作的動力。