-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Atlas的架构
Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上,对其进行了优化,增加了一些新的功能特性。360内部使用Atlas运行的mysql业务,每天承载的读写请求数达几十亿条。
Atlas是一个位于应用程序与MySQL之间中间件。在后端DB看来,Atlas相当于连接它的客户端,在前端应用看来,Atlas相当于一个DB。Atlas作为服务端与应用程序通讯,它实现了MySQL的客户端和服务端协议,同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节,同时为了降低MySQL负担,它还维护了连接池。Atlas的整体架构,可参考下面这两幅图:
Atlas启动后会创建多个线程,其中一个为主线程,其余为工作线程。主线程负责监听所有的客户端连接请求,工作线程只监听主线程的命令请求。
如下图所示,主线程接收到客户端的连接请求,将该请求的相关信息封装为一个名为CON的结构,再把该结构推入一个异步队列。然后通过round-robin方式选择一个工作线程,向其发送一个字节的数据包以激活它。工作线程在收到主线程的激活指令后,从异步队列中取出CON结构,开始处理客户端的请求。
下图是一个可以参考的整体架构,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而不必担心对前端造成影响了。
[mysql-proxy]
- 管理接口的用户名
- 管理接口的密码
- Atlas后端连接的MySQL主库的IP和端口,可设置多项,用逗号分隔
- 从库
- 用户名和密码配置项,需要和主从复制配置的用户名和密码配置一样
- 后台运行
- 工作线程数,对Atlas的性能有很大影响,可根据情况适当设置
- 日志级别,分为message、warning、critical、error、debug五个级别
- 日志存放的路径
- SQL日志的开关,可设置为OFF、ON、REALTIME,OFF代表不记录SQL日志,ON代表记录SQL日志,REALTIME代表记录SQL日>志且实时写入磁盘,默认为OFF
- sql-log = OFF
- 慢日志输出设置。当设置了该参数时,则日志只输出执行时间超过sql-log-slow(单位:ms)的日志>记录。不设置该参数则输出全部日志。
- 实例名称,用于同一台机器上多个Atlas实例间的区分
- Atlas监听的工作接口IP和端口
- Atlas监听的管理接口IP和端口
- 分表设置,此例中person为库名,mt为表名,id为分表字段,3为子表数量,可设置多项,以逗号分>隔,若不分表则不需要设置该项
- tables = person.mt.id.3
- 默认字符集,设置该项后客户端不再需要执行SET NAMES语句
- 允许连接Atlas的客户端的IP,可以是精确IP,也可以是IP段,以逗号分隔,若不设置该项则允许所>有IP连接,否则只允许列表中的IP连接
- client-ips = 127.0.0.1, 192.168.1
- Atlas前面挂接的LVS的物理网卡的IP(注意不是虚IP),若有LVS且设置了client-ips则此项必须设置>,否则可以不设置
- lvs-ips = 192.168.1.1