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

1.Atlas的整体架构

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

2.Atlas的线程模型

Atlas启动后会创建多个线程，其中一个为主线程，其余为工作线程。主线程负责监听所有的客户端连接请求，工作线程只监听主线程的命令请求。

如下图所示，主线程接收到客户端的连接请求，将该请求的相关信息封装为一个名为CON的结构，再把该结构推入一个异步队列。然后通过round-robin方式选择一个工作线程，向其发送一个字节的数据包以激活它。工作线程在收到主线程的激活指令后，从异步队列中取出CON结构，开始处理客户端的请求。

3.Atlas配合LVS使用的架构

下图是一个可以参考的整体架构，LVS前端做负载均衡，两个Atlas做HA,防止单点故障。LVS周期性地对后端Atlas的存活检测有两种方式，一是直接去探测端口是否可连接，二是执行一个脚本，这个脚本会去尝试连接Atlas，通过脚本的返回值来决定每个后端是否可用。Atlas有两种运行状态，通常为online，可通过发信号将其置为offline。Atlas检测到来请求的IP是LVS的网卡IP时，如果处于online状态，就向LVS的检测脚本返回online，如果处于offline状态，就向脚本返回offline。比如我现在因为某种原因需要重启一台Atlas，但直接重启势必导致瞬间的SQL请求全部失败，对前端应用造成影响。因此我先发下线信号将Atlas置为offline状态，当LVS的检测脚本发现返回值是offline时，便将这台Atlas摘除，从此时开始便没有新的请求导向这台Atlas。等到已经打向这台Atlas的SQL请求处理完毕后(这是一个很短的时间)，就可以安全重启Atlas而不必担心对前端造成影响了。