維基百科高可用的定義：
系統(tǒng)無中斷地執(zhí)行其功能的能力，代表系統(tǒng)的可用性程度，是進行系統(tǒng)設(shè)計時的準(zhǔn)則之一。
這個定義的關(guān)鍵在于“無中斷”，但恰好難點也在“無中斷”上面，因為無論是單個硬件還是單個軟件，都不可能做到無中斷，硬件會出故障，軟件會有 BUG；硬件會逐漸老化，軟件會越來越復(fù)雜和龐大……
系統(tǒng)的高可用本質(zhì)上都是通過“冗余”來實現(xiàn)高可用。高可用的“冗余”解決方案，單純從形式上來看，和高性能是一樣的，都是通過增加更多機器來達到目的，但其實本質(zhì)上是有根本區(qū)別的：高性能增加機器目的在于“擴展”處理性能；高可用增加機器目的在于“冗余”處理單元。通過冗余增強了可用性，但同時也帶來了復(fù)雜性。
計算高可用
這里的“計算”指的是業(yè)務(wù)的邏輯處理。計算有一個特點就是無論在哪臺機器上進行計算，同樣的算法和輸入數(shù)據(jù)，產(chǎn)出的結(jié)果都是一樣的，所以將計算從一臺機器遷移到另外一臺機器，對業(yè)務(wù)并沒有什么影響。
單機變雙機架構(gòu)
需要增加一個任務(wù)分配器，選擇合適的任務(wù)分配器也是一件復(fù)雜的事情，需要綜合考慮性能、成本、可維護性、可用性等各方面因素。
任務(wù)分配器和真正的業(yè)務(wù)服務(wù)器之間有連接和交互，需要選擇合適的連接方式，并且對連接進行管理。例如，連接建立、連接檢測、連接中斷后如何處理等。
任務(wù)分配器需要增加分配算法。例如，常見的雙機算法有主備、主主，主備方案又可以細(xì)分為冷備、溫備、熱備。
高可用集群架構(gòu)
這個高可用集群相比雙機來說，分配算法更加復(fù)雜，可以是 1 主 3 備、2 主 2 備、3 主 1 備、4 主 0 備，具體應(yīng)該采用哪種方式，需要結(jié)合實際業(yè)務(wù)需求來分析和判斷，并不存在某種算法就一定優(yōu)于另外的算法。例如，ZooKeeper 采用的就是 1 主多備，而 Memcached 采用的就是全主 0 備。
ZooKeeper 是一個分布式的，開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，是 Google 的 Chubby 一個開源的實現(xiàn)，是 Hadoop 和 Hbase 的重要組件。
Memcached 是一個高性能的分布式內(nèi)存對象緩存系統(tǒng)，用于動態(tài) Web 應(yīng)用以減輕數(shù)據(jù)庫負(fù)載。它通過在內(nèi)存中緩存數(shù)據(jù)和對象來減少讀取數(shù)據(jù)庫的次數(shù)，從而提高動態(tài)、數(shù)據(jù)庫驅(qū)動網(wǎng)站的速度。
存儲高可用
對于需要存儲數(shù)據(jù)的系統(tǒng)來說，整個系統(tǒng)的高可用設(shè)計關(guān)鍵點和難點就在于“存儲高可用”。存儲與計算相比，有一個本質(zhì)上的區(qū)別：將數(shù)據(jù)從一臺機器搬到到另一臺機器，需要經(jīng)過線路進行傳輸。線路傳輸?shù)乃俣仁呛撩爰墑e，同一機房內(nèi)部能夠做到幾毫秒；分布在不同地方的機房，傳輸耗時需要幾十甚至上百毫秒。例如，從廣州機房到北京機房，穩(wěn)定情況下 ping 延時大約是 50ms，不穩(wěn)定情況下可能達到 1s 甚至更多。
雖然毫秒對于人來說幾乎沒有什么感覺，但是對于高可用系統(tǒng)來說，就是本質(zhì)上的不同，這意味著整個系統(tǒng)在某個時間點上，數(shù)據(jù)肯定是不一致的。按照“數(shù)據(jù) + 邏輯 = 業(yè)務(wù)”這個公式來套的話，數(shù)據(jù)不一致，即使邏輯一致，最后的業(yè)務(wù)表現(xiàn)就不一樣了。
除了物理上的傳輸速度限制，傳輸線路本身也存在可用性問題，傳輸線路可能中斷、可能擁塞、可能異常（錯包、丟包），并且傳輸線路的故障時間一般都特別長，短的十幾分鐘，長的幾個小時都是可能的。例如，2015 年支付寶因為光纜被挖斷，業(yè)務(wù)影響超過 4 個小時；2016 年中美海底光纜中斷 3 小時等。在傳輸線路中斷的情況下，就意味著存儲無法進行同步，在這段時間內(nèi)整個系統(tǒng)的數(shù)據(jù)是不一致的。
綜合分析，無論是正常情況下的傳輸延遲，還是異常情況下的傳輸中斷，都會導(dǎo)致系統(tǒng)的數(shù)據(jù)在某個時間點或者時間段是不一致的，而數(shù)據(jù)的不一致又會導(dǎo)致業(yè)務(wù)問題；但如果完全不做冗余，系統(tǒng)的整體高可用又無法保證，所以存儲高可用的難點不在于如何備份數(shù)據(jù)，而在于如何減少或者規(guī)避數(shù)據(jù)不一致對業(yè)務(wù)造成的影響。
分布式領(lǐng)域里面有一個著名的 CAP 定理，從理論上論證了存儲高可用的復(fù)雜度。也就是說，存儲高可用不可能同時滿足“一致性、可用性、分區(qū)容錯性”，最多滿足其中兩個，這就要求我們在做架構(gòu)設(shè)計時結(jié)合業(yè)務(wù)進行取舍。
在理論計算機科學(xué)中，CAP定理（CAP theorem），又被稱作布魯爾定理（Brewer's theorem），它指出對于一個分布式計算系統(tǒng)來說，不可能同時滿足以下三點：
- 一致性（Consistence）等同于所有節(jié)點訪問同一份最新的數(shù)據(jù)副本。
- 可用性（Availability）每次請求都能獲取到非錯的響應(yīng)——但是不保證獲取的數(shù)據(jù)為最新數(shù)據(jù)。
- 分區(qū)容錯性（Partition tolerance）以實際效果而言，分區(qū)相當(dāng)于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間做出選擇。
根據(jù)定理，分布式系統(tǒng)只能滿足三項中的兩項而不可能滿足全部三項。理解 CAP 理論的最簡單方式是想象兩個節(jié)點分處分區(qū)兩側(cè)。允許至少一個節(jié)點更新狀態(tài)會導(dǎo)致數(shù)據(jù)不一致，即喪失了 C 性質(zhì)。如果為了保證數(shù)據(jù)一致性，將分區(qū)一側(cè)的節(jié)點設(shè)置為不可用，那么又喪失了 A 性質(zhì)。除非兩個節(jié)點可以互相通信，才能既保證 C 又保證 A，這又會導(dǎo)致喪失 P 性質(zhì)。
高可用狀態(tài)決策
無論是計算高可用還是存儲高可用，其基礎(chǔ)都是“狀態(tài)決策”，即系統(tǒng)需要能夠判斷當(dāng)前的狀態(tài)是正常還是異常，如果出現(xiàn)了異常就要采取行動來保證高可用。如果狀態(tài)決策本身都是有錯誤或者有偏差的，那么后續(xù)的任何行動和處理無論多么完美也都沒有意義和價值。但在具體實踐的過程中，恰好存在一個本質(zhì)的矛盾：通過冗余來實現(xiàn)的高可用系統(tǒng)，狀態(tài)決策本質(zhì)上就不可能做到完全正確。下面我基于幾種常見的決策方式進行詳細(xì)分析。
獨裁式
獨裁式?jīng)Q策指的是存在一個獨立的決策主體，我們姑且稱它為“決策者”，負(fù)責(zé)收集信息然后進行決策；所有冗余的個體，我們姑且稱它為“上報者”，都將狀態(tài)信息發(fā)送給決策者。
獨裁式的決策方式不會出現(xiàn)決策混亂的問題，因為只有一個決策者，但問題也正是在于只有一個決策者。當(dāng)決策者本身故障時，整個系統(tǒng)就無法實現(xiàn)準(zhǔn)確的狀態(tài)決策。如果決策者本身又做一套狀態(tài)決策，那就陷入一個遞歸的死循環(huán)了。
協(xié)商式
協(xié)商式?jīng)Q策指的是兩個獨立的個體通過交流信息，然后根據(jù)規(guī)則進行決策，最常用的協(xié)商式?jīng)Q策就是主備決策。
這個架構(gòu)的基本協(xié)商規(guī)則可以設(shè)計成：
- 2 臺服務(wù)器啟動時都是備機。
- 2 臺服務(wù)器建立連接。
- 2 臺服務(wù)器交換狀態(tài)信息。
- 某 1 臺服務(wù)器做出決策，成為主機；另一臺服務(wù)器繼續(xù)保持備機身份。
協(xié)商式?jīng)Q策的架構(gòu)不復(fù)雜，規(guī)則也不復(fù)雜，其難點在于，如果兩者的信息交換出現(xiàn)問題（比如主備連接中斷），此時狀態(tài)決策應(yīng)該怎么做。
- 如果備機在連接中斷的情況下認(rèn)為主機故障，那么備機需要升級為主機，但實際上此時主機并沒有故障，那么系統(tǒng)就出現(xiàn)了兩個主機，這與設(shè)計初衷（1 主 1 備）是不符合的。
- 如果備機在連接中斷的情況下不認(rèn)為主機故障，則此時如果主機真的發(fā)生故障，那么系統(tǒng)就沒有主機了，這同樣與設(shè)計初衷（1 主 1 備）是不符合的。
- 如果為了規(guī)避連接中斷對狀態(tài)決策帶來的影響，可以增加更多的連接。例如，雙連接、三連接。這樣雖然能夠降低連接中斷對狀態(tài)帶來的影響（注意：只能降低，不能徹底解決），但同時又引入了這幾條連接之間信息取舍的問題，即如果不同連接傳遞的信息不同，應(yīng)該以哪個連接為準(zhǔn)？實際上這也是一個無解的答案，無論以哪個連接為準(zhǔn)，在特定場景下都可能存在問題。
綜合分析，協(xié)商式狀態(tài)決策在某些場景總是存在一些問題的。
民主式
民主式?jīng)Q策指的是多個獨立的個體通過投票的方式來進行狀態(tài)決策。例如，ZooKeeper 集群在選舉 leader 時就是采用這種方式。
民主式?jīng)Q策和協(xié)商式?jīng)Q策比較類似，其基礎(chǔ)都是獨立的個體之間交換信息，每個個體做出自己的決策，然后按照“多數(shù)取勝”的規(guī)則來確定最終的狀態(tài)。不同點在于民主式?jīng)Q策比協(xié)商式?jīng)Q策要復(fù)雜得多，ZooKeeper 的選舉算法 Paxos，絕大部分人都看得云里霧里，更不用說用代碼來實現(xiàn)這套算法了。
除了算法復(fù)雜，民主式?jīng)Q策還有一個固有的缺陷：腦裂。這個詞來源于醫(yī)學(xué)，指人體左右大腦半球的連接被切斷后，左右腦因為無法交換信息，導(dǎo)致各自做出決策，然后身體受到兩個大腦分別控制，會做出各種奇怪的動作。例如：當(dāng)一個腦裂患者更衣時，他有時會一只手將褲子拉起，另一只手卻將褲子往下脫。腦裂的根本原因是，原來統(tǒng)一的集群因為連接中斷，造成了兩個獨立分隔的子集群，每個子集群單獨進行選舉，于是選出了 2 個主機，相當(dāng)于人體有兩個大腦了。
從圖中可以看到，正常狀態(tài)的時候，節(jié)點 5 作為主節(jié)點，其他節(jié)點作為備節(jié)點；當(dāng)連接發(fā)生故障時，節(jié)點 1、節(jié)點 2、節(jié)點 3 形成了一個子集群，節(jié)點 4、節(jié)點 5 形成了另外一個子集群，這兩個子集群的連接已經(jīng)中斷，無法進行信息交換。按照民主決策的規(guī)則和算法，兩個子集群分別選出了節(jié)點 2 和節(jié)點 5 作為主節(jié)點，此時整個系統(tǒng)就出現(xiàn)了兩個主節(jié)點。這個狀態(tài)違背了系統(tǒng)設(shè)計的初衷，兩個主節(jié)點會各自做出自己的決策，整個系統(tǒng)的狀態(tài)就混亂了。
為了解決腦裂問題，民主式?jīng)Q策的系統(tǒng)一般都采用“投票節(jié)點數(shù)必須超過系統(tǒng)總節(jié)點數(shù)一半”規(guī)則來處理。如圖中那種情況，節(jié)點 4 和節(jié)點 5 形成的子集群總節(jié)點數(shù)只有 2 個，沒有達到總節(jié)點數(shù) 5 個的一半，因此這個子集群不會進行選舉。這種方式雖然解決了腦裂問題，但同時降低了系統(tǒng)整體的可用性，即如果系統(tǒng)不是因為腦裂問題導(dǎo)致投票節(jié)點數(shù)過少，而真的是因為節(jié)點故障（例如，節(jié)點 1、節(jié)點 2、節(jié)點 3 真的發(fā)生了故障），此時系統(tǒng)也不會選出主節(jié)點，整個系統(tǒng)就相當(dāng)于宕機了，盡管此時還有節(jié)點 4 和節(jié)點 5 是正常的。
綜合分析，無論采取什么樣的方案，狀態(tài)決策都不可能做到任何場景下都沒有問題，但完全不做高可用方案又會產(chǎn)生更大的問題，如何選取適合系統(tǒng)的高可用方案，也是一個復(fù)雜的分析、判斷和選擇的過程。
本節(jié)總結(jié)
高可用與高性能，是架構(gòu)設(shè)計中兩個非常重要的決策因素。因此，面對不同業(yè)務(wù)系統(tǒng)的不同需求，對高可用與高性能也會有不同的決策結(jié)論，其實現(xiàn)的復(fù)雜度也各不相同。支付寶業(yè)務(wù)，對于可用性和性能就會有很高的要求，在可用性方面希望能提供 7＊24 不間斷服務(wù)，在高性能方面則希望能實時收付款；而對于一個學(xué)生管理系統(tǒng)，在可用性與性能方面就不一定要有多高的要求，比如晚上可關(guān)機，幾秒內(nèi)能查詢到信息也可接受。為此，高可用性與高性能的復(fù)雜度討論需要結(jié)合業(yè)務(wù)需求。
什么是可用性
定義可用性，可以先定義什么是不可用。需要經(jīng)歷若干環(huán)節(jié)，網(wǎng)站的頁面才能呈現(xiàn)在最終的用戶面前；而其中的任何一個環(huán)節(jié)出現(xiàn)了故障，都可能會導(dǎo)致網(wǎng)站的頁面不可訪問，也就是出現(xiàn)了網(wǎng)站不可用的情況。昨夜 iOS 版本 QQ 出現(xiàn)大面積閃退就是一個系統(tǒng)不可用的典型案例。
我們可以利用百分比來對網(wǎng)站可用性進行度量：
網(wǎng)站不可用時間 = 完成故障修復(fù)的時間點 - 故障發(fā)現(xiàn)的時間點網(wǎng)站年度可用時間 = 年度總時間 - 網(wǎng)站不可用時間網(wǎng)站年度可用性 = (網(wǎng)站年度可用時間 / 年度總時間) x 100%
舉例：一些知名大型網(wǎng)站的可用性可達到 99.99%（俗稱 4 個 9），我們可以算一下一年下來留給處理故障的時間有多少？
年度總時間 = 365 \* 24 \* 60 = 525600 分鐘
網(wǎng)站不可用時間 = 525600 \* (1 - 99.99%) = 52.56 分鐘
也就是，如果網(wǎng)站要達到 4 個 9 的可用性，一年下來網(wǎng)站不可用時間最多 53 分鐘（也就是不足 1 個小時）。
可見，高可用性就是技術(shù)實力的象征，高可用性就是競爭力。
為什么會出現(xiàn)不可用
硬件故障。網(wǎng)站多運行在普通的商用服務(wù)器，而這些服務(wù)器本身就不具備高可用性，再加之網(wǎng)站系統(tǒng)背后有數(shù)量眾多服務(wù)器，那么一定時間內(nèi)服務(wù)器宕機是大概率事件，直接導(dǎo)致部署在該服務(wù)器上的服務(wù)受影響。
軟件 BUG 或網(wǎng)站更新升級發(fā)布。BUG 不能消滅，只能減少；上線后的系統(tǒng)在運行過程中，難免會出現(xiàn)故障，而這些故障同樣直接導(dǎo)致某些網(wǎng)站服務(wù)不可用；此外，網(wǎng)站更新升級發(fā)布也會引起相對較頻繁的服務(wù)器宕機。
不可抗拒力。如地震、水災(zāi)、戰(zhàn)爭等。
如何做到高可用
核心思想：網(wǎng)站高可用的主要技術(shù)手段是服務(wù)與數(shù)據(jù)的冗余備份與失效轉(zhuǎn)移。同一服務(wù)組件部署在多臺服務(wù)器上；數(shù)據(jù)存儲在多臺服務(wù)器上互相備份。通過上述技術(shù)手段，當(dāng)任何一臺服務(wù)器宕機或出現(xiàn)各種不可預(yù)期的問題時，就將相應(yīng)的服務(wù)切換到其他可用的服務(wù)器上，不影響系統(tǒng)的整體可用性，也不會導(dǎo)致數(shù)據(jù)丟失。
從架構(gòu)角度看可用性：當(dāng)前網(wǎng)站系統(tǒng)多采用經(jīng)典的分層模型，從上到下為：應(yīng)用層、服務(wù)層與數(shù)據(jù)層。應(yīng)用層主要實現(xiàn)業(yè)務(wù)邏輯處理；服務(wù)層提供可復(fù)用的服務(wù)；數(shù)據(jù)層負(fù)責(zé)數(shù)據(jù)讀寫；在部署架構(gòu)上常采用應(yīng)用和數(shù)據(jù)分離部署，應(yīng)用會部署到不同服務(wù)器上，這些服務(wù)器被稱為應(yīng)用層的服務(wù)器；這些可復(fù)用的服務(wù)也會各自部署在不同服務(wù)器上，稱為服務(wù)層的服務(wù)器；而各類數(shù)據(jù)庫系統(tǒng)、文件柜等數(shù)據(jù)則部署在數(shù)據(jù)層的服務(wù)器。
硬件故障方面引起不可用的技術(shù)解決措施：
- 應(yīng)用服務(wù)器。可通過負(fù)載均衡設(shè)備將多個應(yīng)用服務(wù)器構(gòu)建為集群對外提供服務(wù)（前提是這些服務(wù)需要設(shè)計為無狀態(tài)，即應(yīng)用服務(wù)器不保存業(yè)務(wù)的上下文信息，而僅根據(jù)每次請求提交的數(shù)據(jù)進行業(yè)務(wù)邏輯的操作響應(yīng)），當(dāng)均衡設(shè)備通過心跳檢測手段檢測到應(yīng)用服務(wù)器不可用時，則將其從集群中移除，并將請求切換到其他可用的應(yīng)用服務(wù)上。
- 服務(wù)層服務(wù)器。這些服務(wù)器被應(yīng)用層通過分布式服務(wù)框架（如Dubbo）訪問，分布式服務(wù)框架可在應(yīng)用層客戶端程序中實現(xiàn)軟件負(fù)載均衡，并通過服務(wù)注冊中心提供服務(wù)的服務(wù)器進行心跳檢測，當(dāng)發(fā)現(xiàn)有服務(wù)器不可用時，立即通知客戶端程序修改服務(wù)列表，同時移除響應(yīng)的服務(wù)器。
- 數(shù)據(jù)服務(wù)器。需要在數(shù)據(jù)寫入時進行數(shù)據(jù)同步復(fù)制，將數(shù)據(jù)寫入多臺服務(wù)器上，實現(xiàn)數(shù)據(jù)冗余備份；當(dāng)數(shù)據(jù)服務(wù)器宕機時，應(yīng)用程序?qū)⒃L問切換到有備份數(shù)據(jù)的服務(wù)器上。
軟件方面引起不可用的技術(shù)解決措施：
- 通過軟件開發(fā)過程進行質(zhì)量保證。
- 通過預(yù)發(fā)布驗證、嚴(yán)格測試、灰度發(fā)布等手段，盡量減少上線服務(wù)的故障。
