摘要
企業如何實現高容量大併發資料庫服務？公司業務高速發展，單例項資料庫到達瓶頸的情況下，如何做好分散式設計，提供高併發高效能的資料庫服務以支撐業務增長？
本次分享主要內容包括資料庫分散式架構設計思路，拆分原理，改造難點，解決方案等，讓資料庫不再成為業務發展瓶頸。
內容來源：2017年6月4日，袋鼠雲首席資料庫架構師巨集翊在“企業網際網路架構優化升級之路”進行《讓資料庫不再成為業務發展瓶頸——分散式資料庫架構設計》演講分享。IT 大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。
閱讀字數：1705 | 3分鐘閱讀
為什麼要做分散式？
高併發：分散式應用帶來更大量的資料庫請求。
高容量：業務增長，產生大量線上資料。
資源向上擴充套件存在天花板。
支撐業務高速發展，平滑擴容。
拆分原則：循序漸進
在業務初期，客戶量比較少，可以把所有服務和資料都存在一個例項上，都能支援業務的發展。
發展之後的客戶量、資料量和併發都上來了，這時資料庫很容易出現瓶頸。我們建議大家首先進行服務化的改造，將不同的業務模組做垂直梳理，把不同服務的資料庫相互隔離，中間的互動由業務上去實現。這樣資料庫就可以分佈在不同的例項上，能夠支援相對較高的併發和容量。
繼續發展的話，例項依然是一個瓶頸，這時我們就要考慮做水平的拆分。把一個服務的資料分佈到不同的例項上，以支援擴充套件、高併發、大容量的資料庫服務。
拆分需要循序漸進，然後做服務的梳理，最後再做水平拆分。
水平拆分會引入一些複雜性，研發方面需要考慮的東西就比較多，所以需要謹慎地做拆分。資料庫的拆分和業務架構緊密結合，有時在業務上的一個小改動完全可以把壓力擋在資料庫之外。
水平拆分的難點
水平拆分的一個服務資料會分佈到不同的底層資料庫上，所以會帶來一些複雜性。
系統架構需要適應資料庫的分散式，就需要做一些改造。面臨的技術挑戰就是應用需要處理複雜的分散式邏輯，比如分散式的事務、跨庫查詢。在穩定性方面也會有一些挑戰，但不是最主要的。主要是分散式的侷限性，分散式資料分佈在不同的資料庫上，它不支援跨庫的join、分散式事務、以及全域性sequence等。
解決方案：客戶端實現資料路由
在客戶端直接做一個配置，去實現路由的功能。它的好處就是不需要引入額外模組，整體架構不變；程式的把控力強，場景簡單方便使用；對程式碼的侵入性強；配置管理複雜。
此方案不會引入額外的組建，架構上比較輕量，簡單場景使用尚可，比如配置管理複雜等，不建議使用。
解決方案：資料庫中介軟體
實現自動分庫分表，對應用透明；使用門檻極低，應用改造量小；方便的動態水平擴容；針對分散式的各種定製功能，如異構索引、小表廣播等；最重要的是，有了資料庫中介軟體，應用看到還是單一的資料庫。
中介軟體的使用最大限度的遮蔽了分散式資料庫所引入的複雜性，極大降低了研發的門檻。
DRDS功能簡介
分庫分表是DRDS的核心功能，支援資料的多維度切分和路由訪問；內建讀寫分離功能，可以靈活配置訪問權重；自帶全域性唯一ID元件；查詢引擎識別和下推複雜查詢，相容98% MySQL語法；彈性擴容元件實現自動化線上水平擴容。
DRDS物理框架
資料拆分，能夠組合1K個MySQL；分散式SQL查詢引擎與高度的SQL相容性；資料儲存的平滑擴容；處理效能的彈性伸縮；讀寫分離（應用透明）；小表廣播、跨庫join、全域性sequence。
主庫和讀庫通過資料庫的原生複製實現，資料是強一致的。DRDS會自動判斷請求，然後做分發。事務性的操作全部路由到主庫上去，讀庫則承擔一些讀的操作。
把join從DRDS層往下推，在MySQL層實現它的join，業務設計上要避免跨庫join。
分散式SQL規範設計：最佳實踐
查詢儘可能帶上分庫條件。如果把一個表拆分到底層的十個庫，查詢的時候每次都帶上一個拆分條件，DRDS能夠很清楚地把請求路由到底層的庫上。
Join的時候有幾種解決方案。一種是兩個表的分庫鍵都相等去做join，這樣就能限定在一個庫上。還有一種是廣播表，join的欄位不一樣，但是每個表都帶上分庫的條件，這樣還是會限定在同一個庫裡面。
EasyDB：資料庫自動化管理平臺
資源：實時監控資料庫和伺服器空間的使用狀態。
高可用：雲上高可用架構設計，故障自動切換。
備份：定期的資料庫全量，增量備份，可靈活配置。
監控：異常情況下自動捕獲和告警，支援簡訊，郵件和微信通知。
效能：超過50個指標效能趨勢和SQL採集，實時監控資料庫的執行狀態。
日誌：資料庫錯誤日誌採集。
安全：資料庫賬號和操作的審計，基於伺服器的安全設計。
我今天的分享就到這裡，謝謝大家！