在聊如何構建高可用系統之前，我們需要對"可用"下乙個定義。
業界常用sla（service level agreement）來描述乙個系統對外部系統承諾的可用性,sla包含很多資訊（服務內容、故障恢復時間、可用性等）， 在這裡我們籠統的用「n個9」來指代，比如4個9指的是99.99%的可用性、 5個9指的是99.999%的可用性。
假如乙個系統聲稱它的年可用性是4個9， 那它提供的可用性承諾就是一年之內， 不可用時間不超過52.56分鐘（60 * 24 * 365 * 0.0001）。
在此基礎之上，我們來看看， 系統需要做到什麼程度， 可以稱為高可用：
低故障總時長： 一般認為4個9以上才有資格稱為高可用
快速的故障恢復： 即使乙個系統一年只掛一次但是需要52分鐘才能恢復（那麼這個系統的年可用性是4個9）， 那其實也是不能接受的。
為什麼要構建高可用系統？ 這個其實不必多說，大家都懂， 因此一筆帶過。 系統的高可用對於個人口碑、產品、公司的形象、營收、股價，甚至社會穩定， 都至關重要。
在著手構建高可用系統之前，我們需要知道是哪些因素在阻礙我們提高系統的可用性：
一切單點都是不可靠的, 如果系統中某個地方可能會出問題（就算概率很低），那麼它遲早會出問題。 也就是我們常說的murphy』s law。
系統依賴的一切下游系統都是不可靠的， 它們隨時可能出問題
系統的上游可能有多個， 而且每個上游的行為都是不可預知的。如果某個上游抽風把我的系統搞崩， 那麼就會影響所有的上游
高可用是有前提條件的，乙個系統對當前的負載能提供高可用， 不代表負載上公升之後仍然高可用
"人"是不可靠的， 費勁心思設計的高可用系統，會因為新引入乙個低階錯誤而崩潰
高可用需要指標來衡量， 我們不能靠嘴來構建高可用系統
知道了問題所在， 那麼就有解決的方向了：
既然單點肯定會出問題，那麼我們就避免單點
既然下游肯定會出問題， 那麼我們得處理下游不可用的情況
既然某個上游的抽風行為會影響別的上游， 那麼我們需要想辦法來最小化這種影響
既然系統只能在一定負載內提供高可用， 那麼我們就得為系統構建一套過載保護機制
既然「人」肯定會犯錯， 那麼我們就引入各種機制，來減少犯錯的概率， 以及減少犯錯的損失
為系統構建一套監控， 資料說話
高可用高效能系統（一）系統應用場景
建設乙個高可用高效能的系統是我最近幾年的努力目標，但其中涉及的內容頗多，都是些零星的經驗，缺乏系統性架構總結。寫這個系列的文章其實是我一直以來的想法，不過題材和內容過多，所以一直擱置。前些日子到一家公司面試，備受打擊，覺得有必要把它總結一下。我假定要為 交易建設乙個高可用高效能的系統，那麼 交易就是...
構建高可用的flask mvc框架
這裡構建的flask mvc框架是最基礎的版本，用於後續開發的乙個mvc模板 外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳 img dqczwn0p 1607261415885 en resource database 556 1 對flaks進行乙個封裝，達到即用即建立from fl...
構建自己的 LINUX 系統（一）
實驗目標 基於tiny core構建一款迷你的 linux 發行版系統。技能要點 準備工具 乙個 linux 開發環境 如 ubuntu debian makefile 在內的常用開發工具 虛擬機器 qemu 或 virtualbox 都可以 syslinux utils debian ubuntu...