低成本和高性能的MySQL云数据库的实现

UMP(Unified MySQL Platform)系统是淘宝核心系统数据库团队开发的低成本和高性能的MySQL云数据方案，关键模块采用Erlang语言实现。

系统中包含了controller服务器、proxy服务器、agent服务器、API/Web服务器、日志分析服务器、信息统计服务器等组件，并且依赖于Mnesia、LVS、RabbitMQ、ZooKeeper等开源组件。

在“低成本和高性能的MySQL云数据库的架构探索”一文中，我们介绍了UMP的系统结构和各个组件的功能，本文里，我们会进一步来探索RabbitMQ和ZooKeeper在系统中的应用以及proxy服务器的实现，整个系统如何实现容灾、读写分离、分库分表等功能，介绍资源管理、隔离和调度等技术，以及在保障用户数据安全上的做法。

RabbitMQ
RabbitMQ是一个用Erlang开发的工业级的消息队列产品。

集群中各节点间的通信（不包括SQL查询、日志等大数据流的传输，这些还是直接走TCP的）都通过RabbitMQ，作为消息通讯的中间件来使用，来保证消息发送的可靠性。

集群初始化时会在RabbitMQ中为集群里的每个节点创建一个队列，作为节点的“信箱”。

节点间发送消息时不管对方在不在线，只要写消息到对方的“信箱”里即可，接下来由对方节点上运行的RabbitMQ客户端接收消息，调用相应的处理例程。

消息处理完后，客户端会回复一个ACK包到RabbitMQ，从“信箱”中删除这条消息。

基于RabbitMQ可以实现RPC，客户端除了回复ACK包给RabbitMQ删除Request消息外，还向发送者的“信箱”写入一条Reply消息。

RabbitMQ是支持事务的，可以保证删除Request消息和写Reply消息在一个原子操作中完成。

图1节点之间通过RabbitMQ实现RPC
如果接收者在处理消息的过程中崩溃了，那么消息还会存储在RabbitMQ中，重启后，消息会再次推送过来，由接收者继续处理。

RabbitMQ可以保证消息被发送出去，被接收者处理，但不幸的是，无法保证消息只被发送/处理一次，主要原因在于RabbitMQ不支持XA。

首先，发送者将消息写到MQ和在本地写一条日志不能在同一个事务中完成，如果发送者将消息写到MQ之后，在本地写日志之前崩溃了，重启后无法确定消息是否被发送，只能尝试重发；同样，消息的接收方无法将处理消息和从MQ中删除消息放在同一个事务中完成，如果消息的接收方在处理完消息之后，从MQ中删除消息之前崩溃了，那么重启后仍然会继续收到并处理这个消息。

因此消息的接受方在处理消息时需要保证幂等性（idempotent），即同一条消息被处理多遍不会有副作用，比如controller向agent发送备份命令时可以捎带上一次备份的时间点，agent检查这个时间点一致后再执行备份操作，这样可以保证同一条备份命令被发送多次时不会创建多个备份。

利用RabbitMQ的路由功能（Exchange）还可以实现消息广播，例如系统中会创建一个叫proxy的Exchange，类型配置为’fanout’，当有新的proxy服务器注册时，节
点的“信箱”就会绑定到该Exchange上。

这样当controller服务器需要向所有的proxy 服务器发送通知时，比如执行主备切换操作，发送到Exchange上的消息会写入所有proxy 服务器的“信箱”中。

RabbitMQ还实现了一种镜像队列(mirrored queue)的算法提供HA。

创建队列时可以通过传入“x-ha-policy”参数设置队列为镜像队列，镜像队列会存储在多个Rabbit MQ 节点上，并配置成一主多从的结构，可以通过“x-ha-policy-params”参数来具体指定master节点和slave节点的列表。

所有发送到镜像队列上的操作，比如消息的发送和删除，都会先在master节点上执行，再通过一种叫GM（Guaranteed Multicast）的原子广播（atomic broadcast）算法同步到各slave节点。

GM算法通过两阶段的提交，可以保证master节点发送到所有slave节点上的消息要么全部执行成功，要么全部失败；通过环形的消息发送顺序，即master节点发送消息给一个slave节点，这个slave节点依次发送给下一个slave节点，最终消息回到master节点，保证了主从节点上的负载差别不大。

ZooKeeper
ZooKeeper在分布式集群中提供分布式锁、名字服务等，它把分布式集群比做动物园，而自己则扮演动物园管理员的角色。

ZooKeeper最早是由Yahoo!开发，应用在Hadoop 软件栈中发挥Google Chubby的作用，我们在项目中单独使用ZooKeeper，实现三个功能：
1.作为全局的配置服务器。

配置文件原先是放在本地的，变更配置需要到所有的节点上去修改，这不仅是重复性的工作而且容易出错。

放在ZooKeeper上后，所有节点都监视配置文件的变化，文件一旦被修改，所有节点都会重新加载并触发相应动作。

2.提供分布式锁。

集群中部署了多个controller服务器通过热备实现HA，但这些controller 服务器不能同时执行同一个操作。

例如，一个MySQL实例挂掉后，如果所有的controller 服务器都去跟踪处理并且发起主备切换流程，proxy服务器和agent服务器就会收到多条切换的命令，集群就乱套了。

因此简单起见，我们规定同一时间，整个集群中多个controller 服务器只能选举出一个leader，由这个leader负责发起各种系统任务。

Leader的选举功能就是通过ZooKeeper的分布式锁功能实现的。

3.监控所有MySQL实例。

我们为MySQL服务器开发了一个ZooKeeper客户端插件，启动后会连接到ZooKeeper服务器上并创建一个临时节点，如果MySQL进程死掉，经过5秒的超时时间，这个临时节点就会被删除，从而被后台运行的监控daemon检查到，如果死掉的MySQL进程是主库的话则触发主从切换流程，是从库的话则从库的读权重被设置为0。

容灾
当MySQL服务器出现故障时，系统会执行对用户透明的故障恢复过程，用户感知不到主库宕机和上线事件，proxy服务器向用户隐藏了这些事件，提供给用户的是一直可用的数据库连接。