當(dāng)前大多數(shù)的互聯(lián)網(wǎng)系統(tǒng)都使用了服務(wù)器集群技術(shù)，集群是將相同服務(wù)部署在多臺服務(wù)器上構(gòu)成一個(gè)集群整體對外提供服務(wù)，這些集群可以是 Web 應(yīng)用服務(wù)器集群，也可以是數(shù)據(jù)庫服務(wù)器集群，還可以是分布式緩存服務(wù)器集群等等。

在實(shí)際應(yīng)用中，在 Web 服務(wù)器集群之前總會有一臺負(fù)載均衡服務(wù)器，負(fù)載均衡設(shè)備的任務(wù)就是作為 Web 服務(wù)器流量的入口，挑選最合適的一臺 Web 服務(wù)器，將客戶端的請求轉(zhuǎn)發(fā)給它處理，實(shí)現(xiàn)客戶端到真實(shí)服務(wù)端的透明轉(zhuǎn)發(fā)。

• LVS、Nginx、HAProxy 是目前使用最廣泛的三種軟件負(fù)載均衡軟件。

一般對負(fù)載均衡的使用是隨著網(wǎng)站規(guī)模的提升根據(jù)不同的階段來使用不同的技術(shù)。具體的應(yīng)用需求還得具體分析，如果是中小型的 Web 應(yīng)用，比如日 PV 小于1000萬，用 Nginx 就完全可以了；如果機(jī)器不少，可以用 DNS 輪詢，LVS 所耗費(fèi)的機(jī)器還是比較多的；大型網(wǎng)站或重要的服務(wù)，且服務(wù)器比較多時(shí)，可以考慮用 LVS。

目前關(guān)于網(wǎng)站架構(gòu)一般比較合理流行的架構(gòu)方案：

• Web 前端采用 Nginx/HAProxy+Keepalived 作負(fù)載均衡器；
• 后端采用 MySQ L數(shù)據(jù)庫一主多從和讀寫分離，采用 LVS+Keepalived 的架構(gòu)。（MySQL自帶主從設(shè)置，如何理解用LVS？）

LVS

LVS 是 Linux Virtual Server 的簡稱，也就是 Linux 虛擬服務(wù)器。現(xiàn)在 LVS 已經(jīng)是 Linux 標(biāo)準(zhǔn)內(nèi)核的一部分，從 Linux2.4 內(nèi)核以后，已經(jīng)完全內(nèi)置了 LVS 的各個(gè)功能模塊，無需給內(nèi)核打任何補(bǔ)丁，可以直接使用 LVS 提供的各種功能。

LVS 的體系結(jié)構(gòu)

LVS 架設(shè)的服務(wù)器集群系統(tǒng)有三個(gè)部分組成：

• 最前端的負(fù)載均衡層，用 Load Balancer 表示
• 中間的服務(wù)器集群層，用 Server Array 表示
• 最底端的數(shù)據(jù)共享存儲層，用 Shared Storage 表示

LVS 負(fù)載均衡機(jī)制

LVS 不像 HAProxy 等七層軟負(fù)載面向的是 HTTP 包，所以七層負(fù)載可以做的 URL 解析等工作，LVS 無法完成。

LVS 是四層負(fù)載均衡，也就是說建立在 OSI 模型的第四層——傳輸層之上，傳輸層上有我們熟悉的 TCP/UDP，LVS 支持 TCP/UDP 的負(fù)載均衡。因?yàn)?LVS 是四層負(fù)載均衡，因此它相對于其它高層負(fù)載均衡的解決辦法，比如 DNS 域名輪流解析、應(yīng)用層負(fù)載的調(diào)度、客戶端的調(diào)度等，它的效率是非常高的。

所謂四層負(fù)載均衡 ，也就是主要通過報(bào)文中的目標(biāo)地址和端口。七層負(fù)載均衡 ，也稱為“內(nèi)容交換”，也就是主要通過報(bào)文中的真正有意義的應(yīng)用層內(nèi)容。

