《從零開始學架構》筆記——第二部分：高性能和高可用架構模式
- 2019 年 10 月 6 日
- 筆記
第四章 存儲高性能
關係資料庫
- 讀寫分離（減輕訪問壓力） 基本原理：將資料庫讀寫操作分散到不同節點上，減小單個資料庫的訪問壓力，提高訪問效率。 基本實現：
- 資料庫伺服器搭建主從集群，一主一從或者一主多從。
- 資料庫主機負責讀寫操作，從機負責讀操作。
- 資料庫主機通過複製將數據同步到從機。
- 業務伺服器將讀寫發送到主機，將讀發送到從機。
事務問題：一致性。 【問題】 如何保證主機和從機的數據一致？？？主從複製的延遲性問題。
- 二次讀取，讀完從機再讀一次主機
- 關鍵業務指向主機，非關鍵業務指向從機
- 分庫分表（減輕存儲壓力） 分庫 將業務模組分到不同資料庫伺服器里。比如電商項目中用戶，商品，訂單就可以防在三台不同的伺服器上。 【問題】
- join操作問題 無法實現關聯查詢
- 事務問題 數據需要保持一致。比如訂單加1商品數量就會減1。（延遲性問題）
- 成本
分表 單表數據拆分有水平拆分和垂直拆分兩種。 拆分後可以放在同一資料庫中，也可以放在不同資料庫中。
- 垂直分表 將表中不常用的列拆分出去。會帶來表數量增加的複雜性。但能顯著提高查詢效率。
- 水平分表 水平分表適合錶行數特別大的表。
- 水平分表的問題
- 路由：根據什麼條件拆分表
- 範圍路由：根據有序的數據列作為路由拆分條件，比如1-999999，1000000-1999999. 建議段大小在100萬到2000萬之間 優缺點：分段大小選取具有複雜性；但可以隨著數據增加平滑擴展新的表
- Hash路由
- 配置路由
- join操作需要合併結果
- order by 操作無法在資料庫中進行，只能通過業務程式碼或者資料庫中間件分別查詢，然後匯總排序
- 路由：根據什麼條件拆分表
- 水平分表的問題
NoSQL
NoSQL分類：
- K-V存儲：Redis
- 文檔資料庫：MongoDB
- 列式資料庫：HBase
- 全文搜索引擎：ElasticSearch
快取
基本原理：將可能會重用的數據放在記憶體中，一次生成，多次使用。
【一個明星發一條微博，執行一個insert，然後n多個select】
- 快取穿透 快取沒有發揮作用，業務系統向快取中讀取，但並沒有數據。 問題：
- 存儲數據不存在
- 快取需要時間較長
- 快取雪崩 當快取失效後系統性能急劇下降。很多請求訪問資料庫，同時生成快取。 解決方案：
- 更新鎖，只能有一個執行緒生成快取。（分散式鎖）
- 後台更新。不用業務執行緒更新，而是用後台執行緒專門更新。
- 快取熱點 複製多份快取，創建快取伺服器集群，將請求分發到不同伺服器上。 【比如新浪微博上粉絲超過100w的明星發的微博，生成100份快取（當然需要100台伺服器）】
第五章 計算高性能
從物理層面上來說：
- 盡量提升單伺服器的性能，將資源發揮到極致
- 單伺服器達到性能瓶頸，設計伺服器集群方案
單伺服器高性能
集群高性能
負載均衡代替前面的任務分配。
負載均衡分類
- DNS負載均衡（實現地理級別的負載均衡）
- 硬體負載均衡（類似路由交換機）100w以上的並發，就是貴，好一點的就是一台寶馬了。
- 軟體負載均衡（Nginx&&LVS）
負載均衡演算法
- 輪詢
- 加權輪詢
- 負載最低優先
- Hash類（根據關鍵資訊進行Hash運算，將相同Hash值的請求分發到同一台伺服器山）
第六章 分散式系統設計理論CAP
對於分散式計算系統，只能滿足一致性，可用性，分區容錯性三個中的兩個。
三進二
- 一致性 所有節點在同一時刻都能看到相同的數據。（比如MySQL集群主從數據一致性）
- 可用性 非故障節點在合理時間返回合理響應。（不能是錯誤或者超時的響應）
- 分區容錯性 當出現網路分區後（網路故障，丟包網路中斷），系統可以繼續運行。
CAP細節
CAP粒度是數據，而不是系統
比如用戶帳號數據選擇CP，而其他資訊選擇AP
正常情況下，可以同時滿足CA
當發生了分區情況，也就是網路故障，才會存在CA的選擇，在網路正常的情況下，CA可以同時滿足。
ACID：
關於資料庫事務完整性的理論
- 原子性：單個事務要麼都完成，要麼都失敗（比如銀行轉賬，一個減，一個加，必須同步）
- 一致性：並發請求下數據保持一致
- 隔離性：防止多個事務並發交叉執行導致的數據不一致問題。（悲觀鎖和樂觀鎖實現）
- 持久性：事務結束後，對數據的修改就是永久的，即使系統故障也不會丟失。
BASE:
如果無法達到強一致性，那就最終一致性
- Basically Availible 基本可用 分散式系統故障時，保證核心功能可用（保持登錄可用，損失註冊）
- Soft Status 軟狀態 數據不一致
- Eventually Consistency 最終一致性
BASE理論是AP方案的延申。
第七章 存儲高可用
主備複製
- 主機存儲數據，將數據複製給備機
- 備機不提供讀寫服務
- 主機發生故障需要人工干預將備機升為主機
主從複製
- 主機存儲數據，將數據複製給備機
- 備機提供讀服務
- 主機故障可以進行讀業務，發揮了備機的性能
- 主從複製比主備複製複雜，主要體現在客戶端需要識別主從關係
- 適用寫少讀多的系統（論壇，新聞網站）
主備倒換和主從倒換
主備複製和主從複製的共性問題是主機故障，無法進行寫操作。
主備倒換和主從倒換在原有基礎上增加角色倒換的功能。
- 互連式：主備機間建立狀態傳遞的通道。 通道可以是網路連接，也可以是串口連接。
- 中介式 主備機不進行直接連接，而是通過中介傳遞資訊。（需要中介高可用） Zookeeper仲裁節點設置節點級別。
- 模擬式 將備機模擬成客戶端，模擬讀寫操作。
主主複製
- 兩台主機都有數據，通過複製通道同步
- 一致性問題很大
- 適合臨時性，可丟失，可覆蓋的場景
數據分散集群
數據分散集群指多個伺服器組成一個集群，每台伺服器都會存儲一部分數據，同時，每台伺服器會備份一部分數據。（分庫分表）
分散式事務演算法：保持一致性
2PC 二階段提交
- 第一階段：協調者向所有參與者發送請求（投票階段）（任一參與者否定都可終止提交）
- 第二階段：參與者全部通過請求，協調者提交請求。
問題：
- 同步阻塞：協調者和參與者互相等待
- 協調者單點故障
3PC 三階段提交
- 第一階段：協調者向所有參與者發送請求（投票階段），參與者有否定則事務中止，在超時時間內收到所有yes則進入第二階段。
- 第二階段：協調者發送預提交給參與者，參與者收到資訊執行事務操作，返回ACK消息。
- 第三階段：協調者收到所有的ACK消息後發送執行提交。參與者執行提交後返回已提交消息給協調者。
分散式一致性演算法
- Paxos（純理論） 特別複雜
- 多數一致性
- 讀操作也會將演算法完全執行一遍
- Raft
- Leader選舉
- 日誌複製
- 安全保證
- ZAB Zookeeper採用的分散式一致性演算法
第八章 計算高可用
當部分硬體損壞時，計算任務可以正常運行。
基本思想：通過增加更多的伺服器達到計算高可用。
主備
- 主機執行所有的計算任務
- 當主機損壞且無法恢復時，需要人工將備機升至主機，並且增加新的備機
- 冷備：程式包和配置文件準備好，啟動伺服器，但業務不啟動；溫備：業務已啟動，但不對外提供服務
- 適用內部管理系統，後台管理系統的等使用人數不多的情況
主從
- 主機執行部分任務，備機執行部分任務
- 主機故障，任務分發不變，即使主機無法正常運作
- 需要人工將備機升為主機，並添加新的備機
對稱集群（負載均衡集群）
- 正常情況下，任務分配器將任務分配給不同的主機
- 當某台伺服器故障後，任務分配器將跳過該台伺服器
- 當故障伺服器恢復後，重新分配任務
非對稱集群
Master-Slave
- 集群通過某種方式區分伺服器角色，選出Master伺服器
- 當Master伺服器故障後，推選出新的Master伺服器
- Zookeeper通過ZAB協議選取Master
第九章 業務高可用
異地多活
機房斷電，機房火災，城市地震...（但是雞蛋也不是那麼容易碎的）（不要把雞蛋放在一個籃子里）
- 同城異區
- 跨城異地
- 跨國異地
異地多活設計技巧
- 保證核心業務的異地多活
- 核心數據最終一致（異地多活不可能很快）
- 採用多種手段同步數據
- 消息隊列
- 二次讀取
- 回源讀取等等
- 保證大部分地區的異地多活（無法達到100%）
異地多活設計步驟
- 業務分級（挑選核心業務）
- 數據分類（數據量，唯一性，實時性，可恢復性）
- 數據同步（存儲系統同步，消息隊列同步等等）
- 異常處理（多通道同步，同步和訪問結合，日誌記錄，用戶補償）
介面級故障應對方案
相對與概率小的機房火災，斷電等故障，介面故障發生的情況更多。
介面級故障：
- 內部：程式問題，電腦性能到達極限，導致資料庫慢查詢
- 外部：黑客攻擊，促銷搶購導致用戶訪問量突增，第三方響應緩慢等
降級
降級是著眼與整個系統的高可用，丟車保帥的一種行為。
比如論壇的系統接近負載，暫停發帖子功能，只能看帖子。
（如果系統持續負載，伺服器崩潰，看帖子的功能也廢了）
熔斷：
是降級的一種情況。換句話說，熔斷會導致降級。
熔斷是指請求達到一個閾值，暫停該服務的調用，防止系統負載過大，導致崩潰。
限流
只讓一部分訪問通過。保證一部分響應優於全部不能響應。
- 基於請求限流（控制閾值）
- 基於資源限流（對關鍵資源限流，比如執行緒池最大並發量）