讓數據庫再也不成爲業務發展瓶頸——分佈式數據庫架構設計

摘要

企業如何實現高容量大併發數據庫服務？公司業務高速發展，單實例數據庫到達瓶頸的狀況下，如何作好分佈式設計，提供高併發高性能的數據庫服務以支撐業務增加？

本次分享主要內容包括數據庫分佈式架構設計思路，拆分原理，改造難點，解決方案等，讓數據庫再也不成爲業務發展瓶頸。

內容來源：2017年6月4日，袋鼠雲首席數據庫架構師宏翊在「企業互聯網架構優化升級之路」進行《讓數據庫再也不成爲業務發展瓶頸——分佈式數據庫架構設計》演講分享。IT 大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：1705 | 3分鐘閱讀

嘉賓演講視頻回放： t.cn/RQCVFyS

爲何要作分佈式？

高併發：分佈式應用帶來更大量的數據庫請求。

高容量：業務增加，產生大量在線數據。

資源向上擴展存在天花板。

支撐業務高速發展，平滑擴容。

拆分原則：按部就班

在業務初期，客戶量比較少，能夠把全部服務和數據都存在一個實例上，都能支持業務的發展。

發展以後的客戶量、數據量和併發都上來了，這時數據庫很容易出現瓶頸。咱們建議你們首先進行服務化的改造，將不一樣的業務模塊作垂直梳理，把不一樣服務的數據庫相互隔離，中間的交互由業務上去實現。這樣數據庫就能夠分佈在不一樣的實例上，可以支持相對較高的併發和容量。

繼續發展的話，實例依然是一個瓶頸，這時咱們就要考慮作水平的拆分。把一個服務的數據分佈到不一樣的實例上，以支持擴展、高併發、大容量的數據庫服務。

拆分須要按部就班，而後作服務的梳理，最後再作水平拆分。

水平拆分會引入一些複雜性，研發方面須要考慮的東西就比較多，因此須要謹慎地作拆分。數據庫的拆分和業務架構緊密結合，有時在業務上的一個小改動徹底能夠把壓力擋在數據庫以外。

水平拆分的難點

水平拆分的一個服務數據會分佈到不一樣的底層數據庫上，因此會帶來一些複雜性。

系統架構須要適應數據庫的分佈式，就須要作一些改造。面臨的技術挑戰就是應用須要處理複雜的分佈式邏輯，好比分佈式的事務、跨庫查詢。在穩定性方面也會有一些挑戰，但不是最主要的。主要是分佈式的侷限性，分佈式數據分佈在不一樣的數據庫上，它不支持跨庫的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採集，實時監控數據庫的運行狀態。

日誌：數據庫錯誤日誌採集。

安全：數據庫帳號和操做的審計，基於服務器的安全設計。

我今天的分享就到這裏，謝謝你們！