前 言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

索引和sql優(yōu)化

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

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

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

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

引入緩存方案

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

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

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

引入讀寫分離方案

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

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

促銷活動(dòng)期間對(duì)訂單的操作，是典型的讀多寫少場(chǎng)景，為了解決這個(gè)問題，引入了讀寫分離的方案，如下圖：

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

引入垂直分庫方案

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

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

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

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

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

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

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

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

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

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

2. 服務(wù)層：

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

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

結(jié)束語

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

為了更好的閱讀后續(xù)連載內(nèi)容，建議讀者認(rèn)真查看單庫版本和分庫分表版本的系統(tǒng)架構(gòu)圖，了解當(dāng)前訂單系統(tǒng)架構(gòu)是什么樣子的，訂單系統(tǒng)最終會(huì)做成什么樣子，形成一個(gè)整體的認(rèn)知。