文章嘗試使用噹噹開源的Sharding JDBC框架實現數據分表操作。它是直接封裝JDBC API，可以理解為增強版的JDBC驅動，舊代碼遷移成本幾乎為零。我們使用一個JPA項目的一個數據表進行了測試，確實改動量比較小。 ...

你們團隊使用SpringMVC+Spring+JPA框架，快速開發了一個NB的系統，上線後客戶訂單跟雪花一樣紛沓而來。

慢慢地，你的心情開始變差，因為客戶和產品的抱怨越來越頻繁，抱怨的最多的一個問題就是：系統越來越慢了。

1 常規優化

你組織團隊，進行了一系列的優化。

1.1 數據表索引優化

經過初步分析，發現瓶頸在資料庫。WEB伺服器的CPU閑來無事，但資料庫伺服器的CPU使用率高居不下。

於是，請來架構組的DBA同事，監控資料庫的訪問，整理出那些耗時的SQL，並且進行SQL查詢分析。根據分析結果，對數據表索引進行重新整理。同時也對資料庫本身的參數設置進行了優化。

優化後，頁面速度明顯提升，客戶抱怨減少，又過了一段時間的安逸日子。

1.2 多點部署+負載均衡

慢慢的，訪問速度又不行了，這次是WEB伺服器壓力很大，資料庫伺服器相對空閑。經過分析，發現是系統併發用戶數太多，單WEB伺服器不能夠支持如此眾多的併發請求。

於是，請架構協助進行WEB多點部署，前端使用nginx做負載分發。這時候必須要解決的一個問題就是用戶會話保持的問題。這可以有幾種不同解決方案：

1、nginx實現sticky分發

因為nginx預設沒有sticky機制，可以使用ip_hash方式來代替。

2、配置Tomcat實現Session複製

3、代碼使用SpringSession，利用redis實現session複製。

具體做法就不一一介紹了。其中使用SpringSession的方法，可以參考我的文章《集群環境CAS的問題及解決方案》。

2 試用噹噹的Sharding JDBC框架

多點部署之後，系統又運行了一段時間，期間增加了更多的WEB節點，基本能應對客戶需求。慢慢的，增加WEB伺服器也不能解決問題了，因為系統瓶頸又回到了資料庫伺服器。SQL執行時間越來越長，而且無法優化。原因也很簡單，數據量太大。

單表數據已經超過幾千萬行，通過資料庫的優化已經不能滿足速度的要求。分庫分表提到了日程上，必須解決。

因為使用了JPA，如果分庫分表需要對數據訪問層做較大的改動，工作量太大，修改的風險也太高。恰好看到噹噹開源了其Sharding-JDBC組件，摘抄一段介紹：

https://github.com/dangdangdotcom/sharding-jdbc

Sharding-JDBC直接封裝JDBC API，可以理解為增強版的JDBC驅動，舊代碼遷移成本幾乎為零：

可適用於任何基於java的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。
可基於任何第三方的資料庫連接池，如：DBCP, C3P0, BoneCP, Druid等。
理論上可支持任意實現JDBC規範的資料庫。雖然目前僅支持MySQL，但已有支持Oracle，SQLServer，DB2等資料庫的計劃。

它支持JPA，可以在幾乎不修改代碼的情況下完成分庫分表的實現。因此，選擇這個框架做一次分庫分表的嘗試。

先做一個最簡單的試用，不做分庫，僅做分表。選擇數據表operate_history，這個數據表記錄所有的操作歷史，是整個系統中數據量最大的一個數據表。

希望將這個表拆分為四個數據表，分別是 operate_history_0operate_history_1 operate_history_2 operate_history_3。數據能夠分配保存到四個數據表中，降低單表的數據量。同時，為了儘量減少跨表的查詢操作，決定使用欄位 entity_key為分表依據，這樣同一個entity對象的所有操作，將會記錄在同一個數據表中。拆分後的數據表結構為：

3 實現過程

以下是針對JPA項目的修改過程。其他項目請參考官方網站的文檔。

