伺服器集群演算法_伺服器集群的負載均衡演算法有哪些

1. Redis集群方案應該怎麼做

通常，為了提高網站響應速度，總是把熱點數據保存在內存中而不是直接從後端資料庫中讀取。Redis是一個很好的Cache工具。大型網站應用，熱點數據量往往巨大，幾十G上百G是很正常的事兒，在這種情況下，如何正確架構Redis呢？
首先，無論我們是使用自己的物理主機，還是使用雲服務主機，內存資源往往是有限制的，scale up不是一個好辦法，我們需要scale out橫向可伸縮擴展，這需要由多台主機協同提供服務，即分布式多個Redis實例協同運行。
其次，目前硬體資源成本降低，多核CPU，幾十G內存的主機很普遍，對於主進程是單線程工作的Redis，只運行一個實例就顯得有些浪費。同時，管理一個巨大內存不如管理相對較小的內存高效。因此，實際使用中，通常一台機器上同時跑多個Redis實例。
方案
1.Redis官方集群方案 Redis Cluster

Redis Cluster是一種伺服器Sharding技術，3.0版本開始正式提供。
Redis
Cluster中，Sharding採用slot(槽)的概念，一共分成16384個槽，這有點兒類似前面講的pre
sharding思路。對於每個進入Redis的鍵值對，根據key進行散列，分配到這16384個slot中的某一個中。使用的hash演算法也比較簡
單，就是CRC16後16384取模。
Redis集群中的每個node(節點)負責分攤這16384個slot中的一部分，也就是說，每個
slot都對應一個node負責處理。當動態添加或減少node節點時，需要將16384個槽做個再分配，槽中的鍵值也要遷移。當然，這一過程，在目前實
現中，還處於半自動狀態，需要人工介入。
Redis集群，要保證16384個槽對應的node都正常工作，如果某個node發生故障，那它負責的slots也就失效，整個集群將不能工作。
為
了增加集群的可訪問性，官方推薦的方案是將node配置成主從結構，即一個master主節點，掛n個slave從節點。這時，如果主節點失
效，Redis Cluster會根據選舉演算法從slave節點中選擇一個上升為主節點，整個集群繼續對外提供服務。這非常類似前篇文章提到的Redis
Sharding場景下伺服器節點通過Sentinel監控架構成主從結構，只是Redis Cluster本身提供了故障轉移容錯的能力。
Redis
Cluster的新節點識別能力、故障判斷及故障轉移能力是通過集群中的每個node都在和其它nodes進行通信，這被稱為集群匯流排(cluster

bus)。它們使用特殊的埠號，即對外服務埠號加10000。例如如果某個node的埠號是6379，那麼它與其它nodes通信的埠號是
16379。nodes之間的通信採用特殊的二進制協議。
對客戶端來說，整個cluster被看做是一個整體，客戶端可以連接任意一個
node進行操作，就像操作單一Redis實例一樣，當客戶端操作的key沒有分配到該node上時，Redis會返回轉向指令，指向正確的node，這
有點兒像瀏覽器頁面的302 redirect跳轉。
Redis Cluster是Redis 3.0以後才正式推出，時間較晚，目前能證明在大規模生產環境下成功的案例還不是很多，需要時間檢驗。

2.Redis Sharding集群

Redis 3正式推出了官方集群技術，解決了多Redis實例協同服務問題。Redis Cluster可以說是服務端Sharding分片技術的體現，即將鍵值按照一定演算法合理分配到各個實例分片上，同時各個實例節點協調溝通，共同對外承擔一致服務。
多Redis實例服務，比單Redis實例要復雜的多，這涉及到定位、協同、容錯、擴容等技術難題。這里，我們介紹一種輕量級的客戶端Redis Sharding技術。
Redis
Sharding可以說是Redis
Cluster出來之前，業界普遍使用的多Redis實例集群方法。其主要思想是採用哈希演算法將Redis數據的key進行散列，通過hash函數，特定
的key會映射到特定的Redis節點上。這樣，客戶端就知道該向哪個Redis節點操作數據。Sharding架構如圖：
慶幸的是，java redis客戶端驅動jedis，已支持Redis Sharding功能，即ShardedJedis以及結合緩存池的ShardedJedisPool。
Jedis的Redis Sharding實現具有如下特點：
采
用一致性哈希演算法(consistent
hashing)，將key和節點name同時hashing，然後進行映射匹配，採用的演算法是MURMUR_HASH。採用一致性哈希而不是採用簡單類
似哈希求模映射的主要原因是當增加或減少節點時，不會產生由於重新匹配造成的rehashing。一致性哈希隻影響相鄰節點key分配，影響量小。
2.
為了避免一致性哈希隻影響相鄰節點造成節點分配壓力，ShardedJedis會對每個Redis節點根據名字(沒有，Jedis會賦予預設名字)會虛擬
化出160個虛擬節點進行散列。根據權重weight，也可虛擬化出160倍數的虛擬節點。用虛擬節點做映射匹配，可以在增加或減少Redis節點
時，key在各Redis節點移動再分配更均勻，而不是只有相鄰節點受影響。
3.ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，這樣通過合理命名key，可以將一組相關聯的key放入同一個Redis節點，這在避免跨節點訪問相關數據時很重要。

Redis Sharding採用客戶端Sharding方式，服務端Redis還是一個個相對獨立的Redis實例節點，沒有做任何變動。同時，我們也不需要增加額外的中間處理組件，這是一種非常輕量、靈活的Redis多實例集群方法。
當然，Redis Sharding這種輕量靈活方式必然在集群其它能力方面做出妥協。比如擴容，當想要增加Redis節點時，盡管採用一致性哈希，畢竟還是會有key匹配不到而丟失，這時需要鍵值遷移。
作為輕量級客戶端sharding，處理Redis鍵值遷移是不現實的，這就要求應用層面允許Redis中數據丟失或從後端資料庫重新載入數據。但有些時候，擊穿緩存層，直接訪問資料庫層，會對系統訪問造成很大壓力。有沒有其它手段改善這種情況？
Redis
作者給出了一個比較討巧的辦法--presharding，即預先根據系統規模盡量部署好多個Redis實例，這些實例佔用系統資源很小，一台物理機可部
署多個，讓他們都參與sharding，當需要擴容時，選中一個實例作為主節點，新加入的Redis節點作為從節點進行數據復制。數據同步後，修改
sharding配置，讓指向原實例的Shard指向新機器上擴容後的Redis節點，同時調整新Redis節點為主節點，原實例可不再使用。
presharding
是預先分配好足夠的分片，擴容時只是將屬於某一分片的原Redis實例替換成新的容量更大的Redis實例。參與sharding的分片沒有改變，所以也
就不存在key值從一個區轉移到另一個分片區的現象，只是將屬於同分片區的鍵值從原Redis實例同步到新Redis實例。

並不是只有增
刪Redis節點引起鍵值丟失問題，更大的障礙來自Redis節點突然宕機。在《Redis持久化》一文中已提到，為不影響Redis性能，盡量不開啟
AOF和RDB文件保存功能，可架構Redis主備模式，主Redis宕機，數據不會丟失，備Redis留有備份。
這樣，我們的架構模式變
成一個Redis節點切片包含一個主Redis和一個備Redis。在主Redis宕機時，備Redis接管過來，上升為主Redis，繼續提供服務。主
備共同組成一個Redis節點，通過自動故障轉移，保證了節點的高可用性。則Sharding架構演變成：

Redis Sentinel提供了主備模式下Redis監控、故障轉移功能達到系統的高可用性。

高訪問量下，即使採用Sharding分片，一個單獨節點還是承擔了很大的訪問壓力，這時我們還需要進一步分解。通常情況下，應用訪問Redis讀操作量和寫操作量差異很大，讀常常是寫的數倍，這時我們可以將讀寫分離，而且讀提供更多的實例數。
可以利用主從模式實現讀寫分離，主負責寫，從負責只讀，同時一主掛多個從。在Sentinel監控下，還可以保障節點故障的自動監測。

