簡介
前面兩篇文章主要講了數(shù)據(jù)庫讀寫分離和分表分庫的一些問題，這篇文章主要講一下我個人實現(xiàn)的一個分表分庫項目。
在此之前，我有寫過一個.Net的分庫，最近在做Java的項目，就順便做出一個Java版本，這個項目源于我另外的一個業(yè)務(wù)項目，在這個業(yè)務(wù)項目中有分表(在一個數(shù)據(jù)庫下有多張表)，當(dāng)時寫了一套基于分表的幫助類，隨著這個業(yè)務(wù)的的發(fā)展，基于分表的解決方案有一定的弊端，主要有兩個：
1. 不能很好的擴(kuò)展，在一個數(shù)據(jù)庫下面有20張表，當(dāng)業(yè)務(wù)繁忙的時候，數(shù)據(jù)庫出現(xiàn)了壓力(公司里面多個項目共用一個數(shù)據(jù)庫服務(wù)器，有可能是其他項目影響了我的項目)，這個時候想要擴(kuò)展就比較麻煩了， 我可以將其中10張表遷移到另外的機(jī)器，同時我的代碼路由算法就要改，其實將其中10張表遷移到另外服務(wù)器上，就已經(jīng)類似于分庫了。
2. 基于分表對業(yè)務(wù)的侵入性較高，我要先通過算法得到具體的表索引(即表的編號，比如user_15),然后要將整個索引和表前綴進(jìn)行拼接才能得到真正的表名。
所以在開源分表分庫的項目的時候，我對項目進(jìn)行了升級，改為分庫模式，即有多個數(shù)據(jù)庫，每個數(shù)據(jù)庫一張表，表名都一樣，這樣你就可以在mybatis中不需要再對表名進(jìn)行修改。 降低了浸入性，同時也方便后續(xù)的擴(kuò)展，你可以將這些數(shù)據(jù)庫放在一臺機(jī)器上，也可以在后續(xù)數(shù)據(jù)庫服務(wù)器性能緊張的時候，將一部分?jǐn)?shù)據(jù)庫遷移到其他機(jī)器上。
最后說一下我當(dāng)時為什么沒有選擇開源的解決方案，目前我知道的開源方案包括 sharding-jdbc ,mycat ，但是當(dāng)時時間緊，任務(wù)重，研究熟悉部署這些項目，可能需要1-2天的時間，并且后續(xù)使用過程中，出了問題，還需要花時間排查，mycat 是基于分庫的，所以并不適合我這個項目，而我的項目中，在操作數(shù)據(jù)庫之前，已經(jīng)可以知道具體要操作哪張表，對分表的操作也比較簡單，但是要得到具體的表索引比較麻煩，是要經(jīng)過多個key運算得到的，綜合所有，我選擇了自己寫了一個。
項目介紹
項目比較簡單，所有和分庫相關(guān)的都在shardingcore中。 test是測試用的。
shardingcore的項目結(jié)構(gòu)。
其中MultipleDataSource是為了實現(xiàn)切換數(shù)據(jù)庫連接，這塊代碼是參考網(wǎng)上數(shù)據(jù)庫讀寫分離的。
ShardingDBAspect是分庫的核心代碼。
