靜態調度算法：
僅根據算法本身進行調度
RR： 輪詢調度（Round Robin）
調度器通過“輪詢”調度算法將外部請求按順序輪流分配到集羣中的真實服務器上，它均等地對待每一臺服務器，而不管服務器上實際的連接數和系統負載。屬於大鍋飯調度。
此種均衡算法適合於服務器組中的所有服務器都有相同的軟硬件配置並且平均服務請求相對均衡的情況。
WRR: 加權輪詢（Weighted Round Robin）
根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器能處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值。帶權重的大鍋飯調度。
此種均衡算法能確保高性能的服務器得到更多的使用率，避免低性能的服務器負載過重。
SH: 源地址哈希（Source Hashing）
根據請求的源IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器。基於client地址的來源區分。實現session sticky。
DH: 目標地址哈希（Destination Hashing）
根據請求的目標IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
動態調度算法：
主要根據每RS當前的負載狀態及調度算法進行調度
LC: 最少鏈接（Least Connections）
動態地將網絡請求調度到已建立的鏈接數最少的服務器上。如果集羣系統的真實服務器具有相近的系統性能，採用“最小連接”調度算法可以較好地均衡負載。誰不幹活就給誰分配
此種均衡算法適合長連接處理的請求服務，如FTP。
WLC： 加權最少鏈接（Weighted Least Connections）
默認調度方法。在集羣系統中的服務器性能差異較大的情況下，調度器採用此調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負載。調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值。帶權重的誰不幹活就給誰分配，機器配置好的權重高
SED: 初始連接高權重優先（Shortest Expected Delay Scheduling SED）
基於wlc算法。一個新的初始鏈接的時候，優先分配權重高的服務器。缺陷：當權重過大的時候，會導致空閒服務器一直處於無連接狀態
NQ: 最少隊列調度（Never Queue Scheduling NQ）
第一輪均勻分配，後續SED。無需隊列。如果有臺 RealServer的連接數＝0 就直接分配過去，不需要再進行sed運算，保證不會有一個主機很空閒。不考慮非活動連接，才用NQ，SED要考慮活動狀態連接，對於DNS的UDP不需要考慮非活動連接，而httpd的處於保持狀態的服務就需要考慮非活動連接給服務器的壓力。
LBLC: 基於局部性的最少鏈接（Locality-Based Least Connections）
動態的DH算法，使用場景：根據負載狀態實現正向代理
針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於一半的工作負載，則用“最少鏈接” 的原則選出一個可用的服務器，將請求發送到該服務器。基於本地的最小連接。把請求傳遞到負載小的服務器上
LBLCR: 帶複製的基於局部性最少鏈接（Locality-Based Least Connections with Replication）
帶複製功能的LBLC,解決LBLC負載不均衡問題，從負載重的複製到負載輕的RS。
針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。它與LBLC算法的不同之處是它要維護從一個目標 IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組，按“最小連接”原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按“最少鏈接”原則從這個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低複製的程度。
某頁面緩存在服務器A上，被訪問次數極高，而其他緩存服務器負載較低，監視是否訪問同一頁面，如果是訪問同一頁面則把請求分到其他服務器。
下面列舉一些針對不同環境個人採用的模式和調度算法：
1. 如果後端服務器的配置相同，而且臺數不多的話
可以使用LVS三種模式中的任意一種，調度算法可以是RR
2. 如果後端服務器的配置相同，但是臺數很多的話
可以使用LVS-DR或者LVS-TUN模式，調度算法可以是RR
3. 如果後端服務器的配置相同，但是臺數很多
而且服務器分佈在不同的局域網中，那麼使用LVS-TUN模式，調度算法可以是RR
4. 如果後端服務器的配置不同，而且臺數不多的話
可以使用LVS三種模式中的任意一種，調度算法可以是WRR
5. 如果後端服務器的配置不同，但是臺數很多的話
可以使用LVS-DR或者LVS-TUN模式，調度算法可以是WRR
6. 如果後端服務器的配置不同，但是臺數很多
而且服務器分佈在不同的局域網中，那麼使用LVS-TUN模式，調度算法可以是WRR
7. 如果後端服務器使用了cache系統
可以使用LVS-DR或者LVS-TUN模式，調度算法可以是LBLC或者LBLCR
8. 如果後端服務器使用了cache系統，且架構體系龐大，使用LVS-TUN模式，調度算法是LBLCR
9. 如果後端服務器爲集羣且性能差異大，使用LVS-DR或者LVS-TUN模式，調度算法採用WLC
10. 如果後端服務器爲集羣且性能差異不大，使用lvs/dr或者LVS-TUN模式，調度算法採用LC
以上幾種情況只是個人的理解，建議還是大家根據實際環境、需求等衆多因素，採用適合的模式及調度算法，每個公司的體系、環境、需求是不一樣的，只有靈活的運用才能找到合適的體系。沒有最好的只有最適合的。