內容來源：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掛了後，資料庫能夠扛的住，一般的解決方案是在發現資料庫響應較慢的時候，連線層自動降級。