前 言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

索引和sql優(yōu)化

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

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

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

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

引入緩存方案

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

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

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

引入讀寫(xiě)分離方案

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

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

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

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

引入垂直分庫(kù)方案

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

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

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

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

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

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

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

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

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

1. 訪(fǎng)問(wèn)層：訪(fǎng)問(wèn)層使用的還是postman，這一層沒(méi)有任何變化。

2. 服務(wù)層：

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

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

結(jié)束語(yǔ)

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

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