閱讀832 返回首頁    go 阿裏雲 go 技術社區[雲棲]


如何實現高容量大並發數據庫服務 | 數據庫分布式架構設計

袋鼠學院和優雲、阿裏雲聯合舉辦的沙龍結束之後,總是有小夥伴們來問PPT內容,想要進一步了解Topic內容。(哦,對了對了,竟然還有小夥伴專門衝著袋鼠雲去聽沙龍,感動cry~~)


千唿萬喚,忙成狗的袋鼠小妹終於把沙龍總結整理了出來(⊙o⊙)


本次沙龍的主題是“雲時代下的運維管理實踐”,受邀請的演講嘉賓,花名宏翊(經常關注袋鼠雲的同學,肯定已經對這個名字很熟悉了),是袋鼠雲首席數據庫架構師,袋鼠學院數據庫講師。


唿應沙龍運維實踐的主題,結合自己的專長領域,宏翊主要是從數據庫領域來談雲時代下的運維管理該如何做,主題為“如何實現高容量大並發數據庫服務?之數據庫分布式架構設計”。


640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=


為什麼數據庫需要做分布式架構設計?在對數據庫進行拆分設計和實施時,會遇到哪些坑?又該如何避免踩坑?


袋鼠小妹結合宏翊的PPT和現場演講,整理內容如下,希望和大家一起分享、探討。


  摘要


數據庫拆分要根據業務現狀、模式,選擇合適的拆分方式,緊密結合業務及應用架構設計,謹慎拆分,防止過度設計。


  正文


  為什麼要做分布式數據庫架構改造?


雲計算大數據時代,傳統的數據庫架構已經無法支撐企業高容量的數據增長,滿足高並發的業務需求。對企業數據庫進行分布式架構設計,打破了數據庫資源不夠用的天花板的同時,還能根據企業業務發展狀況,隨時平滑擴容。


  分布式數據庫架構改造,如何做?


數據庫分布式改造要遵循“循序漸進”的拆分原則


拆分方式有垂直拆分和水平拆分兩種,選擇拆分方式要根據企業自身業務發展需要。


640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=


一般來說,是先做垂直拆分,再做水平拆分。


在單一數據節點無法滿足業務和用戶增長需求的情況下,需要做一個服務化,對業務進行垂直梳理,後麵的數據節點可以放在不同的資源節點上,以提高數據服務的整體性能。


比如一個APP的業務數據,在業務初期階段,是全部放在一個數據庫節點中,在業務量和數據量快速增長的中期階段,需要進行垂直梳理,根據業務邏輯,拆分成商品、交易、用戶,並分別放在不同的數據庫。


如果其中的一個服務已經拆的很細了,但還是有性能瓶頸,無法支撐我們的業務增長,數據庫這塊才需要再做水平拆分。


水平拆分就是將數據(比如圖中APP的交易數據)拆成多片,放到不同的資源上,用一個集群來支撐更高的業務增長。


在拆分時,要謹慎,因為拆分會引入複雜性,能不做就不做,最優先是做業務和架構上的優化,最終才是做數據庫拆分。


在拆分的過程中,不要做過度的設計,或者直接從初級跳到高級,這樣做其實非常浪費資源,投入產出比也不好。


 水平拆分的難點及解決方案


對企業數據庫進行分布式改造,需要理解客戶的業務邏輯、豐富的拆分經驗積累。尤其是水平拆分,有係統複雜度高、技術挑戰性強、穩定性控製難、具有一定局限性四大難點。


針對這些問題,宏翊給我們提供了兩種解決方案。


  1. 客戶端實現數據路由

    此方案不會引入額外的組件,架構上比較輕量,簡單場景使用尚可,但稍複雜的場景會放大它的劣勢,比如配置管理複雜等。


    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=

  2. 數據庫中間件

    中間件的使用最大限度地屏蔽了分布式數據庫所引入的複雜性,極大降低了研發的門檻。最重要的是,有了數據庫中間件,應用看到的還是單一的數據庫。

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=


  水平切分原理及設計原則


要對一個表做拆分,選擇一個拆分字段,通過一個路由算法確定數據存放在哪個底層庫。

比如下列數據選擇MEMBE_ID作為拆分鍵,通過路由算法計算後得出’test1234‘相關的數據應該落在庫1上,DRDS會把所有MEMBE_ID=‘test1234’相關的請求全都路由到庫1。其他數據請求亦落到相應的底層庫。

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=


接下來,當數據已經放下去了,應該如何去查詢、訪問和變更?


比如要查詢一條記錄,member_id=‘test1234


它怎麼去執行的呢?


首先計算一個hash值,當值等於某一個值,它會知道這個數據存儲在哪一個庫上,所以會直接路由到底層這個庫,從這個庫查詢,返回結果。


