高性能
讀寫分離
將訪問壓力分散到集羣中的多個節點
解決複製延遲
- 寫操作侯的讀操作指定發給主庫
- 讀從庫失敗後再讀一次主庫
- 關鍵業務全部讀主庫
分配機制
- 程序側代碼封裝
- 中間件封裝
分庫分表
既分散訪問壓力，也分散存儲壓力
業務分庫
按業務模塊將數據分散到不同的數據庫服務器
問題
- 關聯查詢問題
- 事物問題
- 成本問題
緯度分表
- 垂直分表
- 大字段拆分
- 水平分表
- 行數特別大的表
問題
- 路由問題
- 確定數據在哪個子表
- 範圍路由
- Hash路由
- 關聯查詢
- 求和查詢
- 排序查詢
NoSQL
關係數據庫缺點
- 存儲的都是行記錄，無法存儲數據結構
- schema擴展不方便
- 全文搜索功能比較弱
NoSQL數據庫類型
- K-V存儲
- 文檔數據庫
- 列式數據庫
- 全文搜索引擎
緩存
設計要點
- 緩存穿透
- 數據不存在，緩存中沒有每次都要去數據庫查詢。解決辦法緩存默認值
- 緩存數據生成耗費大量時間，解決辦法提前緩存
- 緩存雪崩
- 緩存失效（過期）引起系統性能急劇下降，多個請求同時生成新的緩存
- 解決辦法
- 更新鎖，使用分佈式鎖，獲取鎖的則更新，其他請求等待鎖釋放後重新讀取緩存，或者返回空值、默認值
- 後臺更新，由後臺線程更新緩存，而不是業務線程，緩存設置永久有效
- 緩存熱點
- 熱點數據集中訪問一個緩存節點，解決辦法複製多份緩存副本
單服務器高性能
高性能架構設計
- 儘量提示單服務器性能，發揮到極致
- 單服務器無法支撐時設計集羣方案
架構設計決定了系統性能的上限，實現細節決定了系統性能的下限
併發模型設計點
- 服務器如何管理連接
- 服務器如何處理請求
PPC
Process Per Connection
每次有新的連接就新建一個進程專門處理，其中有可通過prefork提前創建進程
TPC
Thread Per Connection
使用線程處理每一個請求
連接數量、請求數量
- 海量連接，海量請求：搶購、雙十一
- 海量連接，常量請求：門戶網站
- 常量連接，海量請求：中間件
- 常量連接，常量請求：內部系統、管理系統
Reactor
I/O多路複用+線程池；非阻塞同步網絡模型，read、send需要用戶線程同步操作
- 當多條連接共用一個阻塞對象，進程只需在一個阻塞對象上等待
- 當某條連接有新的數據可以處理時，操作系統通知進程，進程從阻塞返回
實現方案
- 單Reactor單線程
- 單Reactor多線程
- 多Reactor多線程
Proactor
Reactor中同步I/O操作改爲異步實現
高性能負載均衡
任務分配器==負載均衡器
分類
- DNS負載均衡
- 同一域名返回不同的IP地址
- 硬件負載均衡
- 軟件10萬級併發、硬件100萬以上
- 軟件負載均衡
- Nginx
- 7層負載均衡，支持HTTP,E-mail協議
- LVS
- 4層負載均衡，和協議無關，幾乎所以應用都可以做
- Nginx
典型案例
- DNS負載機房IP
- 硬件負載本地集羣
- 軟件負載具體服務器
算法
分類
- 任務平分類
- 負載均衡類
- 性能最優類
- Hash類
具體算法
- 輪詢
- 加權輪詢
- 負載最低優先
- 性能最優類
- 源地址Hash
- ID Hash
CAP理論
- 一致性（Consistence）
- 可用性（Availability）
- 分區容錯性（Partition Tolerance）
- 根據系統內數據不同場景，選擇CP、AP
- 單個用戶餘額、單個商品庫存強一致的數據在技術上無法做到分佈式場景下的完美一致，只能單點寫入，其他節點做備份，無法做到分佈式場景下多點寫入，系統整體可以應用分佈式架構
- 既要考慮分區發生時選擇CP還是AP，也要考慮分區沒有發生時如何保證CA
- BASE理論是對CAP中AP的延伸補充
- 完美的CP場景是不存在的（幾毫秒延遲），CP實際也是實現最終一致性
分佈式系統設計初衷
- 橫向擴展
- 解決單點瓶頸問題，保證高併發下的可用性
- 高可用性
- 解決單點故障問題，保證部分節點故障時的可用性儘量降低系統複雜度
FMEA故障模式與影響分析
FMEA分析方法
- 給出初始的架構設計圖
- 假設架構中某個部件發生故障
- 分析此故障對系統功能造成的影響
- 根據分析結果，判斷架構是否需要進件優化
分析表格
- 功能點
- 故障模式
- 故障影響
- 嚴重程度
- 故障原因
- 故障概率
- 風險程度
- 已有措施
- 規避措施
- 解決措施
- 後續規劃