3.利用代理中間件實現大規模Redis集群
上面分別介紹了多Redis伺服器集群的兩種方式，它們是基於客戶端sharding的Redis Sharding和基於服務端sharding的Redis Cluster。

客戶端sharding技術其優勢在於服務端的Redis實例彼此獨立，相互無關聯，每個Redis實例像單伺服器一樣運行，非常容易線性擴展，系統的靈活性很強。其不足之處在於：
由於sharding處理放到客戶端，規模進步擴大時給運維帶來挑戰。
服務端Redis實例群拓撲結構有變化時，每個客戶端都需要更新調整。
連接不能共享，當應用規模增大時，資源浪費制約優化。
服務端sharding的Redis Cluster其優勢在於服務端Redis集群拓撲結構變化時，客戶端不需要感知，客戶端像使用單Redis伺服器一樣使用Redis集群，運維管理也比較方便。
不過Redis Cluster正式版推出時間不長，系統穩定性、性能等都需要時間檢驗，尤其在大規模使用場合。
能不能結合二者優勢？即能使服務端各實例彼此獨立，支持線性可伸縮，同時sharding又能集中處理，方便統一管理？本篇介紹的Redis代理中間件twemproxy就是這樣一種利用中間件做sharding的技術。
twemproxy處於客戶端和伺服器的中間，將客戶端發來的請求，進行一定的處理後(如sharding)，再轉發給後端真正的Redis伺服器。也就是說，客戶端不直接訪問Redis伺服器，而是通過twemproxy代理中間件間接訪問。
參照Redis Sharding架構，增加代理中間件的Redis集群架構如下：

twemproxy中間件的內部處理是無狀態的，它本身可以很輕松地集群，這樣可避免單點壓力或故障。
twemproxy又叫nutcracker，起源於twitter系統中redis/memcached集群開發實踐，運行效果良好，後代碼奉獻給開源社區。其輕量高效，採用C語言開發，工程網址是：GitHub - twitter/twemproxy: A fast, light-weight proxy for memcached and redis
twemproxy後端不僅支持redis，同時也支持memcached，這是twitter系統具體環境造成的。
由於使用了中間件，twemproxy可以通過共享與後端系統的連接，降低客戶端直接連接後端伺服器的連接數量。同時，它也提供sharding功能，支持後端伺服器集群水平擴展。統一運維管理也帶來了方便。
當然，也是由於使用了中間件代理，相比客戶端直連伺服器方式，性能上會有所損耗，實測結果大約降低了20%左右。

2. 什麼是高性能計算集群

群集技術
開放分類： IT、群集技術

就像冗餘部件可以使你免於硬體故障一樣，群集技術則可以使你免於整個系統的癱瘓以及操作系統和應用層次的故障。一台伺服器集群包含多台擁有共享數據存儲空間的伺服器，各伺服器之間通過內部區域網進行互相連接；當其中一台伺服器發生故障時，它所運行的應用程序將與之相連的伺服器自動接管；在大多數情況下，集群中所有的計算機都擁有一個共同的名稱，集群系統內任意一台伺服器都可被所有的網路用戶所使用。一般而言，群集和高可用性結合的伺服器可將運行提升至99.99%。群集技術不僅僅能夠提供更長的運行時間，它在盡可能地減少與既定停機有關的停機時間方面同樣有著重要意義。例如，如果使用群集，你可以在關閉一台伺服器的同時，不用與用戶斷開即可進行應用，硬體，操作系統的"流動升級"。集群系統通過功能整合和故障過渡技術實現系統的高可用性和高可靠性，集群技術還能夠提供相對低廉的總體擁有成本和強大靈活的系統擴充能力。

隨著計算機技術的發展和越來越廣泛的應用，越來越多的依賴於計算機技術的應用系統走進了我們的工作和生活。在給我們帶來方便和效率的同時，也使得各行各業對於計算機技術的依賴程度越來越高。盡管隨著計算機技術以日新月異的速度發展，單台計算機的性能和可靠性越來越好，但還是有許多現實的要求是單台計算機難以達到的。

高可用性集群，英文原文為High Availability Cluster, 簡稱HA Cluster，是指以減少服務中斷（宕機）時間為目的的伺服器集群技術。
隨著全球經濟的增長，世界各地各種各樣的組織對IT系統的依賴都在不斷增加，電子貿易使得商務一周七天24小時不間斷的進行成為了可能。新的強大的應用程序使得商業和社會機構對日常操作的計算機化要求達到了空前的程度，趨勢非常明顯，我們無時無刻不依賴於穩定的計算機系統。
這種需求極速的增長，使得對系統可用性的要求變得非常重要，許多公司和組織的業務在很大程度上都依賴於計算機系統，任何的宕機都會造成嚴重的損失，關鍵IT系統的故障可能很快造成整個商業運作的癱瘓，每一分鍾的宕機都意味著收入、生產和利潤的損失，甚至於市場地位的削弱。

3. 如何使用Apache伺服器配置負載均衡集群

Internet 的快速增長，特別是電子商務應用的發展，使Web應用成為目前最重要最廣泛的應用，Web伺服器動態內容越來越流行。目前，網上信息交換量幾乎呈指數增長，需要更高性能的Web伺服器提供更多用戶的Web服務，因此，Web伺服器面臨著訪問量急劇增加的壓力，對其處理能力和響應能力等帶來更高的要求，如果Web 伺服器無法滿足大量Web訪問服務，將無法為用戶提供穩定、良好的網路應用服務。
由於客觀存在的伺服器物理內存、CPU 處理速度和操作系統等方面的影響因素，當大量突發的數據到達時，Web伺服器無法完全及時處理所有的請求，造成應答滯後、請求丟失等，嚴重的導致一些數據包因延時而重發，使傳輸線路和伺服器的負擔再次增加。傳統的方法是提高Web 伺服器的CPU 處理速度和增加內存容量等硬體辦法但無論如何增加Web 伺服器硬體性能，均無法滿足日益增加的對用戶的訪問服務能力。
面對日漸增加的Web 訪問服務要求，必須對Web 伺服器按一定策略進行負載分配。利用負載均衡[1]的技術，按照一定策略將Web 訪問服務分配到幾台伺服器上，負載處理對用戶透明，整體上對外如同一台Web 伺服器為用戶提供Web服務。
2 Web負載均衡結構
2.1 負載均衡
負載是一個抽象的概念，是表示系統繁忙程度，系統在一段時間空閑，該系統負載輕，系統在一段時間空忙，該系統負載重，影響系統負載的各種因數較多如果存在很多的數據包同時通過網路連向一台Web伺服器，也就是網路的速度比網路所連接的設備速度快的情況下，系統負載不斷增加，直到最大。
目前提高Web 伺服器性能，使其具有較強負載能力，主要有兩種處理思想[2]：
1)單機思想
不斷升級伺服器硬體性能，每當負載增加，伺服器隨之升級。這隨之將帶來一些問題，首先，伺服器向高檔升級，花費資金較多；其次，升級頻繁，機器切換造成服務中斷，可能會導致整個服務中斷；最後，每種架構的伺服器升級總有一個極限限制。
2)多機思想
使用多台伺服器提供服務，通過一定機制使它們共同分擔系統負載，對單一的伺服器沒有太高的性能要求，系統負載增加，可以多增加伺服器來分擔。對用戶而言，整個系統彷彿是一台單一的邏輯伺服器，這樣的系統能夠提供較強的可擴展性和較好的吞吐性能。
為了適應當前急劇增長的Web訪問，有別於傳統的單機思想，解決單機思想帶來的一系列問題，本文提出了一種基於權值的策略分配負載。
2.2 負載均衡實現設備[2]
目前實現負載均衡需要兩類的設備：伺服器和分配器。
1)伺服器(Server)
為用戶提供真正的服務，也就是指給用戶提供負載均衡服務的計算機設備，有關該設備的一些性能數據是負載均衡的主要依據之一。
2)分配器(Dispatcher)
由用戶瀏覽器、Web 伺服器組成兩層結構Web 系統[2]，如所示，實際是基於客戶端的負載均衡。
負責給用戶服務分配伺服器，分配器的主要功能是根據客戶和伺服器的各種情況(這些情況要能反映伺服器的負載狀況或性能狀況)通過一定的演算法進行調動和分配工作，從而提高由伺服器整體構成的網站的穩定性、響應能力。它主要是集中所有的HTTP 請求，然後分配到多台Web伺服器上處理，來提高系統的處理效率。
2.3 負載均衡系統結構
2.3.1 兩層結構的負載均衡系統
在伺服器上運行一個特定的程序，該程序相當一個客戶端，它定期的收集伺服器相關性能參數，如CPU、I/O、內存等動態信息，根據某種策略，確定提供最佳服務的伺服器，將應用請求轉發給它。如果採集負載信息程序發現伺服器失敗，則找其它伺服器作為服務選擇。這是一種動態負載均衡技術，但是每台伺服器上必須安裝特定的客戶端程序，同時，為保證應用程序的透明性，需要對每個應用進行修改，能夠將訪問請求通過該客戶端程序轉發到其它伺服器上，重定向方式進行，修改每一個應用程序，工作量十分大。
2.3.2 三層結構的負載均衡系統
由用戶瀏覽器、負載均衡和Web伺服器組成三層結構Web系統[2]，如所示。實際是基於伺服器的負載均衡。如果將基於客戶端的負載均衡中客戶端的負載均衡部分移植到一個中間平台，形成一個應用伺服器，構成請求、負載均衡和伺服器的三層結構，客戶端應用不需要做特殊修改，透明的中間層將請求均衡的分布到不同的伺服器。
據伺服器直接連到Internet 與否有兩種多Web 伺服器結構：隔離式(Separation) 和非隔離式(Unseparation)。隔離式是伺服器不直接連到Internet，如所示，非隔離式是伺服器直接連到Internet，如所示。隔離式中只有負載均衡器對外有一個IP 地址，所有的請求由負載均衡器分配到不同的Web Server，所有Web Server 的返回結果也經過負載均衡器傳回給用戶。非隔離式中每一台Web Server 都有一個IP地址，用戶請求經過負載均衡器分配到Web Server，而請求的應答不經過負載均衡器，直接傳回用戶。為了減輕均衡器的負載，本文中採用了三層結構中的隔離方式。
2.4 負載均衡實現的方法
Web 負載均衡常見演算法有[3]：循環調度演算法(Round-Robin Scheling)、加權循環調度演算法(Weighted Round-Robin Scheling) 、最小連接調度演算法(Least-Connection Scheling)、目標地址散列調度演算法(Destination Hashing Scheling)、源地址散列調度演算法(Source Hashing Scheling)。
本文採用基於權值的調度演算法，也就是說權值大的伺服器優先得到調度，本文在實現時是基於靜態的權值，就是在開始的時候給每一個伺服器配置一個默認的權值。當然也可以根據實際運行情況再對每一個伺服器的權值進行調整。但是這需要實時的搜集每一個伺服器的信息，如伺服器的內存實用情況，響應速度等一些信息。

