貝聊億級數據庫分庫分表實踐

文章做者:唐璜,貝聊資深JAVA工程師,曾長期就任於網易
方案實施:鄭曉濱,貝聊高級JAVA工程師,曾就任於網易

首先說明一下,這是貝聊2016年針對班級動態所實施的一個數據庫分庫分表方案,通過一年多的驗證,證實咱們的方案是可行的,所以分享給你們。
1、業務場景
班級動態是貝聊爲家長和老師提供的一個核心功能,相似於微信朋友圈、微博、QQ空間等的好友動態功能,是幼兒園家長老師使用頻率最高的功能之一。在貝聊,老師和家長均可以在班級裏發佈動態、評論動態、點贊動態,內容能夠包含文字、圖片或者視頻等內容。目前只要涉及到好友、粉絲之類的APP或者是網站基本都有這個功能,因此這個業務場景你們應該都很熟悉,就很少介紹了,附一張貝聊APP裏班級動態的截圖:
2、現狀(2016年)
貝聊從2013年成立,至2016年,使用貝聊的幼兒園已經達到幾萬所,班級動態業務涉及的數據也已經達到億級,且天天以幾十萬的速度在增加,預計三年左右就能達到數十億。與此同時,動態的回覆和點讚的數量更大,一般是動態量的幾倍到十幾倍的樣子。數據庫

而班級動態、評論與點贊三個表,當時跟幼兒園、班級等主業務數據表放在一塊兒,直接存儲在阿里雲RDS(MySQL數據庫)上,雖然有作主從,但未作分庫分表處理(這應該是創業公司初期的通病)。後端

3、存在問題
容量瓶頸: 單機數據庫隨着數據量和訪問量的增加必定會遇到服務瓶頸。
擴展困難: 單機數據庫擴展最終須要依賴硬件升級,擴展過程複雜、對業務影響大。
使用成本高: 單機數據庫爲得到更高的服務能力,依賴特定的高端設備,成本高昂。
可靠性低: 單機數據庫的數據集中存儲,宕機時直接影響全部數據庫數據的訪問。
4、目標
優化後,將來三到五年不須要進行大規模的優化。同時,在避免性能問題的基礎上,能支撐幾億甚至幾十億的動態。
5、實施方案
一、獨立班級動態數據庫
從主業務數據庫裏剝離班級動態相關數據表,獨立成庫。緣由很簡單,一是獨立出來方便作處理,二是任何一方有問題,都不會影響另外一業務的正常運行。
二、切分班級動態數據庫的數據
在要支撐幾億甚至幾十億的數據,同時有頻繁的插入和查詢的業務場景,不進行數據切分確定是行不通的。緩存

這裏說的數據切分是水平切分,水平切分主要目的是爲了突破單節點數據庫服務器的 I/O 能力限制,解決數據庫擴展性問題。水平切分時首先是經過一系列的切分規則將數據分佈到不一樣的DB或table中,再經過相應的DB路由或者table路由規則找到須要查詢的具體DB或者table,最後進行相關操做。服務器

如下看看咱們的班級動態、評論與點贊三個表:
因而可知,班級動態表、回覆表與點贊表都與幼兒園id相關。實際業務場景就是如此,用戶必須在其所在的幼兒園下發布動態,也只能查看、回覆與點贊所在幼兒園的動態。那麼選擇幼兒園id字段做爲分庫與分表的鍵,不管是拆分、插入、查詢都是沒問題的。微信

那麼,分多少個庫合適,分多少個表合適,根據什麼規則分,一旦單表數量再次達到性能瓶頸怎麼辦?針對這些問題,咱們通過了充分的調研討論,最後決定採用阿里雲 DRDS方案來實施。架構

DRDS(Distributed Relational Database Service,分佈式關係型數據庫服務 )是阿里巴巴自主研發,致力於解決單機數據庫瓶頸而推出的分佈式數據庫中間件產品。運維

先看看阿里雲官網關於DRDS的產品介紹(這塊好像DRDS的軟文,阿里雲是否是該付咱們廣告費呢): DRDS 高度兼容 MySQL 協議和語法,支持水平拆分、平滑擴容、彈性擴展、透明讀寫分離和分佈式事務等特性,具有分佈式數據庫全生命週期的運維管控能力。
DRDS 支持庫級拆分、表級拆分和分庫分表拆分。拆分鍵暫時只支持單個字段。
分庫鍵:DRDS 根據分庫鍵的值將數據水平拆分到後端的每個 RDS 分庫裏。鍵值相同的數據,必定會位於同一個 RDS 數據庫裏。
分表鍵:每一張邏輯表均可以定義本身的分表鍵,鍵值相同的數據,必定會位於同一個 RDS 數據表裏。
因爲咱們在使用阿里雲的RDS,同時咱們只須要根據單個字段(幼兒園id)拆分,因此咱們用阿里雲 DRDS做爲分庫分表方案徹底沒毛病,對吧?切分方案肯定後,丟給阿里搞,少死好多腦細胞,馬雲也一邊偷着樂去了。分佈式

根據阿里雲DRDS的官方建議:將來2年預估班級動態數據總量 = DRDS建議單表容量 X 分表數量 X 分庫數量
三、獨立動態業務
重構現有的班級動態模塊,並將其獨立成一個Dubbo服務組件。代碼重構的目標主要有如下幾點:
1)保證大部分的SQL語句可以使用分庫分表鍵,避免全表掃描
2)避免使用JOIN語句,使用單表查詢替代
3)靈活使用緩存策略減小DB壓力
6、效果比較
一、 性能大幅度提高
響應速度提高5至10倍,以當時獲取班級動態列表接口爲例:
分庫分表實施前:響應時間大體爲200ms至1500ms級之間。
分庫分表實施後:響應時間提高至大體爲30ms至300ms之間。
二、 可方便快速進行橫向擴容
若是須要擴容,直接按照阿里雲DRDS指引,增長新的分庫便可。
三、 架構的優化
獨立動態業務,經過Dubbo提供服務,對系統進行解耦,讓業務具有快速橫向擴容能力。
四、後遺症
獨立後,暫時沒有作分佈式事務,在業務中須要避免跨庫事務。性能

相關文章
相關標籤/搜索