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天都比较稳定，只是对分表的支持不是太好（比如不支持基于时间的分表模式），一般没有太高并发和对响应时间严格要求的业务可以考虑尝试使用。