第四章 存儲高性能
關系數據庫
-
讀寫分離（減輕訪問壓力）
基本原理：將數據庫讀寫操作分散到不同節點上，減小單個數據庫的訪問壓力，提高訪問效率。
基本實現：
- 數據庫服務器搭建主從集群，一主一從或者一主多從。
- 數據庫主機負責讀寫操作，從機負責讀操作。
- 數據庫主機通過復制將數據同步到從機。
- 業務服務器將讀寫發送到主機，將讀發送到從機。
事務問題：一致性。
【問題】
如何保證主機和從機的數據一致？？？主從復制的延遲性問題。
- 二次讀取，讀完從機再讀一次主機
- 關鍵業務指向主機，非關鍵業務指向從機
-
分庫分表（減輕存儲壓力）
分庫
將業務模塊分到不同數據庫服務器里。比如電商項目中用戶，商品，訂單就可以防在三台不同的服務器上。
【問題】
-
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%）
異地多活設計步驟
- 業務分級（挑選核心業務）
- 數據分類（數據量，唯一性，實時性，可恢復性）
- 數據同步（存儲系統同步，消息隊列同步等等）
- 異常處理（多通道同步，同步和訪問結合，日志記錄，用戶補償）
接口級故障應對方案
相對與概率小的機房火災，斷電等故障，接口故障發生的情況更多。
接口級故障：
- 內部：程序問題，計算機性能到達極限，導致數據庫慢查詢
- 外部：黑客攻擊，促銷搶購導致用戶訪問量突增，第三方響應緩慢等
降級
降級是着眼與整個系統的高可用，丟車保帥的一種行為。
比如論壇的系統接近負載，暫停發帖子功能，只能看帖子。
（如果系統持續負載，服務器崩潰，看帖子的功能也廢了）
熔斷：
是降級的一種情況。換句話說，熔斷會導致降級。
熔斷是指請求達到一個閾值，暫停該服務的調用，防止系統負載過大，導致崩潰。
限流
只讓一部分訪問通過。保證一部分響應優於全部不能響應。
- 基於請求限流（控制閾值）
- 基於資源限流（對關鍵資源限流，比如線程池最大並發量）