LVS 的轉(zhuǎn)發(fā)主要通過修改 IP 地址（NAT 模式，分為源地址修改 SNAT 和目標(biāo)地址修改 DNAT）、修改目標(biāo) MAC（DR 模式）來實(shí)現(xiàn)。

LVS負(fù)載模式

NAT 模式：網(wǎng)絡(luò)地址轉(zhuǎn)換

NAT（Network Address Translation）是一種外網(wǎng)和內(nèi)網(wǎng)地址映射的技術(shù)。
NAT 模式下，網(wǎng)絡(luò)數(shù)據(jù)報(bào)的進(jìn)出都要經(jīng)過 LVS 的處理。LVS 需要作為 RS（真實(shí)服務(wù)器）的網(wǎng)關(guān)。

當(dāng)包到達(dá) LVS 時(shí)，LVS 做目標(biāo)地址轉(zhuǎn)換（DNAT），將目標(biāo) IP 改為 RS 的 IP。RS 接收到包以后，仿佛是客戶端直接發(fā)給它的一樣。RS 處理完，返回響應(yīng)時(shí)，源 IP 是 RS IP，目標(biāo) IP 是客戶端的 IP。這時(shí) RS 的包通過網(wǎng)關(guān)（LVS）中轉(zhuǎn)，LVS 會做源地址轉(zhuǎn)換（SNAT），將包的源地址改為 VIP，這樣，這個(gè)包對客戶端看起來就仿佛是 LVS 直接返回給它的。

DR 模式：直接路由

DR 模式下需要 LVS 和 RS 集群綁定同一個(gè) VIP（RS 通過將 VIP 綁定在 loopback 實(shí)現(xiàn)），但與 NAT 的不同點(diǎn)在于：請求由 LVS 接受，由真實(shí)提供服務(wù)的服務(wù)器（RealServer，RS）直接返回給用戶，返回的時(shí)候不經(jīng)過 LVS。

詳細(xì)來看，一個(gè)請求過來時(shí)，LVS 只需要將網(wǎng)絡(luò)幀的 MAC 地址修改為某一臺 RS 的 MAC，該包就會被轉(zhuǎn)發(fā)到相應(yīng)的 RS 處理，注意此時(shí)的源 IP 和目標(biāo) IP 都沒變，LVS 只是做了一下移花接木。RS 收到 LVS 轉(zhuǎn)發(fā)來的包時(shí)，鏈路層發(fā)現(xiàn) MAC 是自己的，到上面的網(wǎng)絡(luò)層，發(fā)現(xiàn) IP 也是自己的，于是這個(gè)包被合法地接受，RS 感知不到前面有 LVS 的存在。而當(dāng) RS 返回響應(yīng)時(shí)，只要直接向源 IP（即用戶的 IP）返回即可，不再經(jīng)過 LVS。

DR 負(fù)載均衡模式數(shù)據(jù)分發(fā)過程中不修改 IP 地址，只修改 mac 地址，由于實(shí)際處理請求的真實(shí)物理 IP 地址和數(shù)據(jù)請求目的 IP 地址一致，所以不需要通過負(fù)載均衡服務(wù)器進(jìn)行地址轉(zhuǎn)換，可將響應(yīng)數(shù)據(jù)包直接返回給用戶瀏覽器，避免負(fù)載均衡服務(wù)器網(wǎng)卡帶寬成為瓶頸。

IP隧道模式

