在現在的大型網際網路專案中,集群和分布式是常用的架構方式。在處理大使用者量,高併發的情況中,分布式集群確實提供了乙個比較可行的方法。在分布式集群中有乙個很重要的概念,那就是」負載均衡」。在分布式集群中,乙個服務可能要部署在多個不同伺服器中,當大量請求到達的時候,請求被**到集群的伺服器中,這樣便可以用多個集群伺服器來分擔單體伺服器的壓力。但是這裡有乙個不可忽略的概念,就是所謂的負載均衡,他是如何將大量的請求**到不同的集群伺服器中,以使得各個集群伺服器平均分攤來自客戶端的請求(這裡的平均是指近似平均)?其實這就涉及到負載均衡演算法。下面結合幾個小例子來和大家一起學習一下這個負載均衡演算法。
所謂輪詢實現負載均衡就是將客戶端的請求按照集群伺服器列表的順序來一次分配,這種分配方式不管,集群伺服器的配置和效能問題,只是單純的按照伺服器列表的順序一次分配。下面簡單模擬一下輪詢方式實現負載均衡。
首先模擬乙個集群伺服器列表,map中的value是給每個集群伺服器設定的權重,這在後面會用到
/**
* *@classname: ipmap
*@description: todo(模擬集群的多台伺服器)
*@author 愛琴孩
*/public
class
ipmap
}
然後再簡單模擬輪詢的具體操作
/**
*@classname: roundrobin
*@description: todo(開啟多執行緒中測試輪詢)
*@author 愛琴孩
*/public
class
roundrobin
implements
runnable
server = keylist.get(pos);
pos ++;
}system.out.println("輪詢**的伺服器"+server);
}@override
public
void
run()
}
最後開啟多執行緒來進行測試,測試結果如下
這種負載處理方式,是一般負載策略中的預設處理方式,但是剛才上面也說到,這種簡單的輪詢方式有乙個弊端,就是他不會考慮各個伺服器的具體配置和效能問題,有的伺服器配置低,能負載的任務量少,有的伺服器配置高,能同時處理的請求多。如果都是這樣平均處理**過來的請求,顯然是不合理的。所以我們可以給每個集群伺服器中加乙個權重,然後再在加權重之後的伺服器列表中採用輪詢方式實現負載。這種方式可以簡稱為加權負載輪詢,這種方式只需要將上面的方式做乙個簡單修改便可以,具體如下
/**
*@classname: roundrobin
*@description: todo(開啟多執行緒中測試加權輪詢)
*@author 愛琴孩
*/public
class
roundrobin
implements
runnable
server = keylist.get(pos);
pos ++;
}system.out.println("輪詢**的伺服器"+server);
}@override
public
void
run()
}
測試結果如下
上面具體講解的是簡單輪詢和加權輪詢的方式。除了這兩種方式,比較常用的還有ip雜湊法,還有隨機法。下面將這兩種例子結合在一起演示一下
/**
*@classname: loadbalancedemo
*@description: todo(簡單模擬隨機演算法和hash雜湊演算法)
*@author 愛琴孩
*/public
class
loadbalancedemo };
return servermap;
}/**
* *@description: todo(隨機法)
*@author 愛琴孩
*@version v1.0
*/@test
public
void
random()
/***
*@description: todo(hash雜湊演算法)
*@author 愛琴孩
*@version v1.0
*/@test
public
void
hash()
}
上面兩種方式分別對應於隨機法和ip雜湊法,對於隨機法,在概率論中,當事件發生的基數很大的時候,這時候的隨機事件的概率就近似於平均。也就是說,當請求量很大的時候,這種隨機法和簡單輪詢的方式得到的結果是大致一樣的。但是這種方式在請求量很大的情況下,即使和輪詢方式相似,那麼他也就有輪詢方式的缺點,那就是不能兼顧每個集群伺服器的各自效能和配置。當然隨機法也可以進行加權處理,處理方式和上面的加權輪詢類似,這裡就不在演示了。
而對於ip雜湊這種方式,是根據由每個客戶端的ip位址根據演算法來算出乙個具體值,然後再對伺服器列表的個數進行取模運算,對映到對應的集群伺服器。這種方式每個請求被**到集群伺服器是固定的,這樣就可以避免因**不確定性,導致session難以維護問題。
出來上面提到的這幾種,我們還可能會根據最小連線數法,還有最短響應時間法。所謂最小連線數,就是根據當前集群伺服器上已負載的請求數量,動態**請求到對應的集群伺服器,如果伺服器上負載請求已經很多了,就不要在向該伺服器上再**請求。最短響應時間也是類似,如果乙個伺服器的對請求的響應時間很短很及時,那麼代表這個伺服器還能負載一些請求,如果乙個伺服器對請求的響應時間已經很長了,說明負載已經夠了,,如果繼續向這個伺服器**請求,這樣請求肯定會被堵塞。
上面簡單介紹了,輪詢負載,加權輪詢,隨機,加權隨機,ip雜湊,最短響應時間,最小連線數等負載方法,當然還有其他的方法。但是具體使用哪一種方式,還是要結合具體的場景和實際情況來酌情使用,畢竟沒有最好的方式,只有最合適的方式!
nginx系列之五 負載均衡
使用nginx做負載均衡的兩大模組 nginx 的負載均衡功能依賴於 ngx http upstream module模組,所支援的 方式有 proxy pass 一般用於反向 fastcgi pass 一般用於和動態程式互動 memcached pass,proxy next upstream,f...
nginx系列之五 負載均衡
nginx系列之一 nginx入門 nginx系列之二 配置檔案解讀 nginx系列之三 日誌配置 nginx系列之四 web伺服器 nginx系列之五 負載均衡 nginx系列之六 cache服務 nginx系列之七 限流配置 nginx系列之八 使用upsync模組實現負載均衡 使用nginx做...
負載均衡演算法之輪詢
最近的工作事情比較少,於是就開是瞎折騰了 負載均衡大家一定不陌生了,一句話就是,人人有飯吃,還吃得飽,它的核心關鍵字就在於均衡,關於負載均衡大家基本可以脫口而出常見的幾種,輪詢,隨機,雜湊,帶權值的輪詢,客戶端請求數等等 作為最簡單的一種負載均衡策略,輪詢的優點顯而易見,簡單,並且在多數的情況是,基...