MySQL-JDBC Loadbalance深入解析

背景说明

公司的整个电商系统搭建在华为云上，根据老总的估计，上线3个月之后日订单量会达到百万级别，保守估计3个月之后总订单个数预计会有5千万。MySQL单表达到千万级别，就会出现明显的性能问题。根据如此规模的数据，当时考虑了2套解决方案：

方案一：在业务上根据用户ID做拆分，将数据打散放在5台32U128G的华为云RDS上边

方案二：直接使用华为云的分布式数据库中间件DDM

 

方案一的好处是，分片算法全部在业务上实现，整个方案都在自己的控制下。后续问题定位，方案修改都会好很多；坏处是，整个方案需要业务代码支撑，访问到做了拆分的数据都需要做特殊处理，代价还是比较大的，而且对开发人员的能力要求很高。后续运维的工作也比较大。

 

方案二的好处是，直接使用云服务后续不需要担心运维的事情，另外DDM从中间件层屏蔽了分库分表的具体实现，业务可以当做单库来操作，易用性以及对代码的要求、对开发人员的要求都会低了很多。缺点就是，使用了DDM之后，对华为云的粘性会大很多。

 

综合考虑了两个方案的优缺点，最终选择了方案二，主要是基于对华为云技术能力和后续蓬勃发展的信心。

 

对DDM做了一定的调研，的确是一个非常不错的分库分表服务。支持超大规模数据，10备于单机数据库的超强性能，百万并发，读写分离，支持平滑扩容等等。。。优点数不胜数~

 

搭建到华为云之后，一直平稳运行，但是前阵子出了个奇怪的问题，在DDM技术专家的协助下，很快定位了出来，结果是MySQL-JDBC的一个bug导致。作为一个具有打破砂锅问到底、不破楼兰誓不还的程序员，决定对MySQL的相关参数做个详细的分析，免得从一个坑里边爬出来又进了另外一个。

 

Loadbalance模式说明

为了提供高性能，百万并发，DDM自身是以无状态的集群形式对外提供的。内部怎么做的我们不