前 言

各位讀者朋友，大家好，這是分庫分表實戰(zhàn)的第一篇文章，首先介紹一下 ”基于ShardingSphere的分庫分表實戰(zhàn)“ 的設(shè)計思路及內(nèi)容。

本實戰(zhàn)的重點(diǎn)是分庫分表實戰(zhàn)，比較適合1～3年工作經(jīng)驗的程序員朋友。 實戰(zhàn)主要以外賣APP中的外賣訂單來作為本次實戰(zhàn)的核心業(yè)務(wù)。

基于外賣訂單業(yè)務(wù)，儒猿技術(shù)團(tuán)隊開發(fā)了一個外賣訂單項目，通過該項目逐步分析隨著訂單數(shù)據(jù)量逐步增加，系統(tǒng)將遇到什么問題。

并以這些問題為線索逐步分析，在分庫分表之前，有沒有一些方案可以初步解決這些問題，隨著訂單數(shù)據(jù)量的增加，為什么這些方案會失效，最后導(dǎo)致不得不分庫分表。

而分庫分表方案具體該如何設(shè)計？ 方案設(shè)計完成之后又該如何落地？分庫分表方案引入之后又會帶來什么新的問題？這些問題都可以在本實戰(zhàn)中找到答案。

認(rèn)識一下單庫版本的訂單系統(tǒng)

開始時，訂單系統(tǒng)是用單庫跑的，隨著數(shù)據(jù)量的不斷增大，系統(tǒng)將會采取各種措施逐步優(yōu)化，比如索引和sql的優(yōu)化、加緩存、上讀寫分離、垂直分庫等方案，最后實在抗不住了才會進(jìn)行分庫分表。

從單庫版本到分庫分表版本的整個優(yōu)化過程的基礎(chǔ)是一個單庫版本的外賣訂單系統(tǒng)。

儒猿技術(shù)團(tuán)隊已提前使用Spring+SpringMVC+MyBatis開發(fā)實現(xiàn)了外賣訂單系統(tǒng)，該單庫版本的訂單系統(tǒng)，整體架構(gòu)圖如下所示：

上圖是單庫版本訂單系統(tǒng)的邏輯架構(gòu)圖和技術(shù)架構(gòu)圖的一個對比。該訂單系統(tǒng)共分三層，分別是訪問層、服務(wù)層和數(shù)據(jù)層。

1. 訪問層： 是調(diào)用后臺服務(wù)的入口，這里直接使用postman來調(diào)用，因為重點(diǎn)是分庫分表的方案落地，偏后端，所以直接使用postman來作為請求入口，非常的方便。

2. 服務(wù)層： 是整個訂單系統(tǒng)的核心，它提供了外賣訂單系統(tǒng)的核心功能，比如用戶下單、用戶查詢訂單列表、商家接單等核心功能；而為了實現(xiàn)這些功能，使用了一些技術(shù)，比如使用Tomcat作為服務(wù)器來對外提供服務(wù)、使用Spring Web MVC作為web的開發(fā)框架、使用Spring IOC來管理bean、使用MyBatis來操作數(shù)據(jù)庫、使用logback來記錄日志。

3. 數(shù)據(jù)層： 主要是用來存儲外賣訂單數(shù)據(jù)，這里使用的數(shù)據(jù)庫是MySQL。

業(yè)務(wù)快速增長，驅(qū)動系統(tǒng)架構(gòu)不斷演進(jìn)

這里設(shè)定一個背景，該外賣訂單系統(tǒng)是位于一家初創(chuàng)型互聯(lián)網(wǎng)公司的，目前積累的用戶差不多10萬的樣子，每天活躍的用戶大概就2萬，每天相應(yīng)的訂單量也是2萬的樣子。

簡單估算一下，一年的訂單數(shù)據(jù)量也就七八百萬的樣子，單個數(shù)據(jù)庫還是非常輕松抗住的。

索引和sql優(yōu)化

但創(chuàng)業(yè)型公司的發(fā)展是比較迅猛的，如果踩對風(fēng)口的話，用戶會呈現(xiàn)爆發(fā)式的增長，這個時候外賣APP的用戶量可能會迅速增長到了100萬，日活用戶20萬，日訂單20萬，訂單單表也從之前的幾百萬快速達(dá)到了2000萬的級別，如下圖：

令人擔(dān)憂的是，隨著時間的推移，訂單單表的數(shù)據(jù)會繼續(xù)快速增長，此時sql查詢的性能開始慢慢下降，這時就要著手優(yōu)化sql了。

此時先從索引和sql著手優(yōu)化，展示sql優(yōu)化的一般流程，這里將會有2個case，

• 隱式轉(zhuǎn)換導(dǎo)致索引失效。
• 一個是關(guān)于join連接查詢的?。

引入緩存方案

優(yōu)化案例 ——高峰期大量請求打到MySQL，導(dǎo)致數(shù)據(jù)庫資源占用率很高，從而降低了MySQL的查詢性能，最終導(dǎo)致訂單sql查詢突增到2s。

為了解決這個問題，引入緩存，如下圖：

?

