你們團隊使用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。
<dependency>
<groupId>com.dangdang</groupId>
<artifactId>sharding-jdbc-core</artifactId>
<version>1.3.0</version>
</dependency>
<dependency>
<groupId>com.dangdang</groupId>
<artifactId>sharding-jdbc-config-spring</artifactId>
<version>1.3.0</version>
</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">
<property name="driverClassName"value="com.mysql.jdbc.Driver"></property>
<property name="url"value="jdbc:mysql://localhost:3306/sharding"></property>
<property name="username"value="root"></property>
<property name="password"value="sharding"></property>
</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查詢數據，這是比較經濟的一種做法。
-
根據某一個外鍵的值進行分配
前面的例子採用的就是這種方法，因爲這個數據可能會經常根據這個外鍵進行查詢。
-
根據時間進行分配
適用於一些經常按時間段進行查詢的數據，將一個時間段內的數據保存在同一個數據表中。比如訂單系統，缺省查詢一個月之內的數據。