掌握高併發、高可用架構
第三章 分佈式
本章介紹分佈式架構的底層技術。主要說明面試過程中可能被問到的技術點。
第六節 分佈式數據庫MyCat
分庫分表 Sharding
1. 分庫分表的方法
垂直切分，也就是因爲表多而數據多，將關係緊密（比如統一模塊）的表切分出來放到一個服務器中
水平切分，表不多，而是表中數據量龐大，也就是把表的數據按照某種規則切分到多個服務器中
現實中多是這兩種的混合
2. 分庫分表需要解決的問題
-
事務問題
解決方案一：使用分佈式事務；優點是，由數據庫管理，簡單有效；缺點是，性能代價高
解決方案二：將分佈式事務拆分成單個數據庫的小事務，通過程序來總控各個小事務；優點，性能好一些；缺點，代碼耦合高
-
跨節點join的問題
只要是進行切分，跨節點Join問題不可避免。但良好的設計和切分可以減少此類情況的發生
普遍的解決方案是分兩次查詢，第一次查詢找出關聯數據的ID，然後根據這些ID發起第二次的查詢
-
跨節點的count、order by、group by以及聚合函數問題
這是一類問題，因爲它們都需要基於全部數據進行計算，而多數的代理都不會自動處理合並工作
解決方案與跨節點Join一樣，分別在各個節點得到結果後在應用程序進行合併，不同的是每個節點的查詢可以並行執行
-
數據遷移、容量規劃、擴容的問題
-
ID問題
一旦數據庫被切分到多個物理節點上，我們將不能再依賴數據庫自身的主鍵生成機制。一方面，某個分區數據庫自生成的ID無法保證全局唯一性；另一方面，應用程序在插入數據之前要先獲取到ID，以便對SQL進行路由
以下是常見的主鍵生成策略
UUID，簡單，但是數據過長，佔空間，而且建索引和基於索引進行查詢都有性能問題
基於數據庫維護一個Sequence表，表的壓力會很大，而且有單點問題，一旦發生故障，整個應用程序將無法使用
Twitter的分佈式自增ID算法Snowflake
-
跨節點的排序分頁
一般來說，分頁時需要按照指定字段進行排序。當排序字段就是分片字段時，我們根據分片規則可以比較容易定位到指定的分片，當排序字段不是分片字段時，情況就比較複雜了。爲了最終結果的準確性，我們需要在不同的分片節點中將數據進行排序並返回，並將不同分片的結果集進行彙總和再次排序，最後再返回給用戶
![img]()
如果只是取第一頁的數據，看起來對性能的影響並不大。但是，如果取第10頁的數據，情況將複雜的多。
![img]()
因爲各分片節點的數據都是隨機的，爲了排序的準確性，必須把所有分片節點的前N頁數據都排序好後做合併，最後再進行整體的排序。特別的消耗資源，分頁頁碼越大，性能越差。
解決方案如下：
在前端做分頁，並且限定只能看前n的數據
如果是後臺程序要獲取分頁數據，可以加大page size，比如獲取5000條記錄，有效減少分頁數
分庫設計時，配套大數據平臺彙總所有分庫的記錄，有些分頁查詢可以走大數據平臺
-
分庫數量
分庫數量和彈庫能處理的記錄數有關，一般來說，MySql單庫超過5000萬條記錄，Oracle單庫超過1億條記錄，DB壓力就很大。一般建議初次分庫數量爲4-8個庫
3. 分佈式事務
-
XA規範
主要定義了（全局）事務管理器（Transaction Manager）和（局部）資源管理器（Resource Manager）之間的接口。XA接口是雙向的系統接口，在事務管理器和一個或多個資源管理器之間形成通信橋樑
事務管理器控制着全局事務，管理事務生命週期，並協調資源
資源管理器負責控制和管理實際資源
-
JTA（Java Transaction API）
Java平臺上的事務規範，它僅定義了接口，具體實現則由具體的提供商來實現
-
兩階段提交
![img]()
第一階段，準備階段：事務協調者（事務管理器）給每個參與者（資源管理器）發送Prepare消息，每個參與者要麼直接返回失敗，要麼在本地執行事務，寫本地的redo和undo日誌，但不提交
第二階段，提交階段：如果協調者收到了參與者的失敗消息或者超時，直接給每個參與者發送回滾（Rollback）消息，否則，發送Commit消息；參與者根據協調者的指令執行回滾或提交操作，並釋放所有事務處理過程中的鎖資源
優點：效率高
缺點：當事務的併發量達到一定數量時，會出現大量的事務積壓甚至出現死鎖，系統性能會嚴重下降
-
一階段提交（Best Efforts 1PC模式）
就是從應用程序向數據庫發出請求到數據庫完成提交或回滾之後將結果返回給應用程序的過程，非常直白
-
事務補償機制
像Best Efforts 1PC模式，前提是應用程序能獲取所有的數據源，然後使用同一個事務管理器（指Spring的事務管理器）管理事務，最典型的應用場景是數據庫sharding
對於那些基於WebService、RPC、JMS等高度自治的分佈式系統接口，Best Efforts 1PC無能爲力，可以通過事務補償機制來實現最終一致性