中間件扮演的就是這個路由和計算的角色,性能非常強大。拆分後,各底層數據庫數據量比較小,查詢返回比較快;二是可以支持更高的並發,整體並發基本等於兩個底層數據庫實例並發之和。

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=


  來自阿裏雲的數據庫中間件產品:DRDS


數據庫中間件產品中,有平民軟件OneProxy等商業軟件;也有MyCat等開源產品,宏翊為大家則介紹了一款廣泛使用的成熟商業產品DRDS,並講解了DRDS如何解決對數據庫進行拆分時遇到的難點。


DRDS,英文名Distributed Relational Database Service


是阿裏巴巴自主研發致力於解決單機數據庫服務瓶頸問題而推出的分布式數據庫產品。 DRDS 高度兼容 MySQL 協議和語法、支持自動化水平拆分、平滑擴容、彈性擴展、透明讀寫分離、分布式事務、具備分布式數據庫全生命周期的運維管控能力。DRDS前身為淘寶TDDL,是近千核心應用首選組件,已穩定服務8年以上。


DRDS五大核心功能


  • 分庫分表

分庫分表是DRDS的核心功能,DRDS 在後端將數據量較大的數據表水平拆分到後端的每個 RDS 數據庫中,這些拆分到 RDS 中的數據庫被稱為分庫,分庫中的表稱為分表。拆分後,每個分庫負責每一份數據的讀寫操作,從而有效的分散了整體訪問壓力。在係統擴容時,隻需要水平增加分庫的數量,並且遷移相關數據,就可以提高 DRDS 係統的總體容量。DRDS 支持庫級拆分,表級拆分和分庫分表拆分,通過 DRDS DDL 語句指定。


  • 讀寫分離

在主實例的讀請求較多、讀壓力比較大的時候,可以通過 DRDS 讀寫分離功能對讀流量進行分流,減輕 RDS 主實例的讀壓力。

DRDS 的讀寫分離功能是對應用透明的設計。應用在不修改任何代碼的情況下,隻需要在 DRDS 控製台中調整讀權重,即可將讀流量按配置的比例在主 RDS 實例與多個 RDS 隻讀實例之間進行分流;寫流量則全部到主實例,不做分流。

設置讀寫分離後,從主 RDS 實例讀取的是強讀,既實時強一致讀,而隻讀實例上的數據是從主實例上異步複製的,存在毫秒級的延遲,因此從隻讀 RDS 實例讀取的是弱讀,屬於非強一致性讀。個別需要實時性、強一致性讀的 SQL 可以通過 DRDS Hint 指定到主實例上執行。


  • 全局唯一ID

DRDS 支持分布式全局唯一且有序遞增的數字序列。滿足業務在使用分布式數據庫下對主鍵或者唯一鍵以及特定場景的需求。


  • 小表廣播

DRDS 將一些數據量小且更新頻度不高的數據表存儲為單表模式,這些數據表稱為小表。通過數據同步將小表複製到與之 JOIN 的分庫上進而提升 JOIN 效率的解決方案稱為“小表廣播”或者“小表複製”。支持查詢引擎識別和下推複雜查詢,兼容 98% MySQL 語法。


  • 彈性擴容

當邏輯庫對應的底層存儲已經達到物理瓶頸,需要進行水平擴展,比如磁盤餘量接近30%,那麼可以通過平滑擴容來改善。平滑擴容是一種水平擴容方式,既把分庫平滑遷移到新添加的底層存儲上。在實現上是通過增加 RDS 實例的數量來提升總體數據存儲容量,將分庫遷移到新增的 RDS 實例,從而降低單個 RDS 實例的處理壓力。


  分布式改造之後——運維


進行分布式改造之後,如何更省心省力對數據庫進行運維?

靠人工?成本高、運維人員也難招!


借助袋鼠雲開發的數據庫自動化管理平台EasyDB,企業數據庫運維很簡單。


640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=


EasyDB完全兼容DRDS manager,具有高可用、高性能、易運維等特點。從性能、資源、集群、備份、容災入手,支持多種數據庫實例,大規模量的數據庫運維,提供穩定準確的數據庫告警、大盤趨勢分析預警、空間跟蹤、SQL跟蹤、巡檢報告等功能。運維管理人員可以輕鬆應對複雜的日常管理事務及突發性事件,數據庫管理從此變得有規劃,有效率,有預見性。

最後更新:2017-06-15 11:31:44

  上一篇:go  業界首個非侵入式熱修複方案Sophix重磅推出,顛覆移動端傳統更新流程!
  下一篇:go  84小時,230台服務器,袋鼠雲和客戶一起全力阻擊WannaCrypt蠕蟲病毒