数据库中间件-分库分表压测报告
测试环境
软硬件环境
- 4个彼此相互独立阿里rds实例：硬件配置相同，每个配置为：4核心、8GB内存、20GB磁盘、2000 IOPS，每个实例创建一个数据库名称为dbproxy
- 一个中间件节点，硬件配置相同，配置为：8核心、8GB内存、20GB磁盘 中间件默认工作线程数：32
- 一个客户端节点，硬件配置相同，配置为：4核心、8GB内存、20GB磁盘
压力测试工具：基于sysbench-0.5开源定制扩展版 - 一个表：表名为为sbtest1用hash算法切分到4个rds数据库中
- 测试方法：每次压力测试时，分别在2个节点近乎同时各启动一个sysbench客户端。
- 中间件日志级别设置：Mycat和Altas日志级别设置为error
- Mycat jvm堆内存配置：4GB heap 1GB堆外内存
- 测试数据：每次执行insert操作向空表中写入400w条记录，select、update以此数据为基础进行操作
数据库Sharding
数据库Sharding
测试报告
Atlas与Mycat比较
一个sysbench客户端，利用sysbench测试并发线程个数不同的情况下，分别执行insert、select，update三种操作，执行400w次。 测试连接Atlas和Mycat这两种情况下的QPS（QPS越大，系统性能越好）、每条记录请求响应耗时， 每组数据重复测试三次后取平均值，具体数据对比如下表所示：
所有下面测试Mycat执行操作过程中，为了获得最佳效果性能和吞吐量，使用不同gc垃圾回收算法进行基准压力测试且都是jit热代码(多次调用后再测试)，取出表格中最佳一组数据用于趋势图对比，经过实验数据得出不同gc算法对Mycat吞吐量影响很小，高级gc算法有些吞吐量还降低了，影响较大因素为新生代堆大小配置。
统计QPS
(记录数/sec、T95数据)
统计QPS趋势图
上表数据对应的Atlas和Mycat执行insert操作QPS对比趋势图
结合以上图表和数据可以看出，当sysbench达到64线程数出现拐点，Mycat吞吐量上升比较平缓，Altas则近似直线上升，与Mycat相比Altas吞吐量高近40%
上表数据对应的Atlas和Mycat执行select操作QPS对比趋势图
结合以上图表和数据可以看出，当sysbench达到64线程出现拐点，经过业务和场景分析得出中间件转发数据为短生命周期，且多次测试验证，当调大新生代堆大小会有一些改善。以128线程压测为例，默认新生代堆大小为350MB时QPS是34351/sec，当新生代堆大小改为1500MB时QPS是35076/sec，改为2500MB则QPS是37376，吞吐量提升8%左右。总体上atlas吞吐量高于Mycat一倍以上
上表数据对应的Atlas和Mycat执行update操作QPS对比趋势图
结合以上图表和数据可以看出，当sysbench达到64线程出现拐点，Mycat吞吐量遇到瓶颈上升不明显，以128线程压测为例，默认新生代堆大小为350MB时QPS是30377/sec，当新生代堆大小改为1500MB时QPS是31922/sec，改为2500MB则QPS是37970/sec，吞吐量提升25%左右
统计记录请求响应耗时
(每条记录请求响应耗时、单位毫秒、T95数据)：
统计记录请求响应耗时趋势图
上表数据对应的Atlas和Mycat执行insert操作耗时对比趋势图
结合以上图表和数据可以看出，Atlas和Mycat耗时相近，原因是瓶颈在于rds的IOPS限制，insert性能依赖于rds的IOPS能力，不能充分发挥Atlas能量
上表数据对应的Atlas和Mycat执行select操作耗时对比趋势图
结合以上图表和数据可以看出，当sysbench达到64线程出现拐点，Mycat耗时陡然增加且增速比Atlas快
上表数据对应的Atlas和Mycat执行update操作耗时对比趋势图
结合以上图表和数据可以看出，Atlas和Mycat耗时较为相近，原因是瓶颈在于rds的IOPS限制，update性能依赖于rds的IOPS能力，不能充分发挥Atlas能量
统计硬件资源消耗
一个sysbench客户端，利用sysbench测试并发线程个数不同的情况下，分别执行400w次insert、select、update操作，中间件部署机器资源消耗(cpu消耗、load负载)，每组数据重复测试三次后取平均值，具体数据对比如下表所示：
统计硬件资源消耗趋势图
cpu消耗趋势图：
上表数据对应的Atlas和Mycat执行insert操作cpu消耗对比趋势图
结合以上图表和数据可以看出，当sysbench达到64线程出现拐点，Mycat的cpu消耗更大，通过jstack + top分析java进程消耗cpu最多线程(开源工具)，原因为jvm内置线程消耗较大(gc等线程)
上表数据对应的Atlas和Mycat执行select操作cpu消耗对比趋势图
结合以上图表和数据可以看出，虽然客户端64线程压测Atlas的吞吐量远大于Mycat，但cpu消耗却相近，Atlas相比Mycat消耗cpu少很多。
上表数据对应的Atlas和Mycat执行update操作cpu消耗对比趋势图
结合以上图表和数据可以看出，当sysbench达到32线程出现拐点，Mycat的cpu消耗更大，通过jstack + top分析java进程消耗cpu最多线程(开源工具)，原因为jvm内置线程消耗较大(gc等线程)
load负载趋势图
上表数据对应的Atlas和Mycat执行insert操作load负载对比趋势图
结合以上图表和数据以及QPS、cpu综合分析可以看出，当sysbench达到32线程出现拐点，rds遇到IOPS瓶颈，Atlas很多线程处于wait状态，性能无法充分发挥，随着客户端线程增加，所以导致Atlas待调度执行的任务较多
上表数据对应的Atlas和Mycat执行select操作load负载对比趋势图
同理select分析
上表数据对应的Atlas和Mycat执行update操作load负载对比趋势图
同理select分析
mycat jvm监控
当Mycat用默认gc算法时，用java提供可视化工具jvisualvm，监控了jvm heap、cpu等情况，综合分析转发数据生命周期短，堆内存占用较少，很少fullgc，在400w数据测试中也就出现1~2次fullgc，mingc相对较多，cpu波峰值地方是sysbench初始化时候发生的。
insert
select
update
综合分析
本次测试时中间件线程数为机器4倍，基本能充分发挥中间件性能。从执行SQL类型、记录请求响应耗时、cpu消耗、cpu load负载等多个维度综合评估Atlas和Mycat的性能及吞吐量，最大限度保证数据和性能尽量接近真实值。在同等软硬件环境下，Atlas能充分利用硬件资源，极限吞吐量为Mycat一倍以上(个人觉得25~40%比较正常，但是测试select确实大一倍)，通过商业中间件OneProxy与Mycat对比，也可以作出印证，OneProxy测试报告地址。
OneProxy与Atlas一样，用c语言开发
某Java类的Proxy，就是指的Mycat，因为平民软件迁移了好几个Mycat的客户端
用sysbench测试的缺点就是模拟的表结构太简单，而且每条记录最大为200字节，因此无法验证gc对Mycat影响，400w数据操作过程中只有1~2次fullgc，如果真实环境中是不是数据量大些fullgc会频繁些呢？
方案选型
关于中间件方案选型，要从多个维度考虑，例如性能和吞吐量、关键功能完善度，公司投入力量，单纯从吞吐量考虑Atlas无疑胜出，如果自动化(运维化)、服务化、产品化角度考虑Mycat是必然选择。不过Mycat优势也明显;
关于吞吐量和性能问题，Mycat虽然吞吐量较差，但线上一般都是通过中间件前面加一层lvs代理部署来做ha的，就是可以多部署Mycat实例弥补不足。
个人观点：我没有特定倾向，任意语言都可以，主要是结合公司业务场景、需求、功能要求、资源投入程度、紧急程度等综合因素来做决定。如果这方面清晰了(方向和目标定了)，就容易选择了。
中间件上线准备工作
Atlas和Mycat测试的版本都支持分库但不分表，一个数据库只能建立一张表，但不支持单库多表，如果业务需要支持分库分表，就要在一个数据库内可以切分多张表情况。上线需要适配改造，1.通过DBA运维手段解决 2.修改中间件代码实现单库分表功能，二者选其一。
注明：Atlas开源有2个版本，一个版本支持只支持单库分表，另外一个版本支持跨库分表不支持单库多表