隧道模式則類似于VPN的方式,使用網(wǎng)絡(luò)分層的原理,在從客戶端發(fā)來的數(shù)據(jù)包的基礎(chǔ)上,封裝一個(gè)新的IP頭標(biāo)記(不完整的IP頭,只有目的IP部)發(fā)給RS,RS收到后,先把DR發(fā)過來的數(shù)據(jù)包的頭給解開,還原其數(shù)據(jù)包原樣,處理后,直接返回給客戶端,而不需要再經(jīng)過DR?需要注意的是,由于REALSERVER需要對DR發(fā)過來的數(shù)據(jù)包進(jìn)行還原,也就是說必須支持IPTUNNEL協(xié)議?所以,在REALSERVER的內(nèi)核中,必須編譯支持IPTUNNEL這個(gè)選項(xiàng)?

因此，DR 模式具有較好的性能，也是目前大型網(wǎng)站使用最廣泛的一種負(fù)載均衡手段。

LVS已實(shí)現(xiàn)了以下八種調(diào)度算法:

• LVS負(fù)載均衡算法---1.輪詢調(diào)度(Round-RobinScheduling)

調(diào)度器通過"輪詢"調(diào)度算法將外部請求按順序輪流分配到集群中的真實(shí)服務(wù)器上,它均等地對待每一臺服務(wù)器,而不管服務(wù)器上實(shí)際的連接數(shù)和系統(tǒng)負(fù)載?

• LVS負(fù)載均衡算法---2.加權(quán)輪詢調(diào)度(WeightedRound-RobinScheduling)

調(diào)度器通過"加權(quán)輪詢"調(diào)度算法根據(jù)真實(shí)服務(wù)器的不同處理能力來調(diào)度訪問請求?這樣可以保證處理能力強(qiáng)的服務(wù)器處理更多的訪問流量?調(diào)度器可以自動問詢真實(shí)服務(wù)器的負(fù)載情況,并動態(tài)地調(diào)整其權(quán)值?

• LVS負(fù)載均衡算法---3.最小連接調(diào)度(Least-ConnectionScheduling)

調(diào)度器通過"最少連接"調(diào)度算法動態(tài)地將網(wǎng)絡(luò)請求調(diào)度到已建立的鏈接數(shù)最少的服務(wù)器上?如果集群系統(tǒng)的真實(shí)服務(wù)器具有相近的系統(tǒng)性能,采用"最小連接"調(diào)度算法可以較好地均衡負(fù)載?

• LVS負(fù)載均衡算法---4.加權(quán)最小連接調(diào)度(WeightedLeast-ConnectionScheduling)

在集群系統(tǒng)中的服務(wù)器性能差異較大的情況下,調(diào)度器采用"加權(quán)最少鏈接"調(diào)度算法優(yōu)化負(fù)載均衡性能,具有較高權(quán)值的服務(wù)器將承受較大比例的活動連接負(fù)載?調(diào)度器可以自動問詢真實(shí)服務(wù)器的負(fù)載情況,并動態(tài)地調(diào)整其權(quán)值

• LVS負(fù)載均衡算法---5.基于局部性的最少鏈接(Locality-BasedLeastConnectionsScheduling)

基于局部性的最少鏈接"調(diào)度算法是針對目標(biāo)IP地址的負(fù)載均衡,目前主要用于Cache集群系統(tǒng)?該算法根據(jù)請求的目標(biāo)IP地址找出該目標(biāo)IP地址最近使用的服務(wù)器,若該服務(wù)器是可用的且沒有超載,將請求發(fā)送到該服務(wù)器;若服務(wù)器不存在,或者該服務(wù)器超載且有服務(wù)器處于一半的工作負(fù)載,則用"最少鏈接"的原則選出一個(gè)可用的服務(wù)器,將請求發(fā)送到該服務(wù)器?

• LVS負(fù)載均衡算法---6.帶復(fù)制的基于局部性最少鏈接(Locality-BasedLeastConnectionswithReplicationScheduling)