說白了，就是使用緩存來承接大多數(shù)的查詢請求，這樣到達(dá)數(shù)據(jù)庫的請求就非常少了，數(shù)據(jù)庫的資源占用率就會穩(wěn)定在一個正常范圍，從而使得訂單sql的查詢效率，不至于受到很大影響。

引入讀寫分離方案

優(yōu)化案例 —— 由于促銷活動的原因，大量下單的用戶會不斷刷新頁面來查詢訂單信息，比如看一下訂單是否開始配送，此時就會導(dǎo)致大量的請求打到MySQL上去。

此時單庫又抗不了這么讀請求，就導(dǎo)致了數(shù)據(jù)庫負(fù)載很高，從而嚴(yán)重降低了訂單sql的查詢效率，最終導(dǎo)致在促銷活動期間，訂單sql的查詢時間突增到2.5s。

促銷活動期間對訂單的操作，是典型的讀多寫少場景，為了解決這個問題，引入了讀寫分離的方案，如下圖：

?

也就是寫數(shù)據(jù)請求走主庫，而讀數(shù)據(jù)請求走從庫，由于搞了2個從庫，它們可以一起來抗住大量的讀請求，訂單sql的查詢效率就可以得到顯著的提升。

引入垂直分庫方案

引入讀寫分離方案后可能又會遇到一個問題，那就是此時商品模塊、訂單模塊、用戶模塊都部署在同一臺物理數(shù)據(jù)庫上，也就是主庫上，此時這臺物理數(shù)據(jù)庫的CPU、內(nèi)存和網(wǎng)絡(luò)的負(fù)載能力，都是商品模塊、訂單模塊、用戶模塊共用的。

如某天，商品模塊做了一些活動，此時商品模塊就會承接大量的讀請求，尷尬的是商品模塊并沒有做讀寫分離，此時商品模塊所處的這臺物理數(shù)據(jù)庫，它的CPU、內(nèi)存和網(wǎng)絡(luò)負(fù)載的占用都會很高。

關(guān)鍵是， 數(shù)據(jù)庫的資源是有限的，商品模塊已經(jīng)占用了大量的數(shù)據(jù)庫資源，而訂單模塊能用的數(shù)據(jù)庫資源就變得非常有限了，此時訂單寫數(shù)據(jù)的sql執(zhí)行時間就可能突增到了2s， 對于訂單來說肯定是萬萬不能接受的。

所以，為了避免其他業(yè)務(wù)模塊對訂單模塊的影響，將進(jìn)行了垂直分庫的改造，如下圖：

?

垂直分庫后，每個業(yè)務(wù)都有自己獨(dú)立的一臺物理服務(wù)器，之前資源相互占用的問題也就不存在了，最終完美的解決了訂單寫數(shù)據(jù)時間突增的問題。

因為隨著時間的推移，訂單單表的數(shù)據(jù)量勢必會越來越大，而訂單sql查詢的時間也會越來越慢，為了提高sql的查詢效率，同時也為了更好的擴(kuò)展性，最終得要引入這套分庫分表的方案。

來看一下分庫分表版本的訂單系統(tǒng)架構(gòu)

引入分庫分表的方案后，外賣訂單系統(tǒng)的系統(tǒng)架構(gòu)如下圖：

整個分層沒有變化，分庫分表后還是分為了三層，分別是訪問層、服務(wù)層和數(shù)據(jù)層，還是從上到下逐一介紹：

1. 訪問層： 訪問層使用的還是postman，這一層沒有任何變化。

2. 服務(wù)層：

• 增加了根據(jù)路由key改寫sql的功能，因為分庫分表后會有多個庫和表，比如訂單庫分為order_db_0和order_db_1。
• 每個數(shù)據(jù)庫中有多個訂單表，比如order_db_0中有訂單表order_info_0和order_info_1，這個時候，如果要往數(shù)據(jù)庫中插入訂單或查詢訂單，為了確定數(shù)據(jù)落在哪個庫的哪個表中，就需要根據(jù)路由key來改寫sql了，根據(jù)路由key改寫sql采用ShardingSphere來實現(xiàn)。
• 增加了數(shù)據(jù)遷移的功能，因為分庫分表后，需要將之前單庫中的數(shù)據(jù)遷移到新的庫表中，比如這里分了8庫8表，就會將原始單庫中的數(shù)據(jù)遷移到新的8庫8表中，數(shù)據(jù)遷移具體要用到全量同步、增量同步和數(shù)據(jù)驗證等功能，數(shù)據(jù)遷移的功能會使用到canal和RocketMQ。

3. 數(shù)據(jù)層： 還是使用MySQL，只不過會使用ShardingSphere來做sql改寫和讀寫分離，然后在數(shù)據(jù)層還將引入緩存，緩存使用Redis來實現(xiàn)。

結(jié)束語

本節(jié)主要對整個外賣訂單系統(tǒng)的背景、系統(tǒng)演進(jìn)的過程、單庫版本的系統(tǒng)架構(gòu)和分庫分表版本的系統(tǒng)架構(gòu)，做了一個簡單的介紹，后續(xù)就會圍繞單庫版本的訂單系統(tǒng)來進(jìn)行一步一步的優(yōu)化，最終優(yōu)化成分庫分表版本的系統(tǒng)架構(gòu)。