你们团队使用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。
com.dangdang
sharding-jdbc-core
1.3.0
com.dangdang
sharding-jdbc-config-spring
1.3.0
3.2 修改Spring中Database部分的配置
原Database配置
修改后的配置
sharding-columns="entity_key"
algorithm-class="cn.codestory.sharding.SingleKeyTableShardingAlgorithm"/>
actual-tables="operate_history_0,operate_history_1,operate_history_2,operate_history_3"
table-strategy="historyTableStrategy" />
3.3 编写类SingleKeyTableShardingAlgorithm
这个类用来根据entity_key值确定使用的分表名。参考sharding提供的示例代码进行修改。核心代码如下
publicCollection doInSharding(
CollectionavailableTargetNames,
ShardingValueshardingValue) {
int targetCount = availableTargetNames.size();
Collection result = newLinkedHashSet<>(targetCount);
Collection 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查询数据，这是比较经济的一种做法。
根据某一个外键的值进行分配
前面的例子采用的就是这种方法，因为这个数据可能会经常根据这个外键进行查询。
根据时间进行分配
适用于一些经常按时间段进行查询的数据，将一个时间段内的数据保存在同一个数据表中。比如订单系统，缺省查询一个月之内的数据。