帶復(fù)制的基于局部性最少鏈接"調(diào)度算法也是針對目標(biāo)IP地址的負(fù)載均衡,目前主要用于Cache集群系統(tǒng)?它與LBLC算法的不同之處是它要維護(hù)從一個(gè)目標(biāo)IP地址到一組服務(wù)器的映射,而LBLC算法維護(hù)從一個(gè)目標(biāo)IP地址到一臺服務(wù)器的映射?該算法根據(jù)請求的目標(biāo)IP地址找出該目標(biāo)IP地址對應(yīng)的服務(wù)器組,按"最小連接"原則從服務(wù)器組中選出一臺服務(wù)器,若服務(wù)器沒有超載,將請求發(fā)送到該服務(wù)器,若服務(wù)器超載;則按"最小連接"原則從這個(gè)集群中選出一臺服務(wù)器,將該服務(wù)器加入到服務(wù)器組中,將請求發(fā)送到該服務(wù)器?同時(shí),當(dāng)該服務(wù)器組有一段時(shí)間沒有被修改,將最忙的服務(wù)器從服務(wù)器組中刪除,以降低復(fù)制的程度

LVS負(fù)載均衡算法---7.目標(biāo)地址散列調(diào)度(DestinationHashingScheduling)

目標(biāo)地址散列"調(diào)度算法根據(jù)請求的目標(biāo)IP地址,作為散列鍵(HashKey)從靜態(tài)分配的散列表找出對應(yīng)的服務(wù)器,若該服務(wù)器是可用的且未超載,將請求發(fā)送到該服務(wù)器,否則返回空

LVS負(fù)載均衡算法---8.源地址散列調(diào)度(SourceHashingScheduling)

源地址散列"調(diào)度算法根據(jù)請求的源IP地址,作為散列鍵(HashKey)從靜態(tài)分配的散列表找出對應(yīng)的服務(wù)器,若該服務(wù)器是可用的且未超載,將請求發(fā)送到該服務(wù)器,否則返回空?

LVS 的優(yōu)點(diǎn)

抗負(fù)載能力強(qiáng)、是工作在傳輸層上僅作分發(fā)之用，沒有流量的產(chǎn)生，這個(gè)特點(diǎn)也決定了它在負(fù)載均衡軟件里的性能最強(qiáng)的，對內(nèi)存和 cpu 資源消耗比較低。
配置性比較低，這是一個(gè)缺點(diǎn)也是一個(gè)優(yōu)點(diǎn)，因?yàn)闆]有可太多配置的東西，所以并不需要太多接觸，大大減少了人為出錯(cuò)的幾率。
工作穩(wěn)定，因?yàn)槠浔旧砜关?fù)載能力很強(qiáng)，自身有完整的雙機(jī)熱備方案，如 LVS+Keepalived。
無流量，LVS 只分發(fā)請求，而流量并不從它本身出去，這點(diǎn)保證了均衡器 IO 的性能不會受到大流量的影響。
應(yīng)用范圍比較廣，因?yàn)?LVS 工作在傳輸層，所以它幾乎可以對所有應(yīng)用做負(fù)載均衡，包括 http、數(shù)據(jù)庫、在線聊天室等等。

LVS 的缺點(diǎn)

軟件本身不支持正則表達(dá)式處理，不能做動靜分離；而現(xiàn)在許多網(wǎng)站在這方面都有較強(qiáng)的需求，這個(gè)是 Nginx、HAProxy+Keepalived 的優(yōu)勢所在。
如果是網(wǎng)站應(yīng)用比較龐大的話，LVS/DR+Keepalived 實(shí)施起來就比較復(fù)雜了，相對而言，Nginx/HAProxy+Keepalived就簡單多了

通過ipvsadm 或者 keepAlive進(jìn)行配置管理

Nginx

Nginx 是一個(gè)強(qiáng)大的 Web 服務(wù)器軟件，用于處理高并發(fā)的 HTTP 請求和作為反向代理服務(wù)器做負(fù)載均衡。具有高性能、輕量級、內(nèi)存消耗少，強(qiáng)大的負(fù)載均衡能力等優(yōu)勢。

