MySQL 高擴展架構構建百萬在線系統實踐

內容來源：2017 年 10 月24 日，知數堂 MySQL技術專家吳炳錫在「2017 MySQL技術交流大會---上海站」進行《MySQL高擴展架構設計》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2571 | 7分鐘閱讀

嘉賓演講視頻及PPT回顧：suo.im/4rykSK

摘要

隨着傳統企業去IOE的聲音愈來愈大，也有不少朋友來諮詢MySQL的架構設計問題，本次分享討論如何利用MySQL構建一個高擴展的架構，從而在MySQL上構建出來基於百萬在線的系統。

MySQL 在高併發結構中的挑戰

挑戰

數據量大是現階段很是明顯的挑戰，咱們最近接觸的案例中有不少數據量輕易就達到了8個多T，數據的備份都變得很麻煩。如今已經到了一個海量數據的年代。

之前的互聯網行業可能對一致性的要求並不會過高，可是像銀行這樣的傳統金融行業，單單轉帳操做的流程就有280多個，而如今之因此能如此迅速的完成轉帳操做，強一致性在其中發揮了重要的做用。

相似微信、支付寶的掃碼功能都和數據庫有聯繫，要是這些功能出現問題想必你們都會很惱火，這其中涉及到了數據庫的可用性問題。

最後還有一個服務範圍廣的問題，好比如何處理認證中心的一點註冊多地登陸狀況。

優勢

MySQL的高併發、靈活的特性是其餘數據庫沒法比擬的。多IDC架構使得MySQL可以分佈到多個機房，架構處理很是簡單。另外MySQL是Sharp nothing的，每一個節點都有一份數據，損壞率被極大的減少。

MySQL自己的特色

- 無執行計劃緩存，cpu佔用較高

- Query單核運算，不適合運行較大較複雜的SQL

- 在MySQL5.7之前對於鏈接數據敏感（建議控制在300個如下）

- 基於存儲引擎的解決方案（Innodb，TokuDB，MyRocks，Spider）

- 不支持事務嵌套，不支持hash join

即便面臨如此多的挑戰，國內成功的案列卻很是多。好比微信財付通、物流、P2P信貸、遊戲行業、互聯網行業。

成功的經驗總結

容量規劃

容量規劃這塊特別須要注意資源分配對齊，不少公司的數據庫規模良莠不齊，大的有十幾個T，小的可能只有幾十兆。

這樣整個資源的管理會很是混亂，要想進行大規模的管理就須要把DB做爲一個存儲資源，制定分配標準。好比單實例在PCIE上運行，實例大小1T左右，單庫大小200G左右 ，超過200G就進行拆分。

另外咱們提倡單機多實例。這樣的好處在於可控，方便遷移，內部作成DB資源管理平臺易下手。反之單機單實例，存儲4T以上，備份管理很是難受。

分庫分表

在項目逐漸增大後，你們都將面臨如何分拆數據的問題。個人建議是分拆冒尖的數據，好比項目中的用戶好友關係數據若是很是大，那麼就分拆它，還有一些不規範的好比日誌類的數據也能夠分拆。這樣一步步的分拆，就能更早的規劃資源耗費嚴重的數據。

咱們提倡的拆分原則是先按功能進行拆分，好比分爲認證類型、用戶核心類型、用戶基本資料等。按功能拆分完在單庫大於200G後再考慮水平拆分，這裏通常採用兩種算法：Range和Hash。當單實例達到1T左右時，考慮分Set，好比1-2000萬是Set1,2000萬-4000萬是Set2，經過Set治理，也能夠方便的解決數據在多IDC分佈的問題。

分佈式事務

分佈式事務是常見的複雜類型事務，一個比較常見的場景就是十幾個接口的調用都在同個DB上，如何拆分事務成了一個問題。在分佈式事務中，能夠想象出這樣的場景，在一個高速通道中將併發的數量限制在所支持數量內，而且每一個用戶只能操做自身所處環境的數據。這種方式就是利用消息隊列解耦。另外爲了防止用戶在沒有完成當前事務的狀況下又開始新的事務，則須要引入狀態機的概念。

DB調用

複雜項目的DB調用面臨的最無語的問題，莫過於一個DB被N多的服務調用，最後沒法分辨哪一個IP對應哪一個服務，當DB須要進行遷移時，不知道具體須要通知誰。

爲了解決問題，就須要應用虛擬DB功能，單DB只對本身的服務開放權限，拒絕其餘服務直接訪問其餘功能DB，而且服務之間只走服務調用而不與DB發生聯繫。

另外在不知道自身併發極限的狀況下，應該採用流式調用，把併發控制在必定範圍以內，引入過載保護。

長服務鏈調用有時會碰到開發人員連數據庫Timeout的狀況，這極有多是由於，開發從鏈接池獲取到鏈接，處理完成後纔將鏈接放回鏈接池。而正確的作法是拿到鏈接獲取到結果，就把鏈接放到鏈接池，再去處理結果。爲了不這種狀況，應當就長服務鏈調用的問題及時與開發溝通好。

可用性

可用性這塊首先要談的就是高可用，這方面最先使用的是MHA，到了如今基本上每一個公司都會維護一份本身的MHA代碼，而不去直接使用官方的。另外一種方式是自主實現，基於MHA的思想，本身經過Python之類的語言實現。

再往上的服務架構上的支持，要考慮DB在故障切換中程序會不會異常，DB切換後故障，有沒有備選方案。

以咱們的經驗來看可用性要考慮幾方面的措施，包括自動化的安全閾值控制、高可用切換過程當中產生的DB不可用處理、多寫的機制中數據一致性是否是方便校檢以及後期數據補償方案。

多IDC結構

多機房部署是各大公司都在探索的一個領域，它有着不少特性。好比單節點寫入，其它IDC就近讀取。多點寫入，總線彙總。另外多機房代碼發佈須要訪問每一個機房自身的數據庫，通常這種狀況咱們都會引入SmartDNS。

Cache 選擇

Cache的選擇實際上是比較多的，通常項目開始階段能夠不考慮Cache只緩存調用最多的。咱們在下文列出了一些Cache分類。

易失性 Cache

- Memcache

- Redis

非易失性 Cache

- Redis

- MongoDB

- MySQL NDB Cluster

比較推薦的是Redis – Cluster以及MongoDB Cluster。易失性這方面則能夠選擇Redis，可是必定要考慮Redis掛了後，數據庫可以扛的住，通常的解決方案是在發現數據庫響應較慢的時候，鏈接層自動降級。