4. 如何搭建apache+tomcat集群

在實際應用中，如果網站的訪問量很大，為了提高訪問速度，可以與多個Tomcat伺服器與Apache伺服器集成，讓他們共同運行servlet/jsp組件的任務，多個Tomcat伺服器構成了一個集群（Cluster）系統，共同為客戶提供服務。集群系統具有以下優點：

高可靠性（HA）：利用集群管理軟體，當主伺服器故障時，備份伺服器能夠自動接管主伺服器的工作，並及時切換過去，以實現對用戶的不間斷服務。
高性能計算（HP）：即充分利用集群中的每一台計算機的資源，實現復雜運算的並行處理，通常用於科學計算領域，比如基因分析，化學分析等。
負載平衡：即把負載壓力根據某種演算法合理分配到集群中的每一台計算機上，以減輕主伺服器的壓力，降低對主伺服器的硬體和軟體要求。

原理：JK插件的負載均衡器根據在worker.properties中配置的lbfactor（負載平衡因數），負責為集群系統中的Tomcat伺服器分配工作負荷，以實現負載平衡。每個Tomcat伺服器間用集群管理器（SimpleTcpCluster）進行通信，以實現HTTP回話的復制，比如Session。

下面我們在一台機器上配置一個Apache和兩個Tomcat伺服器集群：

2.安裝Apache，安裝兩個Tomcat，並把一個測試項目放到兩個Tomcat的webapps目錄下以便以後測試。

3.把mod_jk.so復制到<apache_home>/moles下。

4.在<apache_home>/conf目錄下創建：workers.properties文件：

"pln">worker "pun">. "pln">list "pun">= "pln">worker1 "pun">, "pln">worker2 "pun">, "pln">loadbalancer "com">#apache把Tomcat看成是工人，loadbalancer是負載均衡器

worker.worker1.host=localhost#Tomcatworker1伺服器
worker.worker1.port=8009#Tomcat埠
worker.worker1.type=ajp13#協議
worker.worker1.lbfactor=100#負載平衡因數

worker.worker2.host=localhost#Tomcatworker2伺服器
worker.worker2.port=8009#因為在一台機器上所以埠不能一樣
worker.worker2.type=ajp13#協議
worker.worker2.lbfactor=100#設為一樣代表兩台機器的負載相同

worker.loadbalancer.type=1b
worker.loadbalancer.balanced_workers=worker1,worker2
worker.loadbalancer.sticky_seesion=false
worker.loadbalancer.sticky_session_force=false

說明：1.worker.loadbalancer.sticky_seesion如果設為true則說明會話具有「粘性」，也就是如果一個用戶在一個Tomcat中建立了會話後則此後這個用戶的所有操做都由這個Tomcat伺服器承擔。集群系統不會進行會話復制。如果設為false則下面的 sticky_session_force無意義。

2.sticky_session_force：假設sticky_session設為true，用戶會話具有了粘性，當當前Tomcat伺服器停止服務後，如果sticky_session_force為true也就是強制會話與當前Tomcat關聯，那麼會報500錯誤，如果設為false則會轉到另外的Tomcat伺服器。

5.修改<apache_home>/conf/httpd.conf文件，在文件後面加上：