Nignx 的架構(gòu)設(shè)計(jì)

相對于傳統(tǒng)基于進(jìn)程或線程的模型（Apache就采用這種模型）在處理并發(fā)連接時(shí)會為每一個(gè)連接建立一個(gè)單獨(dú)的進(jìn)程或線程，且在網(wǎng)絡(luò)或者輸入/輸出操作時(shí)阻塞。這將導(dǎo)致內(nèi)存和 CPU 的大量消耗，因?yàn)樾缕鹨粋€(gè)單獨(dú)的進(jìn)程或線程需要準(zhǔn)備新的運(yùn)行時(shí)環(huán)境，包括堆和棧內(nèi)存的分配，以及新的執(zhí)行上下文，當(dāng)然，這些也會導(dǎo)致多余的 CPU 開銷。最終，會由于過多的上下文切換而導(dǎo)致服務(wù)器性能變差。

反過來，Nginx 的架構(gòu)設(shè)計(jì)是采用模塊化的、基于事件驅(qū)動、異步、單線程且非阻塞。

Nginx 大量使用多路復(fù)用和事件通知，Nginx 啟動以后，會在系統(tǒng)中以 daemon 的方式在后臺運(yùn)行，其中包括一個(gè) master 進(jìn)程，n(n>=1) 個(gè) worker 進(jìn)程。所有的進(jìn)程都是單線程（即只有一個(gè)主線程）的，且進(jìn)程間通信主要使用共享內(nèi)存的方式。

其中，master 進(jìn)程用于接收來自外界的信號，并給 worker 進(jìn)程發(fā)送信號，同時(shí)監(jiān)控 worker 進(jìn)程的工作狀態(tài)。worker 進(jìn)程則是外部請求真正的處理者，每個(gè) worker 請求相互獨(dú)立且平等的競爭來自客戶端的請求。請求只能在一個(gè) worker 進(jìn)程中被處理，且一個(gè) worker 進(jìn)程只有一個(gè)主線程，所以同時(shí)只能處理一個(gè)請求。（原理同 Netty 很像）

Nginx 負(fù)載均衡

Nginx 負(fù)載均衡主要是對七層網(wǎng)絡(luò)通信模型中的第七層應(yīng)用層上的 http、https 進(jìn)行支持。

Nginx 是以反向代理的方式進(jìn)行負(fù)載均衡的。反向代理（Reverse Proxy）方式是指以代理服務(wù)器來接受 Internet 上的連接請求，然后將請求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給 Internet 上請求連接的客戶端，此時(shí)代理服務(wù)器對外就表現(xiàn)為一個(gè)服務(wù)器。

Nginx 實(shí)現(xiàn)負(fù)載均衡的分配策略有很多，Nginx 的 upstream 目前支持以下幾種方式：

• 輪詢（默認(rèn)）：每個(gè)請求按時(shí)間順序逐一分配到不同的后端服務(wù)器，如果后端服務(wù)器 down 掉，能自動剔除。
• weight：指定輪詢幾率，weight 和訪問比率成正比，用于后端服務(wù)器性能不均的情況。
• ip_hash：每個(gè)請求按訪問 ip 的 hash 結(jié)果分配，這樣每個(gè)訪客固定訪問一個(gè)后端服務(wù)器，可以解決 session 的問題。
• fair（第三方）：按后端服務(wù)器的響應(yīng)時(shí)間來分配請求，響應(yīng)時(shí)間短的優(yōu)先分配。
• url_hash（第三方）：按訪問 url 的 hash 結(jié)果來分配請求，使每個(gè) url 定向到同一個(gè)后端服務(wù)器，后端服務(wù)器為緩存時(shí)比較有效。

Nginx 的優(yōu)點(diǎn)

