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

文章做者：唐璜，貝聊資深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提供服務，對系統進行解耦，讓業務具有快速橫向擴容能力。
四、後遺症
獨立後，暫時沒有作分佈式事務，在業務中須要避免跨庫事務。