MySQL資料庫TDSQL架構分析及採用策略擴容流程
阿新 • • 發佈：2019-01-24
系統由三個模組組成：Scheduler、Agent、閘道器，三個模組的互動都是通過ZooKeeper完成，極大簡化了各個節點之間的通訊機制，相對於第二代HOLD的開發簡單了很多。
Scheduler作為叢集的管理排程中心，主要功能包括：
1.管理set，提供建立、刪除set、set內節點替換等工作；
2.所有的DDL操作統一下發和排程；
3.監控set內各個節點的存活狀態，當set內主節點故障，發起高一致性主備切換流程；
4.監控各個set的CPU、磁碟容量、各個表的資源消耗情況，必要的時候自動發起擴容流程；
5.Scheduler自身的容災通過ZooKeqzer的選舉機制完成，保證中心控制節點無單點。
Agent模組負責監控本機MySQL例項的執行情況，主要功能包括：
1.用短連線的方式週期性訪問本機的MySQL例項，檢測是否可讀、可寫，若發生異常，會將異常資訊上報到ZooKeeper，最終會由上面描述的Scheduler模組檢測到這個異常情況，從而發起容災切換；
2.檢測主備複製的執行情況，會定期上報主備複製的延時和延遲的事務數，若發生了主備切換，自動向新主機重建主備，因此MySQL的主備不需要DBA干預，對於新增的例項會3.自動採用xtrabackup通過主機自動重建資料；
4.檢測MySQL例項的CPU利用率和各個表的請求量、資料量、CPU利用率，上報到ZooKeeper，ZooKeeper通過全域性的資源情況抉擇如何擴容、縮容；
5.監控是否有下發到自身的擴容任務，如有則會執行擴容流程（下面會有描述）；
監控是否要發生容災切換，並按計劃執行主備切換流程。
閘道器基於MySQL Proxy開發，在網路層、連線管理、SQL解析、路由等方面做了大量優化，主要特點和功能如下：
1.解析SQL，將識別出的DDL語句直接存到ZooKeeper，讓Keeper來統一排程；
2.Watch ZooKeeper的路由資訊，拉取最新的路由表儲存到本地檔案和記憶體；
3.將SQL請求路由到對應的set，支援讀寫分離；
4.對接入的IP、使用者名稱、密碼進行鑑權；
5.記錄完整的SQL執行資訊，與秒級監控平臺對接完成實時的SQL請求的時耗，成功率等指標監控分析；
6.對count、distinct、sum、avg、max、min、order by、group by等聚合類SQL一般需要訪問後端的多個set，閘道器會分析結果並做合併再返回，暫不支援跨set join和分散式事務；
7.閘道器無狀態，既支援與業務部署到一起，也可以獨立部署（可通過TGW或者LVS做容災）。
自動擴容機制
目前，針對MySQL的擴容，一般有下面兩種策略。
1.垂直擴容。一般通過升級硬體來實現，比如更換更好的CPU，將傳統的sas盤換成FusionIO卡這類，然後針對新硬體調整好引數，在硬體結構變化比較大的時候，效能甚至能達到上十倍的提升。但垂直擴容有比較大的侷限，就是這種模式隨著業務的突增還是比較容易達到瓶頸，特別是面對網際網路海量使用者的時候，所以在網際網路應用場景下，一般僅將垂直擴容當做一個輔助的手段。
2.水平擴容。常用的有2種方法，一是不同的庫或者表部署到不同的例項，二是一張表需要根據某個欄位拆分到不同的字表中（資料分片），這種策略在網際網路系統中非常常見，很多系統會將這2種水平擴容的方法結合起來使用；
通過上述2種擴容方法的比較，為了應對海量擴充套件的需求，應該是重點選用水平擴容的方法。但水平擴容的實現一般對業務是有感知的，比如採用什麼規則來拆表，拆開的表放到哪些節點，如果某個子表還有瓶頸應該怎麼擴容，擴容是否還需要業務配合等等這些事情如果全部交給業務會比較繁瑣，因此這些需求應該儘量全部交給TDSQL自身來完成，對業務完全透明。
分表邏輯
在TDSQL中，每個表（邏輯表）可能會拆分成多個子表（建表的時候通過在建表語句中嵌入註釋的方式提供一個shard欄位名，最多會拆分出1W個子表），每個子表在MySQL上都是一個真實的物理表，這裡稱為一個shard，因此一張表的資料可能會按這樣的方式分佈在多個Set中，如圖2所示