跨平臺：Nginx 可以在大多數(shù) Unix like OS編譯運(yùn)行，而且也有 Windows 的移植版本
配置異常簡單：非常容易上手。配置風(fēng)格跟程序開發(fā)一樣，神一般的配置
非阻塞、高并發(fā)連接：官方測試能夠支撐5萬并發(fā)連接，在實(shí)際生產(chǎn)環(huán)境中跑到2～3萬并發(fā)連接數(shù)
事件驅(qū)動：通信機(jī)制采用 epoll 模型，支持更大的并發(fā)連接
Master/Worker 結(jié)構(gòu)：一個(gè) master 進(jìn)程，生成一個(gè)或多個(gè) worker 進(jìn)程
內(nèi)存消耗小：處理大并發(fā)的請求內(nèi)存消耗非常小。在3萬并發(fā)連接下，開啟的10個(gè) Nginx 進(jìn)程才消耗150M 內(nèi)存（15M*10=150M）
內(nèi)置的健康檢查功能：如果 Nginx 代理的后端的某臺 Web 服務(wù)器宕機(jī)了，不會影響前端訪問
節(jié)省帶寬：支持 GZIP 壓縮，可以添加瀏覽器本地緩存的 Header 頭
穩(wěn)定性高：用于反向代理，宕機(jī)的概率微乎其微

Nginx 的缺點(diǎn)

• 通常我們理解Nginx只是七層負(fù)載(支持http、https 和 Email 協(xié)議)，后經(jīng)網(wǎng)友Godfree
  （見評論）提示，nginx-1.9.0后可支持四層的負(fù)載（ mainline version has been released, with the stream module for generic TCP proxying and load balancing）
• 對后端服務(wù)器的健康檢查，只支持通過端口來檢測，不支持通過 ur l來檢測。
• 不支持 Session 的直接保持，但能通過 ip_hash 來解決

HAProxy

HAProxy 支持兩種代理模式 TCP（四層）和HTTP（七層），也是支持虛擬主機(jī)的。

HAProxy 的優(yōu)點(diǎn)能夠補(bǔ)充 Nginx 的一些缺點(diǎn)，比如支持 Session 的保持，Cookie 的引導(dǎo)；同時(shí)支持通過獲取指定的 url 來檢測后端服務(wù)器的狀態(tài)。

HAProxy 跟 LVS 類似，本身就只是一款負(fù)載均衡軟件；單純從效率上來講 HAProxy 會比 Nginx 有更出色的負(fù)載均衡速度，在并發(fā)處理上也是優(yōu)于 Nginx 的。

HAProxy 支持 TCP 協(xié)議的負(fù)載均衡轉(zhuǎn)發(fā)，可以對 MySQL 讀進(jìn)行負(fù)載均衡，對后端的 MySQL 節(jié)點(diǎn)進(jìn)行檢測和負(fù)載均衡，大家可以用 LVS+Keepalived 對 MySQL 主從做負(fù)載均衡。

HAProxy 負(fù)載均衡策略非常多：Round-robin（輪循）、Weight-round-robin（帶權(quán)輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據(jù)cookie）。

什么是keepalived

• keepalived是保證集群高可用的一個(gè)服務(wù)軟件，其功能類似于heartbeat，用來防止單點(diǎn)故障。
• 以VRRP協(xié)議為實(shí)現(xiàn)基礎(chǔ)的，VRRP全稱Virtual Router Redundancy Protocol，即虛擬路由冗余協(xié)議。
• keepalived是可以工作在第三層、第四層、第五層的檢測服務(wù)器狀態(tài)的軟件，
• 如果有一臺web服務(wù)器死機(jī)，或工作出現(xiàn)故障，keepalived將檢測到，并將其從系統(tǒng)中剔除
  當(dāng)web服務(wù)器工作正常后keepalived自動將web服務(wù)器加入到服務(wù)器集群中

Keepalived的工作原理

• 三層、四層、五層工作在TCP/IP協(xié)議棧的IP層、TCP層、應(yīng)用層。原理如下：

