博学谷分库分表实践1分库分表ShardingJDBC课程内容介绍

你们团队使用SpringMVC+Spring+JPA框架，快速开发了一个NB的系统，上线后客户订单跟雪花一样纷沓而来。
慢慢地，你的心情开始变差，因为客户和产品的抱怨越来越频繁，抱怨的最多的一个问题就是：系统越来越慢了。
1 常规优化你组织团队，进行了一系列的优化。
1.1 数据表索引优化经过初步分析，发现瓶颈在数据库。WEB服务器的CPU闲来无事，但数据库服务器的CPU使用率高居不下。
于是，请来架构组的DBA同事，监控数据库的访问，整理出那些耗时的SQL，并且进行SQL查询分析。根据分析结果，对数据表索引进行重新整理。同时也对数据库本身的参数设置进行了优化。
优化后，页面速度明显提升，客户抱怨减少，又过了一段时间的安逸日子。
1.2 多点部署+负载均衡【博学谷分库分表实践1分库分表ShardingJDBC课程内容介绍】慢慢的，访问速度又不行了，这次是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