一、集羣的原理及作用
1、什麼是集羣？
簡單來講集羣就是一組協同工作的服務器。
2、集羣化的目的？
1）高併發
2）更穩定，魯棒性高
3）時效性高
3、提升服務器性能的方式
3.1 垂直拓展
更換更強大的軟/硬件
缺點：
1）軟硬件有上限，瓶頸明顯。
首先，軟件如nginx不可能將當前的資源全部佔用掉轉化成併發量，其次操作系統本身有所限制，單個進程理論上最多支持65535個線程，換句話說單個進程最大併發量爲65535個，再乘以cpu的核心數就是理論上單臺服務器能支撐的最大併發量。一個限制是應用程序能否把當前的資源喫透，另一個就是服務器的資源能不能繼續提升。
2）升級或更換服務器時，服務器會宕機，導致服務訪問中斷。
優點：
1）技術實現難度低
2）網絡拓撲結構無需更改（最大的優點）
3.2 水平拓展
增加服務器數量
優點：
1）軟硬件上限高
2）添加節點服務不會中斷
3）性價比較高
缺點：
1）技術實現難度較高
3.3 水平拓展的常見實現方案
1）第一代水平拓展實現方案
早些年前幾乎所有的負載均衡都是通過DNS服務器實現的，通過在DNS服務器上對同一個域名添加多個不同的A記錄，使用rr輪詢機制將域名解析至不同ip的服務器。
後來由於緩存服務器記錄了域名解析結果，影響DNS服務器的訪問分配平衡，加上DNS服務器只有在使用域名訪問時才能實現負載均衡，使用面很窄，已淘汰。
2）第二代水平拓展實現方案
基本架構由Agent端，真實服務器，共享存儲3部分組成。
如Nginx反向代理時，Apache作爲web訪問負載服務器，MySQL作爲數據庫，一些基於用戶的元數據一般都記錄到數據庫中，如用戶名、密碼等。另一些數據，如視屏、用戶頭像一般都存放在共享存儲（SHARE）中。
二、常見的集羣簡介
1、負載均衡集羣（LBC）
1.1 什麼是負載均衡集羣？
LBC負載均衡集羣，將單臺服務器的壓力分擔至不同服務器的節點共同承接。
結構：前端組件（負載調度器）、真實服務器、共享存儲
1.2 思考：當集羣中web服務器訪問壓力過大時，我們可以考慮擴容，即增加真實服務器節點來解決問題。但是，若Nginx反向代理服務器壓力過大時，該如何解決？
方案一：提升前端組件，負載調度器的性能。
方案二：將不同業務分攤至不同集羣。
方案三：增加一些緩存服務器，緩存到不同的節點，提供數據支持。如鬥魚使用的CDN技術，由各個城市節點緩存數據提供數據支持。
1.3 負載調度器分類
1）按軟/硬件來區分
軟件：amoeba、Nginx、LVS、Ha-Proxy（linux-HA）
硬件：ROSE、安瑞科技、F5
2）按OSI七層模型來區分
OSI七層模型：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層
能實現負載調度器的層級爲：數據鏈路層、傳輸層、應用層
1》在第二層（數據鏈路層）實現負載調度器
實現負載調度器功能的硬件工具：F5
原理：不同的公共網線連接不同的網卡，通過不同的網卡發送數據包實現負載調度器的功能，目前支持的硬件如F5，沒有公開的軟件能支持。
實例：如國內網絡連通性較差，用戶訪問萬維網時，由於不同網絡供應商的網絡在各個城市互相沒有做匯聚，導致數據必鬚髮送到一些核心節點上才能被轉發，我們可以通過在二層網絡使用負載調度器對來自不同供應商公共網絡的訪問請求按照訪問者的ip區分其使用的公共網絡類型，再分攤到在各自公共網絡的萬維網服務器，達到始終在同一網絡完成專線訪問，提高訪問效率。
2》在第四層（傳輸層）實現負載調度器
實現負載調度器功能的工具： LVS、Ha-Proxy（linux-HA）Nginx（新版）
原理：只完成了一次TCP連接，客戶端與真實服務器。
流程：客戶端將訪問請求發送至負載調度器，負載調度器直接將請求轉發給真實服務器，真實服務器收到請求後將查到的數據發送給負載調度器，負載調度器將數據直接轉發給客戶端。
安全性：不可以攔截SYN攻擊，真實服務器易受到來自客戶端的SYN攻擊。
範圍性：由於負載調度器不需要和客戶端與真實服務器建立完整的TCP連接，所以只要是C/S結構，根據TCP UDP 開發的服務體系都可以。
併發能力：四層大於七層
3》在第七層（應用層）實現負載調度器
實現負載調度器功能的工具：Ha-Proxy（linux-HA）Nginx
提示：若要使用域名主機名的方式實現負載均衡調度器，只能在第7層完成，只有在第7層才能識別。
原理：完成2次完整的TCP連接，第一次是客戶端與負載調度器，第二次是負載調度器與真實服務器。
流程：客戶端將訪問請求發送至負載調度器，負載調度器收到請求報文後拆解，然後重新封裝，封裝好後再將新請求報文發送給真實服務器，真實服務器收到請求後將查到的數據發送給負載調度器，負載調度器再將數據發給客戶端。
安全性：可以攔截SYN攻擊。
範圍性：由於負載調度器需要同時和客戶端與真實服務器建立完整的TCP連接，所以負載調度器只能負載自己識別的協議模式。
併發能力：四層大於七層
關於第四層與第七層的總結：
集羣併發能力不強，安全性要求高，使用七層負載
集羣併發能力不強，但是必須識別域名，使用七層負載
集羣併發能力強，不管安全性要求如何，使用四層負載
集羣併發能力強，安全性要求高，使用四七層負載
2、高可用集羣（HAC）
2.1 定義
儘可能提高服務器可用性的集羣。
可用性標準：99%（及格線，相當於服務器一年的宕機總時長約3.65天）
99.9%
99.99%
99.999%（目前行業最高標準，相當於服務器一年的宕機總時長約315秒）
提示：隨着標準提高，實現成本（造價）呈指數上升。
2.2 目的
避免因負載調度器的單節點故障導致整個集羣癱瘓。
2.3 原理
2臺功能相同的服務器，一臺作爲主服務器接收用戶訪問請求並分配壓力給真實服務器，另一臺作爲熱備服務器持續向主服務器發送心跳檢測。一旦熱備服務器發現主服務器宕機，就主動接替主服務器的工作。
2.4 高可用服務器對切換ip的方式
1）網卡上開啓子接口，配置與主服務器相同的ip，配合腳本實現；
2）使用VRRP路由冗餘協議實現。
2.5 高可用集羣的缺點
資源利用率低
2.6 高可用服務器對腦分裂問題
1）什麼是腦分裂？
由於某些原因,導致兩臺高可用服務器對在指定時間內，無法檢測到對方的心跳消息，導致他們各自取得資源及服務的所有權，而此時的兩臺高可用服務器對都還活着並在正常運行，這樣就會導致一個IP或服務在兩端同時存在而發生衝突，當用戶寫入數據時可能會分別寫入到兩端，這可能會導致服務器兩端數據不一致或造成數據丟失，這種情況被稱爲腦分裂。
2）導致腦分裂可能的原因
1》高可用服務器對之間心跳線鏈路故障,導致無法正常通信。
2》心跳線壞了(包括斷了,老化)。
3》網卡及相關驅動壞了,IP配置及衝突問題(網卡直連)。
4》心跳線間連接的設備故障(網卡及交換機)。
5》採用仲裁的方案，仲裁的機器出問題。
6》高可用服務器對上開啓了iptables防火牆阻擋了心跳消息傳輸。
7》高可用服務器對上心跳網卡地址等信息配置不正確,導致發送心跳失敗。
8》其他服務配置不當等原因,如心跳方式不同,心跳廣播衝突，軟件BUG等。
9》keepalived配置裏同一VRRP示例，若virtual_router_id參數兩端配置不一致。
3）解決方案
1》冗餘心跳線
2》多次間歇性探測
3》通過網絡命令連接控制電源交換機斷掉主服務器電源
2.7 高可用集羣實現方案
軟件：heartbeat（linux-ha）、Keepalived
硬件：ROSE、安瑞科技、F5
3、高性能運算集羣（HPC）
3.1 定義
提供單臺計算機提供不了的運算能力。
3.2 原理
將要處理的某一個數據拆分成n個片段，分攤給n個計算機，每個計算機處理1個片段，最後將處理的結果彙總在一起得到最終結果。
3.3 特點
專用性強，使用面較窄
3.4 一個問題看懂高性能運算集羣與負載均衡集羣的區別
eg：一個任務A，理論上可以拆分爲10個a，現在有11臺性能相同的服務器，問題如下：
如果是構建LBC，則處理1個A，共2個節點參與運算，處理了0個a；
如果是構建HPC，則處理1個A，共11個節點參與運算，處理了10個a。