• 三層：keepalived使用三層方式工作是，keepalived會定期向服務(wù)器集群中的服務(wù)器發(fā)送一個(gè)IMCP的數(shù)據(jù)包，也就是ping程序，如果發(fā)現(xiàn)某臺服務(wù)器的IP地址沒有激活，keepalived便報(bào)告這臺服務(wù)器失效，并將它從集群中刪除，這種情況的典型例子是某臺服務(wù)器被非法關(guān)機(jī)。三層的方式是以服務(wù)器的IP地址是否有效作為服務(wù)器工作正常與否的標(biāo)準(zhǔn)。

• 四層：主要是以TCP端口的狀態(tài)來決定服務(wù)器工作正常與否。如web服務(wù)器的端口一般是80，如果keepalived檢測到80端口沒有啟動，則keepalived將這臺服務(wù)器從集群中剔除。

• 五層：應(yīng)用層，比三層和四層要復(fù)雜一點(diǎn)，keepalived將根據(jù)用戶的設(shè)定檢查服務(wù)器程序運(yùn)行是否正常，如果與用戶設(shè)定的不相符，則keepalived將把服務(wù)器從服務(wù)器集群中剔除。

• 基于VRRP虛擬路由冗余協(xié)議，可以認(rèn)為是實(shí)現(xiàn)路由器高可用的協(xié)議，即將N臺提供相同功能的路由器組成一個(gè)路由器組，這個(gè)組里面有一個(gè)master和多個(gè)backup，master上面有一個(gè)對外提供服務(wù)的vip（該路由器所在局域網(wǎng)內(nèi)其他機(jī)器的默認(rèn)路由為該vip），master會發(fā)組播，當(dāng)backup收不到vrrp包時(shí)就認(rèn)為master宕掉了，這時(shí)就需要根據(jù)VRRP的優(yōu)先級來選舉一個(gè)backup當(dāng)master。這樣的話就可以保證路由器的高可用了。

• keepalived主要有三個(gè)模塊，分別是core、check和vrrp。core模塊為keepalived的核心，負(fù)責(zé)主進(jìn)程的啟動、維護(hù)以及全局配置文件的加載和解析。check負(fù)責(zé)健康檢查，包括常見的各種檢查方式。vrrp模塊是來實(shí)現(xiàn)VRRP協(xié)議的。

keepalived的作用

高可用-可持續(xù)的服務(wù)器質(zhì)量

負(fù)載均衡-橫向擴(kuò)展

實(shí)現(xiàn)對失效服務(wù)器的隔離-通過健康監(jiān)測，保證服務(wù)的可用性

實(shí)現(xiàn)：vrrp協(xié)議實(shí)現(xiàn)。（冗余網(wǎng)關(guān)路由協(xié)議）

keepalived體系結(jié)構(gòu)

1、watchdog 負(fù)責(zé)監(jiān)控checkers和vrrp進(jìn)程的狀況。

2、Checkers 負(fù)責(zé)真實(shí)服務(wù)器的健康監(jiān)測，是keepalived最主要的功能，換一句話說，可以沒有vrrp statck，但是健康檢查healthcheckping一定要有。

3、Vrrp statck 負(fù)責(zé)負(fù)載均衡器之間失敗切換failover。如果只用一個(gè)負(fù)載均衡器，則vrrp不是必須的。

4、Ipvs warpper是用來發(fā)送設(shè)定的規(guī)則封裝到內(nèi)核ipvs代碼。

5、Netlink reflector 用來設(shè)定vrrp的vip地址等。

Keepalived功能十分強(qiáng)大，但是配置工作十分簡單，keepalived各種功能的實(shí)現(xiàn)是通過設(shè)定配置文件keepalived.conf來完成的。

Ref：
http://www.talkwithtrend.com/Article/216127
http://outofmemory.cn/wiki/keepalived-configuration 【keepalived】