3.1 修改pom.xml增加dependency

需要添加兩個jar，sharding-jdbc-core和sharding-jdbc-config-spring。

<groupId>com.dangdang</groupId>

<artifactId>sharding-jdbc-core</artifactId>

</dependency>

<groupId>com.dangdang</groupId>

<artifactId>sharding-jdbc-config-spring</artifactId>

</dependency>

3.2 修改Spring中Database部分的配置

原Database配置

<bean id="dataSource"class="org.apache.tomcat.jdbc.pool.DataSource"destroy-method="close">

<propertyname="driverClassName"value="com.mysql.jdbc.Driver"></property>

<propertyname="url" value="jdbc:mysql://localhost:3306/sharding"></property>

<propertyname="username" value="root"></property>

<propertyname="password" value="sharding"></property>

</bean>

修改後的配置

<beanid="db-node-0"class="org.apache.tomcat.jdbc.pool.DataSource"destroy-method="close">

</bean>

<rdb:strategyid="historyTableStrategy"

sharding-columns="entity_key"

algorithm-class="cn.codestory.sharding.SingleKeyTableShardingAlgorithm"/>

<rdb:data-sourceid="dataSource">

<rdb:sharding-ruledata-sources="db-node-0"default-data-source="db-node-0">

<rdb:table-rules>

<rdb:table-rulelogic-table="operate_history"

actual-tables="operate_history_0,operate_history_1,operate_history_2,operate_history_3"

table-strategy="historyTableStrategy" />

</rdb:table-rules>

</rdb:sharding-rule>

</rdb:data-source>

3.3 編寫類SingleKeyTableShardingAlgorithm

這個類用來根據entity_key值確定使用的分表名。參考sharding提供的示例代碼進行修改。核心代碼如下

publicCollection<String> doInSharding(

Collection<String>availableTargetNames,

ShardingValue<Long>shardingValue) {

int targetCount = availableTargetNames.size();

Collection<String> result = newLinkedHashSet<>(targetCount);

Collection<Long> values =shardingValue.getValues();

for (Long value : values) {

for (String tableNames :availableTargetNames) {

if (tableNames.endsWith(value % targetCount+ "")) {

result.add(tableNames);

}

return result;

}

這是一個簡單的實現，對entity_key進行求模，用餘數確定數據表名。

3.4 修改主鍵生成方法

因為數據分表保存，不能使用identify方式生成數據表主鍵。如果主鍵是String類型，可以考慮使用uuid生成方法，但它查詢效率會相對比較低。

如果使用long型主鍵，可以使用其他方式，一定要確保各個子表中的主鍵不重覆。

3.5 歷史數據的處理

根據數據分表的規則，需要對原有數據包的數據進行遷移，分別移動到四個數據表中。如果不做這一步，或者數據遷移到了錯誤的數據表，後續將會查詢不到這些數據。

至此，對項目的修改基本完成，重新啟動項目並增加operate_history數據，就會看到新添加的數據，已經根據我們的分表規則，插入到了某一個數據表中。查詢的時候，能夠同時查詢到多個實際數據表中的數據。

4 數據分表規則的一些考慮

前面的例子，演示的是根據entity_key進行分表，也可以使用其他欄位如主鍵進行分表。以下是我想到的一些分表規則：

根據主鍵進行分配

這種方式能夠實現最平均的分配方法，每生成一條新數據，會依次保存到下一個數據表中。

根據用戶ID進行分配

這種方式能夠確保同一個用戶的所有數據保存在同一個數據表中。如果經常按用戶id查詢數據，這是比較經濟的一種做法。

根據某一個外鍵的值進行分配

前面的例子採用的就是這種方法，因為這個數據可能會經常根據這個外鍵進行查詢。

根據時間進行分配

適用於一些經常按時間段進行查詢的數據，將一個時間段內的數據保存在同一個數據表中。比如訂單系統，預設查詢一個月之內的數據。

利用Sharding-Jdbc實現分表