前 言

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

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

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

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

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

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

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

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

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

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

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

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

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

業(yè)務快速增長，驅動系統(tǒng)架構不斷演進

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

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

索引和sql優(yōu)化

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

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

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

• 隱式轉換導致索引失效。
• 一個是關于join連接查詢的?。

引入緩存方案

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

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

?

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

引入讀寫分離方案

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

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

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

?

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

引入垂直分庫方案

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

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

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

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

?

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

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

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

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

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

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

2. 服務層：

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

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

結束語

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