前 言

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

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

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

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

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

認識一下單庫版本的訂單系統

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

從單庫版本到分庫分表版本的整個優化過程的基礎是一個單庫版本的外賣訂單系統。

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

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

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

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

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

業務快速增長，驅動系統架構不斷演進

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

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

索引和sql優化

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

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

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

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

引入緩存方案

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

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

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

引入讀寫分離方案

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

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

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

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

引入垂直分庫方案

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

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

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

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

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

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

來看一下分庫分表版本的訂單系統架構

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

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

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來實現。
• 增加了數據遷移的功能，因為分庫分表后，需要將之前單庫中的數據遷移到新的庫表中，比如這里分了8庫8表，就會將原始單庫中的數據遷移到新的8庫8表中，數據遷移具體要用到全量同步、增量同步和數據驗證等功能，數據遷移的功能會使用到canal和RocketMQ。

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

結束語

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

為了更好的閱讀后續連載內容，建議讀者認真查看單庫版本和分庫分表版本的系統架構圖，了解當前訂單系統架構是什么樣子的，訂單系統最終會做成什么樣子，形成一個整體的認知。