當多執行緒協作處理同乙個資料來源時，可以使用分割槽器，有兩種分割槽器：
1.範圍分割槽器
範圍分割槽器又稱靜態分割槽器，即每個執行緒處理的資料項個數是相同的，根據資料來源集合的索引來劃分給每個執行緒乙個資料範圍。比如4個執行緒處理有100個元素的陣列，級分割槽器會依次給每個執行緒分配陣列索引為0～24，25～49，50～74，75～99四個範圍的元素，每個範圍25個陣列元素，如果處理每個元素的耗時不同，級分割槽器不會動態調配每個執行緒處理的工作量。當乙個執行緒處理完25個陣列元素後，其它執行緒仍還沒有處理完，空閒的執行緒不會幫繁忙執行緒處理資料。
但由於每個執行緒處理的資料項個數在一開始就已經分配完成，不會涉及鎖的問題，這排除了鎖帶來的效能問題。
這種分割槽器適合，資料項元素較多（資料元素越多，當使用動態分割槽器處理的時候，鎖衝突的次數就會越多，鎖帶來的效能影響就會越明顯），每個元素的處理時間差不多的情形。
2.塊分割槽器
塊分割槽器又稱動態分割槽器，當多個執行緒處理同乙個資料來源時，它們會分別從資料來源請求部分資料，當請求的資料處理完成之後，從資料來源請求部分資料。比如，4個執行緒（稱為a,b,c,d）處理100個元素的陣列，它們會各自請求10個元素進行處理，假設a執行緒優先處理完這10個元素，隨後其會再去請求10個元素，以此類推，最後是：a執行緒處理70個元素，b執行緒處理10個元素，c執行緒處理10個元素，d執行緒處理10個元素。這就有點「能者多勞」的意思，先處理完乙個小塊資料元素的執行緒會再去請求資料元素來執行，幫助處理的慢的執行緒來處理資料。
由於同乙個資料來源會被不同的執行緒不斷的請求資料塊，所以，資源爭用導致的鎖的問題是不可避免的，並且，如果每個塊中的元素越小，則鎖衝突的次數將會越多。
塊分割槽器適合每個元素的處理時間相差很大，且資料項元素較少的情形。
c#中的分割槽器詳見文件：
docker容器間的負載均衡
場景 第一次寫文章有點害怕，心理慌慌的，寫得不好的或是不對的，還請指點。在最近一次開發過程中遇見這個這樣的問題 在面臨突發性大量使用者湧進系統的時候，伺服器的資源使用並不高，cpu使用率28 左右，記憶體的使用率40 左右但是依然會造成系統卡頓，請求超時等問題。百思不得其解頭髮都快抓掉完了 系統也未...
SpringCloud服務間呼叫 負載均衡策略調整
比如我建立的乙個訂單服務 order service，要呼叫我的商品服務product service裡面的介面，預設使用輪詢的負載均衡策略 現在我要使用隨機分配，如何操作呢？要指定呼叫的服務名稱product service randomrule為隨機分配，更多策略參考 server port 8...
DNS負載均衡 Nginx 負載均衡的種類
dns負載均衡 當乙個 有足夠多的使用者的時候，假如每次請求的資源都位於同一臺機器上面，那麼這台機器隨時可能會蹦掉。處理辦法就是用dns負載均衡技術，它的原理是在dns伺服器中為同乙個主機名配置多個ip位址,在應答dns查詢時,dns伺服器對每個查詢將以dns檔案中主機記錄的ip位址按順序返回不同的...