mysql 中间件atlas性能测试

Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。360内部使用Atlas运行的mysql业务，每天承载的读写请求数达几十亿条。

一、Atlas的整体架构

Atlas是一个位于应用程序与MySQL之间中间件。在后端DB看来，Atlas相当于连接它的客户端，在前端应用看来，Atlas相当于一个DB。Atlas作为服务端与应用程序通讯，它实现了MySQL的客户端和服务端协议，同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节，同时为了降低MySQL负担，它还维护了连接池。Atlas的整体架构，可参考下图：

二、Atlas的性能测试

1，测试硬件和配置参数

CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz, 2U 8 cores 32 processes;MEM: 128G ,DISK :SSD RAID1
innodb_buffer_pool_size=16G 单实例	mysql版本：percona 5.6.15		测试表个数：4； 总记录数：1亿
event-threads = 24、48	atlas 所在机器CPU 24线程	innodb_flush_log_at_trx_commit = 1	sync_binlog = 1

2，event-threads = 24 下连接atlas和直连DB时的qps、tps及响应时间的对比（atlas所在机器cpu 线程数 24）



图3



图4

图5

通过上述性能测试图的对比发现：

1，使用atlas性能大概比直连DB有30%~35%的下降，这里主要是atlas工作线程需要对sql进行过滤，重写等导致的，不过如果是一主多从的情况可以抵消这部分消耗；

2，响应时间大概是直连DB的1.5~2倍左右，主要是atlas工作线程需要对sql进行过滤，重写并且结果集需要先返回到atlas再返回给客户端等导致的；

3，360基础开发组自身测试结果（虚拟机上的测试）说event-threads（atlas工作线程）的配置会影响性能，

但是经过配置24和48（cpu processer 为24）后对实体机打压测试如图



图6



图7



图9

通过上述三个图的结果说明：

event-threads 只要设置到合适大小（和cpu processer大小差不多）即可再大对性能没什么太大好处

（当然这里没有测试1,4,8,16等大小的情况，以后有空再补吧）

三、Atlas的优缺点及测试结论

总结：

优点

1，实现了读写分离（并通过hint/*master*/可强制走主库，并且加入了权重配置可进行读的负载均衡

2，自身维护了一套连接池，减少了创建连接带来的性能消耗

3，支持DB动态上下线，方便横向扩展

4，支持ip过滤，实现了简单的权限控制

5，可记录所有sql，实现了简单的审计功能

缺点

1，使用atlas比直连DB，性能损耗大概是30%-35%左右

2， 使用atlas比直连DB，响应时间大概是直连DB的1.5~2倍

3，对分表的支持不是太好，只支持同schema下的hash分表，并且分表后查询只基于分表key的等值查询（如果支持范围查询，那么比直接非分表情况扫描全表的性能还差，所以360干脆就不支持）

4，atlas配置暂时不支持配置参数的动态加载，如果修改了配置需要重启atlas，这可能会对业务有一点的影响（不过一般可以做ha或者业务低峰进行重启，这个问题不是特别迫切）

总的来说作为一款开源mysql proxy，atlas总体表现还是不错的，持续压测3天都比较稳定，只是对分表的支持不是太好（比如不支持基于时间的分表模式），一般没有太高并发和对响应时间严格要求的业务可以考虑尝试使用。

参考：https://github.com/Qihoo360/Atlas