前言

數(shù)據(jù)庫分庫分表除了使用中間件來代理請求分發(fā)之外，另外一種常見的方法就是在客戶端層面來分庫分表 —— 通過適當?shù)匕b客戶端代碼使得分庫分表的數(shù)據(jù)庫訪問操作代碼編寫起來也很方便。本文的分庫分表方案基于 MyBatis 框架，但是又不同于市面上常用的方案，它們一般都是通過編寫復雜的 MyBatis 插件來重寫 SQL 語句，這樣的插件代碼會巨復雜無比，可能最終只有插件的原作者自己可以完全吃透相關代碼，給項目的維護性帶來一定問題。本文的方案非常簡單易懂，而且也不失使用上的便捷性。它的設計哲學來源于 Python —— Explicit is better than Implicit，也就是顯式優(yōu)于隱式，它不會將分庫分表的過程隱藏起來。

很多分庫分表的設計在實現(xiàn)上會盡量將分庫分表的邏輯隱藏起來，其實這是毫無必要的。使用者必須知道背后確實進行了分庫分表，否則他怎么會無法進行全局的索引查找？他怎么會無法隨意進行多表的 join 操作。如果你真的將它當成單表來用，到上線時必然會出大問題。

項目名稱叫：shardino，項目地址：https://github.com/pyloque/shardino

接下來我們來看看在本文的方案之下，數(shù)據(jù)庫操作代碼的形式是怎樣的帖子表一共分出來 64 個表，不同的記錄會各自分發(fā)到其中一個表，可以是按 hash 分發(fā)，也可以按照日期分發(fā)，分發(fā)邏輯由用戶代碼自己來決定。在不同的環(huán)境中可以將分表數(shù)量設置為不同的值，比如在單元測試下分表設為 4 個，而線上可能需要設置為 64 個。

帖子表又會被分配到多個庫，這里就直接取模分配。假設有 4 個帖子庫，帖子表總共分出來 64 個表，分別是 post_0、post_1、post_2 一直到 post_63。那么 post_0、post_4、post_8 等分配到 0 號庫，post_1、post_5、post_9 等分配到 1 號庫，post_2、post_6、post_10 等分配到 2 號庫，post_3、post_5、post_11 等分配到 4 號庫。

從配置文件中構建 MySQLGroupStore 數(shù)據(jù)庫組對象，這個對象是我們執(zhí)行 MySQL 操作的入口，通過它可以找到具體的物理的 MySQL 主從數(shù)據(jù)源。

配置文件 application.properties 如下

這里的數(shù)據(jù)庫組是由多個對等的 Master-Slaves 對構成，每個 Master-Slaves 是由一個主庫和多個不同權重的從庫構成，Master-Slaves 對的數(shù)量就是分庫的數(shù)量。

mysqlgroup 還有一個特殊的配置選項 slaveEnabled 來控制是否需要從庫，從而關閉讀寫分離，默認是關閉的，這樣就不會去構建從庫實例相關對象。

post_k 這張表后綴 k 我們稱之為 partition number，也就是后續(xù)代碼中到處在用的 partition 變量，表明當前的記錄被分配到對應物理數(shù)據(jù)表的序號。我們需要根據(jù)記錄的內(nèi)容計算出 partition number，再根據(jù) partition number 決定出這條記錄所在的物理表屬于那個物理數(shù)據(jù)庫，然后對這個物理數(shù)據(jù)庫進行相應的讀寫操作。

在本例中，帖子表按照 userId 字段 hash 出 64 張表，平均分配到 2 對物理庫中，每個物理庫包含一個主庫和2個從庫。

有了 MySQLGroupStore 實例，我們就可以盡情操縱所有數(shù)據(jù)庫了。

從上面的代碼中可以看出所有的讀寫、創(chuàng)建、刪除表操作的第一步都是計算出 partition number，然后根據(jù)它來選出目標主從庫再進一步對目標的數(shù)據(jù)表進行操作。這里我默認開啟了autocommit，所以不需要顯式來 session.commit() 了。

在對數(shù)據(jù)表的操作過程中，又需要將具體的 partition number 傳遞過去，如此 MyBatis 才能知道具體操作的是哪個分表。

在每一條數(shù)據(jù)庫操作中都必須帶上 partition 參數(shù)，你可能會覺得這有點繁瑣。但是這也很直觀，它明確地告訴我們目前正在操作的是哪一個具體的分表。在 MyBatis 的注解 Mapper 類中，如果方法含有多個參數(shù)，需要使用 @Param 注解進行名稱標注，這樣才可以在 SQL 語句中直接使用相應的注解名稱。否則你得使用默認的變量占位符名稱 param0、param1 來表示，這就很不直觀。我們將分表的 hash 算法寫在實體類 Post 中，這里使用 CRC32 算法進行 hash。

代碼中的 partitionFor 方法的參數(shù) num 就是一共要分多少表。如果是按日期來分表，這個參數(shù)可能就不需要，直接返回日期的整數(shù)就行比如 20190304。

還有最后一個問題是多個帶權重的從庫是如何做到概率分配的。這里就要使用到 spring-jdbc 自帶的 AbstractRoutingDataSource —— 帶路由功能的數(shù)據(jù)源。它可以包含多個子數(shù)據(jù)源，然后根據(jù)一定的策略算法動態(tài)挑選出一個數(shù)據(jù)源來，這里就是使用權重隨機。

但是有個問題，我這里只需要這一個類，但是需要引入整個 spring-boot-jdbc-starter 包，有點拖泥帶水的感覺。我研究了一下 AbstractRoutingDataSource 類的代碼，發(fā)現(xiàn)它的實現(xiàn)非常簡單，如果就仿照它自己實現(xiàn)了一個簡單版的，這樣就不需要引入整個包代碼了。

還需進一步深入理解其實現(xiàn)代碼的可以將 shardino 代碼倉庫拉到本地跑一跑

里面有單元測試可以運行起來，運行之前需要確保本機安裝了 docker 環(huán)境

這條指令會啟動2對主從庫，各1主兩從。在本例中雖然用到了 springboot ，其實也只是用了它方便的依賴注入和單元測試功能，shardino 完全可以脫離 springboot 而獨立存在。shardino 并不是一個完美的開源庫，它只是一份實現(xiàn)代碼的樣板，如果讀者使用的是其它數(shù)據(jù)庫或者 MySQL 的其它版本，那就需要自己微調(diào)一下代碼來適配了。

總結

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對VeVb武林網(wǎng)的支持。