"com">#Tomcat集群配置
"com">LoadMolejk_molemoles/mod_jk.so
JkWorkersFileconf/workers.properties
#我的工人們
JkLogFilelogs/mod_jk.log
#日誌文件
JkLogLeveldebug
#tomcat運行模式
JkMount/*.jsploadbalancer
#收到.jsp結尾的文件交給負載均衡器處理
JkMount/helloapp/*loadbalancer
#收到helloapp/路徑交給負載均衡器處理

6.修改兩個Tomcat的conf/service.xml文件。

6.1首先要修改AJP埠，確保他們與workers.properties中配置的一樣

例如按我們上面的配置，只需要把Tomcat2中的AJP埠該為8109即可。

6.2此外在使用了loadbalancer後，要求worker的名字與Tomcat的service.xml中的Engine元素的jvmRoute屬性一致，

例如worker1修改為： <Engine name="Catalina" defaultHost="localhost" jvmRoute="worker1">

6.3另外，如果兩台Tomcat伺服器裝在一台機器上，必須確保他們的埠沒有沖突，Tomcat中一共配置了三個埠：

把其中一個該了讓它們不一樣就行了。

完成了以上步驟我們的集群算是基本完成了，打開Apache和兩個Tomcat 瀏覽器進入：localhost/demo/ 能夠正確訪問。

為了測試，我們寫一個jsp文件：test.jsp

"tag"><html>
<head>
<title>test</title>
</head>
<body>
<%
System.out.printfln("calltest.jsp");
%>
session:<%=session.getId()%>
</body></html>

把它放到兩個Tomcat中的demo項目中，瀏覽器訪問這個頁面，每次訪問只在一個Tomcat控制台列印語句。

然而頁面中的Session Id是會變的。這種情況下如果一個用戶正在訪問時，如果跳到另一個Tomcat伺服器，那麼他的session就沒有了，可能導致錯誤。

7.配置集群管理器

如果讀者對HttpSession有了解應該知道，用戶的會話狀態保存在session中，一個瀏覽器訪問多個網頁它們的請求始終處於一個會話范圍中，因此SessionID應該是不變的。

以上我們看到的瀏覽器中的SessionID不同，因為轉到另一個Tomcat後當前會話就結束了，又在另一個伺服器上開啟了一個新的會話。那麼怎麼讓多個Tomcat伺服器共享一個會話呢?

為了解決上述問題，我們啟用Tomcat的集群管理器（SimpleTcpCluster）：

7.1修改Tomcat1和Tomcat2的servlet.xml文件，在Engine元素中加入以下Cluster元素

"tag"><Cluster "pln"> "atn">className "pun">= "atv">"org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="8">

<ManagerclassName="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>

<ChannelclassName="org.apache.catalina.tribes.group.GroupChannel">
<MembershipclassName="org.apache.catalina.tribes.membership.McastService"
bind="127.0.0.1"
address="228.0.0.4"
port="45564"
frequency="500"
dropTime="3000"/>
<ReceiverclassName="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4000"
autoBind="100"
selectorTimeout="5000"
maxThreads="6"/>
<SenderclassName="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<TransportclassName="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<InterceptorclassName="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<InterceptorclassName="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
</Channel>

<ValveclassName="org.apache.catalina.ha.tcp.ReplicationValve"filter=""/>
<ValveclassName="org.apache.catalina.ha.session.JvmRouteBinderValve"/>

<DeployerclassName="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>
<ClusterListenerclassName="org.apache.catalina.ha.session."/>
<ClusterListenerclassName="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>

關於Cluster的相關介紹參照：<tomcat-home>webappsdocscluster-howto.html <tomcat-home>webappsdocsconfigcluster.html

7.2分別修改Tomcat1和Tomcat2 demo項目的web.xml文件，在後面加入<distributable>元素

"tag"><web-app>
"pln">...
"tag"><distributable/>
</web-app>

如果一個web項目的web.xml文件中指定了<distributable/>元素那麼Tomcat伺服器啟動這個Web應用時，會為它創建由<Cluster>元素指定的會話管理器，這里我們用的是DeltaManager,他們把會話從一個Tomcat伺服器復制到集群中另一個Tomcat伺服器。

7.3重新啟動兩個Tomcat，發現Tomcat控制台還是依次列印出Call test.jsp 頁面中的SessionID卻不變了。測試完成。

重要說明：(1).如果項目要發布到集群上，那麼與會話有關的類需要實現java.io.Serializable序列化介面。

(2).集群中Tomcat間用組播方式進行通信，如果機器上有多個網卡則可能導致組播失敗，解決的辦法是<Cluster>元素的<Membership>元素配置bind屬性，它用於明確知道組播地址：

(3).如果集群較小，可以採用DeltaManager會話管理器，如果多的話建議使用BackupManager

(4).<Membership>的address設為"228.0.0.4"，運行時須確保機器聯網能訪問到該地址，否則可能運行失敗。

5. Redis怎麼做集群

為什麼集群？

通常，為了提高網站響應速度，總是把熱點數據保存在內存中而不是直接從後端資料庫中讀取。Redis是一個很好的Cache工具。大型網站應用，熱點數據量往往巨大，幾十G上百G是很正常的事兒，在這種情況下，如何正確架構Redis呢？

首先，無論我們是使用自己的物理主機，還是使用雲服務主機，內存資源往往是有限制的，scale up不是一個好辦法，我們需要scale out橫向可伸縮擴展，這需要由多台主機協同提供服務，即分布式多個Redis實例協同運行。

其次，目前硬體資源成本降低，多核CPU，幾十G內存的主機很普遍，對於主進程是單線程工作的Redis，只運行一個實例就顯得有些浪費。同時，管理一個巨大內存不如管理相對較小的內存高效。因此，實際使用中，通常一台機器上同時跑多個Redis實例。

方案

1.Redis官方集群方案 Redis Cluster

Redis Cluster是一種伺服器Sharding技術，3.0版本開始正式提供。

Redis Cluster中，Sharding採用slot(槽)的概念，一共分成16384個槽，這有點兒類pre sharding思路。對於每個進入Redis的鍵值對，根據key進行散列，分配到這16384個slot中的某一個中。使用的hash演算法也比較簡單，就是CRC16後16384取模。

Redis集群中的每個node(節點)負責分攤這16384個slot中的一部分，也就是說，每個slot都對應一個node負責處理。當動態添加或減少node節點時，需要將16384個槽做個再分配，槽中的鍵值也要遷移。當然，這一過程，在目前實現中，還處於半自動狀態，需要人工介入。

Redis集群，要保證16384個槽對應的node都正常工作，如果某個node發生故障，那它負責的slots也就失效，整個集群將不能工作。

為了增加集群的可訪問性，官方推薦的方案是將node配置成主從結構，即一個master主節點，掛n個slave從節點。這時，如果主節點失效，Redis Cluster會根據選舉演算法從slave節點中選擇一個上升為主節點，整個集群繼續對外提供服務。這非常類似前篇文章提到的Redis Sharding場景下伺服器節點通過Sentinel監控架構成主從結構，只是Redis Cluster本身提供了故障轉移容錯的能力。

Redis Cluster的新節點識別能力、故障判斷及故障轉移能力是通過集群中的每個node都在和其它nodes進行通信，這被稱為集群匯流排(cluster bus)。它們使用特殊的埠號，即對外服務埠號加10000。例如如果某個node的埠號是6379，那麼它與其它nodes通信的埠號是16379。nodes之間的通信採用特殊的二進制協議。

對客戶端來說，整個cluster被看做是一個整體，客戶端可以連接任意一個node進行操作，就像操作單一Redis實例一樣，當客戶端操作的key沒有分配到該node上時，Redis會返回轉向指令，指向正確的node，這有點兒像瀏覽器頁面的302 redirect跳轉。

Redis Cluster是Redis 3.0以後才正式推出，時間較晚，目前能證明在大規模生產環境下成功的案例還不是很多，需要時間檢驗。

2.Redis Sharding集群

Redis 3正式推出了官方集群技術，解決了多Redis實例協同服務問題。Redis Cluster可以說是服務端Sharding分片技術的體現，即將鍵值按照一定演算法合理分配到各個實例分片上，同時各個實例節點協調溝通，共同對外承擔一致服務。

多Redis實例服務，比單Redis實例要復雜的多，這涉及到定位、協同、容錯、擴容等技術難題。這里，我們介紹一種輕量級的客戶端Redis Sharding技術。

Redis Sharding可以說是Redis Cluster出來之前，業界普遍使用的多Redis實例集群方法。其主要思想是採用哈希演算法將Redis數據的key進行散列，通過hash函數，特定的key會映射到特定的Redis節點上。這樣，客戶端就知道該向哪個Redis節點操作數據。

慶幸的是，java redis客戶端驅動jedis，已支持Redis Sharding功能，即ShardedJedis以及結合緩存池的ShardedJedisPool。

Jedis的Redis Sharding實現具有如下特點：

1. 採用一致性哈希演算法(consistent hashing)，將key和節點name同時hashing，然後進行映射匹配，採用的演算法是MURMUR_HASH。採用一致性哈希而不是採用簡單類似哈希求模映射的主要原因是當增加或減少節點時，不會產生由於重新匹配造成的rehashing。一致性哈希隻影響相鄰節點key分配，影響量小。

2.為了避免一致性哈希隻影響相鄰節點造成節點分配壓力，ShardedJedis會對每個Redis節點根據名字(沒有，Jedis會賦予預設名字)會虛擬化出160個虛擬節點進行散列。根據權重weight，也可虛擬化出160倍數的虛擬節點。用虛擬節點做映射匹配，可以在增加或減少Redis節點時，key在各Redis節點移動再分配更均勻，而不是只有相鄰節點受影響。

3.ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，這樣通過合理命名key，可以將一組相關聯的key放入同一個Redis節點，這在避免跨節點訪問相關數據時很重要。

6. 求集群管理的相關知識！

集群技術案例介紹和具體操作

集群技術案例介紹和具體操作
中國科學院西安網路中心中科紅旗linux培訓認證中心
集群技術
1.1 什麼是集群
簡單的說，集群（cluster）就是一組計算機，它們作為一個整體向用戶提
供一組網路資源。這些單個的計算機系統就是集群的節點（node）。一個理想的
集群是，用戶從來不會意識到集群系統底層的節點，在他/她們看來，集群是一
個系統，而非多個計算機系統。並且集群系統的管理員可以隨意增加和刪改集群
系統的節點。
1.2 為什麼需要集群
集群並不是一個全新的概念，其實早在七十年代計算機廠商和研究機構就
開始了對集群系統的研究和開發。由於主要用於科學工程計算，所以這些系統並
不為大家所熟知。直到Linux集群的出現，集群的概念才得以廣為傳播。
對集群的研究起源於集群系統良好的性能可擴展性(scalability)。提高CPU
主頻和匯流排帶寬是最初提供計算機性能的主要手段。但是這一手段對系統性能的
提供是有限的。接著人們通過增加CPU個數和內存容量來提高性能，於是出現了
向量機，對稱多處理機(SMP)等。但是當CPU的個數超過某一閾值，象SMP這些
多處理機系統的可擴展性就變的極差。主要瓶頸在於CPU訪問內存的帶寬並不能
隨著CPU個數的增加而有效增長。與SMP相反，集群系統的性能隨著CPU個數的
增加幾乎是線性變化的。圖1顯示了這中情況。
圖1. 幾種計算機系統的可擴展性
對於關鍵業務，停機通常是災難性的。因為停機帶來的損失也是巨大的。下
面的統計數字列舉了不同類型企業應用系統停機所帶來的損失。
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
應用系統每分鍾損失(美元)
呼叫中心(Call Center) 27000
企業資源計劃(ERP)系統13000
供應鏈管理(SCM)系統11000
電子商務(eCommerce)系統10000
客戶服務(Customer Service Center)系統27000
圖2：停機給企業帶來的損失
隨著企業越來越依賴於信息技術，由於系統停機而帶來的損失也越拉越大。
集群系統的優點並不僅在於此。下面列舉了集群系統的主要優點：
高可擴展性：如上所述。
高可用性：集群中的一個節點失效，它的任務可傳遞給其他節點。可以有效防止單點失效。
高性能：負載平衡集群允許系統同時接入更多的用戶。
高性價比：可以採用廉價的符合工業標準的硬體構造高性能的系統。
2.1 集群系統的分類
雖然，根據集群系統的不同特徵可以有多種分類方法，但是一般把集群系統分為兩類：
（1）、高可用(High Availability)集群,簡稱HA集群。
這類集群致力於提供高度可靠的服務。就是利用集群系統的容錯性對外提供7*24小時不間
斷的服務，如高可用的文件伺服器、資料庫服務等關鍵應用。
目前已經有在Linux下的高可用集群，如Linux HA項目。
負載均衡集群：使任務可以在集群中盡可能平均地分攤不同的計算機進行處理，充分利
用集群的處理能力，提高對任務的處理效率。
在實際應用中這幾種集群類型可能會混合使用，以提供更加高效穩定的服務。如在一個使
用的網路流量負載均衡集群中，就會包含高可用的網路文件系統、高可用的網路服務。
（2）、性能計算(High Perfermance Computing)集群，簡稱HPC集群，也稱為科學計算
集群。
在這種集群上運行的是專門開發的並行應用程序，它可以把一個問題的數據分布到多
台的計算機上，利用這些計算機的共同資源來完成計算任務，從而可以解決單機不能勝任
的工作（如問題規模太大，單機計算速度太慢）。
這類集群致力於提供單個計算機所不能提供的強大的計算能力。如天氣預報、石油勘探與油
藏模擬、分子模擬、生物計算等。這些應用通常在並行通訊環境MPI、PVM等中開發，由於MPI
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
是目前的標准，故現在多使用MPI為並行環境。
比較有名的集群Beowulf就是一種科學計算集群項目。
3、集群系統轉發方式和調度演算法
3．1轉發方式
目前LVS主要有三種請求轉發方式和八種調度演算法。根據請求轉發方式的不同，所構
架集群的網路拓撲、安裝方式、性能表現也各不相同。用LVS主要可以架構三種形式的集群，
分別是LVS/NAT、LVS/TUN和LVS/DR，可以根據需要選擇其中一種。
（1）、網路地址轉換（LVS/NAT）
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
（2）、直接路由
（3）、IP隧道
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
三種轉發方式的比較：
3．2、調度演算法
在選定轉發方式的情況下，採用哪種調度演算法將決定整個負載均衡的性能表現，不同
的演算法適用於不同的應用場合，有時可能需要針對特殊場合，自行設計調度演算法。LVS的算
法是逐漸豐富起來的，最初LVS只提供4種調度演算法，後來發展到以下八種：
1.輪叫調度（Round Robin）
調度器通過「輪叫」調度演算法將外部請求按順序輪流分配到集群中的真實伺服器上，它均
等地對待每一台伺服器，而不管伺服器上實際的連接數和系統負載。
2.加權輪叫（Weighted Round Robin）
調度器通過「加權輪叫」調度演算法根據真實伺服器的不同處理能力來調度訪問請求。這樣
可以保證處理能力強的伺服器能處理更多的訪問流量。調度器可以自動詢問真實伺服器的
負載情況，並動態地調整其權值。
3.最少鏈接（Least Connections）
調度器通過「最少連接」調度演算法動態地將網路請求調度到已建立的鏈接數最少的伺服器
上。如果集群系統的真實伺服器具有相近的系統性能，採用「最小連接」調度演算法可以較
好地均衡負載。
4.加權最少鏈接（Weighted Least Connections）
在集群系統中的伺服器性能差異較大的情況下，調度器採用「加權最少鏈接」調度演算法優
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
化負載均衡性能，具有較高權值的伺服器將承受較大比例的活動連接負載。調度器可以自
動詢問真實伺服器的負載情況，並動態地調整其權值。
5.基於局部性的最少鏈接（Locality-Based Least Connections）
「基於局部性的最少鏈接」調度演算法是針對目標IP地址的負載均衡，目前主要用於Cache
集群系統。該演算法根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該服務
器是可用的且沒有超載，將請求發送到該伺服器；若伺服器不存在，或者該伺服器超載且
有伺服器處於一半的工作負載，則用「最少鏈接」的原則選出一個可用的伺服器，將請求
發送到該伺服器。
6. 帶復制的基於局部性最少鏈接（ Locality-Based Least Connections with
Replication）
「帶復制的基於局部性最少鏈接」調度演算法也是針對目標IP地址的負載均衡，目前主要
用於Cache集群系統。它與LBLC演算法的不同之處是它要維護從一個目標IP地址到一組服務
器的映射，而LBLC演算法維護從一個目標IP地址到一台伺服器的映射。該演算法根據請求的目
標IP地址找出該目標IP地址對應的伺服器組，按「最小連接」原則從伺服器組中選出一
台伺服器，若伺服器沒有超載，將請求發送到該伺服器；若伺服器超載，則按「最小連接
」原則從這個集群中選出一台伺服器，將該伺服器加入到伺服器組中，將請求發送到該服
務器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，
以降低復制的程度。
7.目標地址散列（Destination Hashing）
「目標地址散列」調度演算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分
配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，
否則返回空。
8.源地址散列（Source Hashing）
「源地址散列」調度演算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的
散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則
返回空。
了解這些演算法原理能夠在特定的應用場合選擇最適合的調度演算法，從而盡可能地保持
Real Server的最佳利用性。當然也可以自行開發演算法，不過這已超出本文范圍，請參考有
關演算法原理的資料。
4．1、什麼是高可用性
計算機系統的可用性(availability)是通過系統的可靠性(reliability)和可維護性
(maintainability)來度量的。工程上通常用平均無故障時間(MTTF)來度量系統的可靠性，
用平均維修時間（MTTR）來度量系統的可維護性。於是可用性被定義為：
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
MTTF/(MTTF+MTTR)*100%
業界根據可用性把計算機系統分為如下幾類：
可用比例
(Percent
Availability)
年停機時間
(downtime/year
)
可用性分類
99.5 3.7天
常規系統
(Conventional)
99.9 8.8小時可用系統(Available)
99.99 52.6分鍾
高可用系統(Highly
Available)
99.999 5.3分鍾Fault Resilient
99.9999 32秒Fault Tolerant
為了實現集群系統的高可用性，提高系統的高可性，需要在集群中建立冗餘機制。一個功
能全面的集群機構如下圖所示
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
負載均衡伺服器的高可用性
為了屏蔽負載均衡伺服器的失效，需要建立一個備份機。主伺服器和備份機上都運行
High Availability監控程序，通過傳送諸如「I am alive」這樣的信息來監控對方的運
行狀況。當備份機不能在一定的時間內收到這樣的信息時，它就接管主伺服器的服務IP並
繼續提供服務；當備份管理器又從主管理器收到「I am alive」這樣的信息是，它就釋放
服務IP地址，這樣的主管理器就開開始再次進行集群管理的工作了。為在住伺服器失效的
情況下系統能正常工作，我們在主、備份機之間實現負載集群系統配置信息的同步與備份，
保持二者系統的基本一致。
HA的容錯備援運作過程
自動偵測(Auto-Detect)階段由主機上的軟體通過冗餘偵測線，經由復雜的監聽程序。邏
輯判斷，來相互偵測對方運行的情況，所檢查的項目有：
主機硬體(CPU和周邊)
主機網路
主機操作系統
資料庫引擎及其它應用程序
主機與磁碟陣列連線
為確保偵測的正確性，而防止錯誤的判斷，可設定安全偵測時間，包括偵測時間間隔，
偵測次數以調整安全系數，並且由主機的冗餘通信連線，將所匯集的訊息記錄下來，以供
維護參考。
自動切換(Auto-Switch)階段某一主機如果確認對方故障，則正常主機除繼續進行原來的
任務，還將依據各種容錯備援模式接管預先設定的備援作業程序，並進行後續的程序及服
務。
自動恢復(Auto-Recovery)階段在正常主機代替故障主機工作後，故障主機可離線進行修
復工作。在故障主機修復後，透過冗餘通訊線與原正常主機連線，自動切換回修復完成的
主機上。整個回復過程完成由EDI-HA自動完成，亦可依據預先配置，選擇回復動作為半自
動或不回復。
4．2、HA三種工作方式：
（1）、主從方式（非對稱方式）
工作原理：主機工作，備機處於監控准備狀況；當主機宕機時，備機接管主機的一切工作，
待主機恢復正常後，按使用者的設定以自動或手動方式將服務切換到主機上運行，數據的
一致性通過共享存儲系統解決。
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
（2）、雙機雙工方式（互備互援）
工作原理：兩台主機同時運行各自的服務工作且相互監測情況，當任一台主機宕機時，另
一台主機立即接管它的一切工作，保證工作實時，應用服務系統的關鍵數據存放在共享存
儲系統中。
（3）、集群工作方式（多伺服器互備方式）
工作原理：多台主機一起工作，各自運行一個或幾個服務，各為服務定義一個或多個備用
主機，當某個主機故障時，運行在其上的服務就可以被其它主機接管。
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
相關文檔
http://tech.sina.com.cn/it/2004-04-09/1505346805.shtml
http://stonesoup.esd.ornl.gov
LINUX下的集群實列應用
最近有客戶需要一個負載均衡方案，筆者對各種軟硬體的負載均衡方案進行了調查和
比較，從IBM sServer Cluster、Sun Cluster PlatForm 等硬體集群，到中軟、紅旗、
TurboLinux的軟體集群，發現無論採用哪個廠商的負載均衡產品其價格都是該客戶目前所
不能接受的。於是筆者想到了開放源項目Linux Virtual Server(簡稱LVS)。經過對LVS的研
究和實驗，終於在Red Hat 9.0上用LVS成功地構架了一組負載均衡的集群系統。整個實
現過程整理收錄如下，供讀者參考。
選用的LVS實際上是一種Linux操作系統上基於IP層的負載均衡調度技術，它在操
作系統核心層上，將來自IP層的TCP/UDP請求均衡地轉移到不同的伺服器，從而將一組
伺服器構成一個高性能、高可用的虛擬伺服器。使用三台機器就可以用LVS實現最簡單的集
群，如圖1所示。
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
圖1 LVS實現集群系統結構簡圖
圖1顯示一台名為Director的機器在集群前端做負載分配工作；後端兩台機器稱之為
Real Server，專門負責處理Director分配來的外界請求。該集群的核心是前端的Director
機器，LVS就是安裝在這台機器上，它必須安裝Linux。Real Server則要根據其選用的負
載分配方式而定，通常Real Server上的設置比較少。接下來介紹Director機器上LVS的
安裝過程。
安裝
LVS的安裝主要是在Director機器上進行，Real Server只需針對不同的轉發方式做簡單
的設定即可。特別是對LVS的NAT方式，Real Server惟一要做的就是設一下預設的網關。
所以構架集群的第一步從安裝Director機器開始。
首先，要在Director機器上安裝一個Linux操作系統。雖然早期的一些Red Hat版本，
如6.2、7.2、8.0等自帶Red Hat自己的集群軟體，或者是在內核中已經支持LVS，但是為
了更清楚地了解LVS的機制，筆者還是選擇自行將LVS編入Linux內核的方式進行安裝，
Linux版本採用Red Hat 9.0。
如果用戶對Red Hat的安裝比較了解，可以選擇定製安裝，並只安裝必要的軟體包。
安裝中請選擇GRUB 做為啟動引導管理軟體。因為GRUB 在系統引導方面的功能遠比
LILO強大，在編譯Linux內核時可以體會它的方便之處。
LVS是在Linux內核中實現的，所以要對原有的Linux內核打上支持LVS的內核補丁，
然後重新編譯內核。支持LVS 的內核補丁可以從LVS 的官方網
http://www.linuxvirtualserver.org 下載，下載時請注意使用的Linux核心版本，必須下載和
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
使用的Linux內核版本相一致的LVS內核補丁才行。對於Red Hat 9.0，其Linux內核版本
是2.4.20，所以對應內核補丁應該是http://www.linuxvirtualserver.org/software/kernel-
2.4/linux-2.4.20-ipvs-1.0.9.patch.gz。筆者經過多次實驗，使用Red Hat 9.0自帶的Linux
源代碼無法成功編譯LVS 的相關模組。由於時間關系筆者沒有仔細研究，而是另外從
kernel.org上下載了一個tar包格式的2.4.20內核來進行安裝，順利完成所有編譯。下面是
整個內核的編譯過程：
1.刪除Red Hat自帶的Linux源代碼
# cd /usr/src
# rm -rf linux*
2.下載2.4.20內核
# cd /usr/src
# wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.20.tar.bz2
3.解壓到當前目錄/usr/src
# cd /usr/src
# tar -xjpvf linux-2.4.20.tar.bz2
4.建立鏈接文件
# cd /usr/src # ln -s linux-2.4.20 linux-2.4 # ln -s linux-2.4.20 linux
5.打上LVS的內核補丁
# cd /usr/src
#wget http://www.linuxvirtualserver.org/software/kernel-2.4/linux-2.4.20-ipvs-
1.0.9.patch.gz
# gzip -cd linux-2.4.20-ipvs-1.0.9.patch.gz
# cd /usr/src/linux
# patch -p1 < ../linux-2.4.20-ipvs-1.0.9.patch
在打補丁時，注意命令執行後的信息，不能有任何錯誤信息，否則核心或模組很可能
無法成功編譯。
6.打上修正ARP問題的內核補丁
# cd /usr/src
# wget http://www.ssi.bg/~ja/hidden-2.4.20pre10-1.diff
# cd /usr/src/linux
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
# patch -p1 < ../hidden-2.4.20pre10-1.diff
這一步在Director機器上可以不做，但是在使用LVS/TUN和LVS/DR方式的Real Server
上必須做。
7.為新核心命名
打開/usr/src/linux/Makefile。注意，在開始部分有一個變數EXTRAVERSION可以自行定
義。修改這個變數，比如改成「EXTRAVERSION=-LVS」後，編譯出的核心版本號就會顯
示成2.4.20-LVS。這樣給出有含義的名稱將有助於管理多個Linux核心。
8.檢查源代碼
# make mrproper
這一步是為確保源代碼目錄下沒有不正確的.o文件及文件的互相依賴。因為是新下載的內
核，所以在第一次編譯時，這一步實際可以省略。
9.配置核心選項
# make menuconfig
命令執行後會進入一個圖形化的配置界面，可以通過這個友好的圖形界面對內核進行定製。
此過程中，要注意對硬體驅動的選擇。Linux支持豐富的硬體，但對於伺服器而言，用不到
的硬體驅動都可以刪除。另外，像Multimedia devices、Sound、Bluetooth support、Amateur
Radio support等項也可以刪除。
注意，以下幾項配置對LVS非常重要，請確保作出正確的選擇：
(1)Code maturity level options項
對此項只有以下一個子選項，請選中為*，即編譯到內核中去。
Prompt for development and/or incomplete code/drivers
(2)Networking options項
對此項的選擇可以參考以下的配置，如果不清楚含義可以查看幫助：
<*> Packet socket
[ ] Packet socket: mmapped IO
< > Netlink device emulation
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
Network packet filtering (replaces ipchains)
[ ] Network packet filtering debugging
Socket Filtering
<*> Unix domain sockets
TCP/IP networking
IP: multicasting
IP: advanced router
IP: policy routing
[ ] IP: use netfilter MARK value as routing key
[ ] IP: fast network address translation
<M> IP: tunneling
IP: broadcast GRE over IP
[ ] IP: multicast routing
[ ] IP: ARP daemon support (EXPERIMENTAL)
[ ] IP: TCP Explicit Congestion Notification support
[ ] IP: TCP syncookie support (disabled per default)
IP: Netfilter Configuration --->
IP: Virtual Server Configuration --->
(3)Networking options項中的IP: Virtual Server Configuration項
如果打好了LVS的內核補丁，就會出現此選項。進入Virtual Server Configuration選項，
有以下子選項：
<M> virtual server support (EXPERIMENTAL)
IP virtual server debugging
(12) IPVS connection table size (the Nth power of 2)
--- IPVS scheler
<M> round-robin scheling
<M> weighted round-robin scheling
<M> least-connection scheling scheling
<M> weighted least-connection scheling
<M> locality-based least-connection scheling
<M> locality-based least-connection with replication scheling
<M> destination hashing scheling
<M> source hashing scheling
<M> shortest expected delay scheling
<M> never queue scheling
--- IPVS application helper
<M> FTP protocol helper
以上所有項建議全部選擇。
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
(4)Networking options項中的IP: Netfilter Configuration項
對於2.4版本以上的Linux Kernel來說，iptables是取代早期ipfwadm和ipchains的
更好選擇，所以除非有特殊情況需要用到對ipchains和ipfwadm的支持，否則就不要選它。
本文在LVS/NAT方式中，使用的就是iptables，故這里不選擇對ipchains和ipfwadm的
支持：
< > ipchains (2.2-style) support
< > ipfwadm (2.0-style) support
10. 編譯內核
(1)檢查依賴關系
# make dep
確保關鍵文件在正確的路徑上。
(2)清除中間文件
# make clean
確保所有文件都處於最新的版本狀態下。
(3)編譯新核心
# make bzImage
(4)編譯模組
# make moles
編譯選擇的模組。
(5)安裝模組
# make moles_install
# depmod -a
生成模組間的依賴關系，以便modprobe定位。
(6)使用新模組
# cp System.map /boot/System.map-2.4.20-LVS
# rm /boot/System.map
# ln -s /boot/System.map-2.4.20-LVS /boot/System.map
# cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.20-LVS
# rm /boot/vmlinuz
# ln -s /boot/vmlinuz-2.4.20-LVS /boot/vmlinuz
# new-kernel-pkg --install --mkinitrd --depmod 2.4.20-LVS
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
(7)修改GRUB，以新的核心啟動
執行完new-kernel-pkg命令後，GRUB的設置文件/etc/grub.conf中已經增加了新核心的
啟動項，這正是開始安裝Linux時推薦使用GRUB做引導程序的原因。
grub.conf中新增內容如下：
title Red Hat Linux (2.4.20-LVS)
root (hd0,0)
kernel /boot/vmlinuz-2.4.20LVS ro root=LABEL=/
initrd /boot/initrd-2.4.20LVS.img
將Kernel項中的root=LABEL=/改成 root=/dev/sda1 (這里的/dev/sda1是筆者Linux的根
分區，讀者可根據自己的情況進行不同設置）。
保存修改後，重新啟動系統:
# reboot
系統啟動後，在GRUB的界面上會出現Red Hat Linux(2.4.20-LVS)項。這就是剛才編譯的
支持LVS的新核心，選擇此項啟動，看看啟動過程是否有錯誤發生。如果正常啟動，ipvs
將作為模塊載入。同時應該注意到，用LVS的內核啟動後在/proc目錄中新增了一些文件，
比如/proc/sys/net/ipv4/vs/*。
11.安裝IP虛擬伺服器軟體ipvsadm
用支持LVS的內核啟動後，即可安裝IP虛擬伺服器軟體ipvsadm了。用戶可以用tar包或
RPM 包安裝，tar 包可以從以下地址http://www.linuxvirtualserver.org/software/kernel-
2.4/ipvsadm-1.21.tar.gz 下載進行安裝。
這里採用源RPM包來進行安裝：
# wget http://www.linuxvirtualserver.org/software/kernel-2.4/ipvsadm-1.21-7.src.rpm
# rpmbuild --rebuild ipvsadm-1.21-7.src.rpm
# rpm -ivh /usr/src/redhat/RPMS/i386/ipvsadm-1.21-7.i386.rpm
注意：高版本的rpm命令去掉了--rebuild這個參數選項，但提供了一個rpmbuild命令來實
現它。這一點和以前在Red Hat 6.2中以rpm—rebuild XXX.src.rpm來安裝源RPM包的習
慣做法有所不同。
安裝完，執行ipvsadm命令，應該有類似如下的信息出現：
# ipvsadm
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心中科紅旗linux培訓認證中心
IP Virtual Server version 1.0.9 (size=4096)
Prot LocalAddress:Port Scheler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
出現類似以上信息，表明支持LVS 的內核和配置工具ipvsadm 已完全安裝，這台
Director機器已經初步安裝完成，已具備構架各種方式的集群的條件。
實例
理解了上述關於請求轉發方式和調度演算法的基本概念後，就可以運用LVS來具體實現
幾種不同方式的負載均衡的集群系統。LVS的配置是通過前面所安裝的IP虛擬伺服器軟體
ipvsadm來實現的。ipvsadm與LVS的關系類似於iptables和NetFilter的關系，前者只是
一個建立和修改規則的工具，這些命令的作用在系統重新啟動後就消失了，所以應該將這
些命令寫到一個腳本里，然後讓它在系統啟動後自動執行。網上有不少配置LVS的工具，
有的甚至可以自動生成腳本。但是自己手工編寫有助於更深入地了解，所以本文的安裝沒
有利用其它第三方提供的腳本，而是純粹使用ipvsadm命令來配置。
下面就介紹一下如何配置LVS/NAT、LVS/TUN、LVS/DR方式的負載均衡集群。
1.設定LVS/NAT方式的負載均衡集群
NAT是指Network Address Translation，它的轉發流程是：Director機器收到外界請求，
改寫數據包的目標地址，按相應的調度演算法將其發送到相應Real Server上，Real Server
處理完該請求後，將結果數據包返回到其默認網關，即Director機器上，Dire

7. 伺服器集群，負載均衡，分布式等問題

集群和負載均衡的區別如下：
1、集群(Cluster)
所謂集群是指一組獨立的計算機系統構成的一個松耦合的多處理器系統,它們之間通過網路實現進程間的通信?應用程序可以通過網路共享內存進行消息傳送,實現分布式計算機?
2、負載均衡(Load Balance)
網路的負載均衡是一種動態均衡技術,通過一些工具實時地分析數據包,掌握網路中的數據流量狀況,把任務合理均衡地分配出去?這種技術基於現有網路結構,提供了一種擴展伺服器帶寬和增加伺服器吞吐量的廉價有效的方法,加強了網路數據處理能力,提高了網路的靈活性和可用性?
3、特點
(1)高可靠性(HA)?利用集群管理軟體,當主伺服器故障時,備份伺服器能夠自動接管主伺服器的工作,並及時切換過去,以實現對用戶的不間斷服務?
(2)高性能計算(HP)?即充分利用集群中的每一台計算機的資源,實現復雜運算的並行處理,通常用於科學計算領域,比如基因分析?化學分析等?
(3)負載平衡?即把負載壓力根據某種演算法合理分配到集群中的每一台計算機上,以減輕主伺服器的壓力,降低對主伺服器的硬體和軟體要求?
LVS系統結構與特點
1. Linux Virtual Server:簡稱LVS?是由中國一個Linux程序員章文嵩博士發起和領導的,基於Linux系統的伺服器集群解決方案,其實現目標是創建一個具有良好的擴展性?高可靠性?高性能和高可用性的體系?許多商業的集群產品,比如RedHat的Piranha? Turbo Linux公司的Turbo Cluster等,都是基於LVS的核心代碼的?
2. 體系結構:使用LVS架設的伺服器集群系統從體系結構上看是透明的,最終用戶只感覺到一個虛擬伺服器?物理伺服器之間可以通過高速的 LAN或分布在各地的WAN相連?最前端是負載均衡器,它負責將各種服務請求分發給後面的物理伺服器,讓整個集群表現得像一個服務於同一IP地址的虛擬伺服器?
3. LVS的三種模式工作原理和優缺點: Linux Virtual Server主要是在負載均衡器上實現的,負載均衡器是一台加了 LVS Patch的2.2.x版內核的Linux系統?LVS Patch可以通過重新編譯內核的方法加入內核,也可以當作一個動態的模塊插入現在的內核中?

8. 什麼是資料庫集群

集群主要分成三大類（高可用集群，負載均衡集群，科學計算集群）
高可用集群( High Availability Cluster)
負載均衡集群(Load Balance Cluster)
科學計算集群(High Performance Computing Cluster)

1、高可用集群(High Availability Cluster)
常見的就是2個節點做成的HA集群，有很多通俗的不科學的名稱，比如」雙機熱備」, 「雙機互備」, 「雙機」。高可用集群解決的是保障用戶的應用程序持續對外提供服務的能力。 (請注意高可用集群既不是用來保護業務數據的，保護的是用戶的業務程序對外不間斷提供服務，把因軟體/硬體/人為造成的故障對業務的影響降低到最小程度)。

2、負載均衡集群(Load Balance Cluster)

負載均衡系統：集群中所有的節點都處於活動狀態，它們分攤系統的工作負載。一般Web伺服器集群、資料庫集群和應用伺服器集群都屬於這種類型。

負載均衡集群一般用於相應網路請求的網頁伺服器，資料庫伺服器。這種集群可以在接到請求時，檢查接受請求較少，不繁忙的伺服器，並把請求轉到這些伺服器上。從檢查其他伺服器狀態這一點上看，負載均衡和容錯集群很接近，不同之處是數量上更多。

3、科學計算集群(High Performance Computing Cluster)

高性能計算(High Perfermance Computing)集群，簡稱HPC集群。這類集群致力於提供單個計算機所不能提供的強大的計算能力。

高性能計算分類：

3.1、高吞吐計算(High-throughput Computing)
有一類高性能計算，可以把它分成若干可以並行的子任務，而且各個子任務彼此間沒有什麼關聯。象在家搜尋外星人（ SETI@HOME – Search for Extraterrestrial Intelligence at Home ）就是這一類型應用。
這一項目是利用Internet上的閑置的計算資源來搜尋外星人。SETI項目的伺服器將一組數據和數據模式發給Internet上參加SETI的計算節點，計算節點在給定的數據上用給定的模式進行搜索，然後將搜索的結果發給伺服器。伺服器負責將從各個計算節點返回的數據匯集成完整的數據。因為這種類型應用的一個共同特徵是在海量數據上搜索某些模式，所以把這類計算稱為高吞吐計算。
所謂的Internet計算都屬於這一類。按照 Flynn的分類，高吞吐計算屬於SIMD（Single Instruction/Multiple Data）的范疇。

3.2、分布計算(Distributed Computing)
另一類計算剛好和高吞吐計算相反，它們雖然可以給分成若干並行的子任務，但是子任務間聯系很緊密，需要大量的數據交換。按照Flynn的分類，分布式的高性能計算屬於MIMD（Multiple Instruction/Multiple Data）的范疇。

下面說說這幾種集群的應用場景：

高可用集群這里不多作說明。

想Dubbo是比較偏向於負載均衡集群，用過的猿友應該知道（不知道的可以自行了解一下），Dubbo同一個服務是可以有多個提供者的，當一個消費者過來，它要消費那個提供者，這里是有負載均衡機制在裡面的。

搜索引擎Elasticsearch比較偏向於科學計算集群的分布計算。

而到這里，可能不少猿友都知道，集群的一些術語：集群容錯、負載均衡。

我們以Dubbo為例：
集群容錯（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E9%9B%86%E7%BE%A4%E5%AE%B9%E9%94%99）

Dubbo提供了這些容錯策略：
集群容錯模式：
可以自行擴展集群容錯策略，參見：集群擴展
Failover Cluster
失敗自動切換，當出現失敗，重試其它伺服器。(預設)
通常用於讀操作，但重試會帶來更長延遲。
可通過retries="2"來設置重試次數(不含第一次)。

Failfast Cluster
快速失敗，只發起一次調用，失敗立即報錯。
通常用於非冪等性的寫操作，比如新增記錄。

Failsafe Cluster
失敗安全，出現異常時，直接忽略。
通常用於寫入審計日誌等操作。

Failback Cluster
失敗自動恢復，後台記錄失敗請求，定時重發。
通常用於消息通知操作。

Forking Cluster
並行調用多個伺服器，只要一個成功即返回。
通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。

可通過forks="2"來設置最大並行數。

Broadcast Cluster
廣播調用所有提供者，逐個調用，任意一台報錯則報錯。(2.1.0開始支持)
通常用於通知所有提供者更新緩存或日誌等本地資源信息。

負載均衡（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1）

Dubbo提供了這些負載均衡策略：

Random LoadBalance

隨機，按權重設置隨機概率。

在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。

RoundRobin LoadBalance
輪循，按公約後的權重設置輪循比率。
存在慢的提供者累積請求問題，比如：第二台機器很慢，但沒掛，當請求調到第二台時就卡在那，久而久之，所有請求都卡在調到第二台上。

LeastActive LoadBalance
最少活躍調用數，相同活躍數的隨機，活躍數指調用前後計數差。
使慢的提供者收到更少請求，因為越慢的提供者的調用前後計數差會越大。

ConsistentHash LoadBalance
一致性Hash，相同參數的請求總是發到同一提供者。
當某一台提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。
演算法參見：http://en.wikipedia.org/wiki/Consistent_hashing。

預設只對第一個參數Hash，如果要修改，請配置<bbo:parameter key="hash.arguments" value="0,1" />

預設用160份虛擬節點，如果要修改，請配置<bbo:parameter key="hash.nodes" value="320" />

9. 伺服器集群的負載均衡演算法有哪些

輪轉(Round-Robin)演算法
加權輪轉(Weighted Round Robin)演算法
最小連接數（Least Connections）演算法
加權最小連接數（Weighted Least Connections）演算法
目的地址哈希散列（Destination Hashing Scheling）演算法
源地址哈希散列（Source Hashing Scheling）演算法
隨機（Random）演算法

導航:首頁 > 源碼編譯 > 伺服器集群演算法

伺服器集群演算法

與伺服器集群演算法相關的資料