【作者主页】Francek Chen
【专栏介绍】⌈ ⌈ ⌈大数据技术原理与应用 ⌋ ⌋ ⌋专栏系统介绍大数据的相关知识，分为大数据基础篇、大数据存储与管理篇、大数据处理与分析篇、大数据应用篇。内容包含大数据概述、大数据处理架构Hadoop、分布式文件系统HDFS、分布式数据库HBase、NoSQL数据库、云数据库、MapReduce、Hadoop再探讨、数据仓库Hive、Spark、流计算、Flink、图计算、数据可视化，以及大数据在互联网领域、生物医学领域的应用和大数据的其他应用。
【GitCode】专栏资源保存在我的GitCode仓库：https://gitcode.com/Morse_Chen/BigData_principle_application。
文章目录
-
- [一、UMP 系统概述](#一、UMP 系统概述)
- [二、UMP 系统架构](#二、UMP 系统架构)
-
- （一）Mnesia
- （二）RabbitMQ
- （三）ZooKeeper
- （四）LVS
- [（五）Controller 服务器](#（五）Controller 服务器)
- [（六）Web 控制台](#（六）Web 控制台)
- [（七）Proxy 服务器](#（七）Proxy 服务器)
- [（八）Agent 服务器](#（八）Agent 服务器)
- （九）日志分析服务器
- （十）信息统计服务器
- （十一）愚公系统
- [三、UMP 系统功能](#三、UMP 系统功能)
- 小结
不同的云数据库产品采用的系统架构存在很大差异，下面以阿里巴巴核心系统数据库团队开发的 UMP（Unified MySQL Platform）系统为例进行介绍。
一、UMP 系统概述
UMP 系统是低成本和高性能的 MySQL 云数据库方案，关键模块采用 Erlang 实现。开发者通过网络从平台上申请 MySQL 实例资源，利用平台提供的单一入口来访问数据。UMP 系统把各种服务器资源划分为资源池，并以资源池为单位把资源分配给 MySQL 实例。系统中包含了一系列组件，这些组件协同工作，以对用户透明的形式提供主从热备、数据备份、迁移、容灾、读写分离、分库分表等一系列服务。系统内部将用户划分为 3 种类型，分别是数据量和流量比较小的用户、中等规模用户，以及需要分库分表的用户。多个小规模用户可以共享一个 MySQL 实例，中等规模用户独占一个 MySQL 实例，需要分库分表的用户的多个 MySQL 实例可以共享同一台物理机，UMP 系统通过这些方式实现了资源的虚拟化，降低了整体成本。UMP 系统通过"用 Cgroup 限制 MySQL 进程资源"和"在 Proxy 服务器端限制 QPS"两种方式，实现了资源隔离、按需分配，以及限制 CPU、内存和 I/O 资源；同时，UMP 系统还支持在不影响提供数据服务的前提下根据用户业务的发展进行动态扩容和缩容。UMP 系统还综合运用了 SSL 数据库连接、数据访问 IP 白名单、记录用户操作日志、SQL 拦截等技术，来有效保护用户的数据安全。
总的来说，UMP 系统架构设计遵循了以下原则。
① 保持单一的系统对外入口，并且为系统内部维护单一的资源池。
② 消除单点故障，保证服务的高可用性。
③ 保证系统具有良好的可伸缩性，能够动态地增加、删减计算与存储节点。
④ 保证分配给用户的资源也是弹性可伸缩的，资源之间相互隔离，确保应用和数据的安全。
二、UMP 系统架构
UMP 系统架构如图1所示，UMP 系统中的角色包括 Controller 服务器、Web 控制台、Proxy 服务器、Agent 服务器、日志分析服务器、信息统计服务器、愚公系统；依赖的开源组件包括 Mnesia、RabbitMQ、ZooKeeper 和 LVS。
（一）Mnesia
Mnesia 是一个分布式数据库管理系统，适合电信及其他需要持续运行和具备软实时特性的 Erlang 应用，是构建电信应用的控制系统平台---开放式电信平台（Open Telecom Platform，OTP）的一部分。Erlang 是一种结构化、动态类型的编程语言，内建并行计算支持，非常适合构建分布式、软实时并行计算系统。使用 Erlang 编写出的应用，在运行时通常由成千上万个轻量级进程组成，并通过消息传递相互通信，Erlang 的进程间上下文切换要比 C 程序高效得多。Mnesia 与 Erlang 编程语言是紧耦合的，其最大的好处是在操作数据时，不会发生由于数据库与编程语言所用的数据格式不同带来阻抗失配问题。Mnesia 支持事务，支持透明的数据分片，利用两阶段锁实现分布式事务，可以线性扩展到至少 50 个节点。Mnesia 的数据库模式（schema）可在运行时动态重配置，表能被迁移或复制到多个节点来改进容错性。Mnesia 的这些特性，使其在开发云数据库时被用来提供分布式数据库服务。
图1 UMP系统架构
（二）RabbitMQ
RabbitMQ 是一个用 Erlang 开发的工业级的消息队列产品（功能类似于 IBM 公司的消息队列产品 IBM WebSphere MQ），作为消息传输中间件来使用，可以实现可靠的消息传送。UMP 集群中各个节点之间的通信，不需要建立专门的连接，都是通过读写队列消息来实现的。
（三）ZooKeeper
ZooKeeper 是高效和可靠的协同工作系统，提供分布式锁之类的基本服务（如统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等），用于构建分布式应用，减轻分布式应用程序所承担的协调任务（关于 ZooKeeper 的工作原理可以参考相关书籍或网络资料）。在 UMP 系统中，ZooKeeper 主要发挥 3 个作用。
（1）作为全局的配置服务器。UMP 系统需要运行多台服务器，它们运行的应用系统的某些配置项是相同的，如果要修改这些相同的配置项，就必须同时到多个服务器上去修改，这样做不仅麻烦，而且容易出错。因此，UMP 系统把这类配置信息完全交给 ZooKeeper 来管理，把配置信息保存在 ZooKeeper 的某个目录节点中，然后在所有需要修改的服务器中对这个目录节点设置监听，也就是监控配置信息的状态，一旦配置信息发生变化，每台服务器就会收到 ZooKeeper 的通知，然后从 ZooKeeper 获取新的配置信息。
（2）提供分布式锁。UMP 集群中部署了多个 Controller 服务器，为了保证系统的正确运行，对于某些操作，在某一时刻，只能由一个服务器执行，而不能由多台服务器同时执行。例如一个MySQL 实例发生故障后，需要进行主备切换，由另一个正常的服务器来代替当前发生故障的服务器，如果这个时候所有的 Controller 服务器都去跟踪处理并且发起主备切换流程，那么，整个系统就会进入混乱状态。因此，在同一时间，必须从集群的多个 Controller 服务器中选举出一个"总管"，由这个"总管"负责发起各种系统任务。ZooKeeper 的分布式锁功能能够帮助选出一个"总管"，让这个"总管"来管理集群。
（3）监控所有 MySQL 实例。集群中运行 MySQL 实例的服务器发生故障时，必须及时被监听到，然后使用其他正常服务器来替代故障服务器。UMP 系统借助于 ZooKeeper 实现对所有 MySQL 实例的监控。每个 MySQL 实例在启动时都会在 ZooKeeper 上创建一个临时类型的目录节点，当某个 MySQL 实例挂掉时，这个临时类型的目录节点也随之被删除，后台监听进程可以捕获到这种变化，从而知道这个 MySQL 实例不再可用。
（四）LVS
Linux 虚拟服务器（Linux Virtual Server，LVS），是一个虚拟的服务器集群系统。LVS 采用 IP 负载均衡技术和基于内容的请求分发技术。调度器是 LVS 集群系统的唯一入口点。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无须修改客户端和服务器端的程序。UMP 系统借助于 LVS 来实现集群内部的负载均衡。
（五）Controller 服务器
Controller 服务器向 UMP 集群提供各种管理服务，实现集群成员管理、元数据存储、MySQL 实例管理、故障恢复、备份、迁移、扩容等功能。Controller 服务器上运行了一组 Mnesia 分布式数据库服务，其中存储了各种系统元数据，主要包括集群成员、用户的配置和状态信息，以及用户名与后端 MySQL 实例地址的映射关系（或称为"路由表"）等。当其他服务器组件需要获取用户数据时，可以向 Controller 服务器发送获取数据请求。为了避免单点故障，保证系统的高可用性，UMP 系统中部署了多台 Controller 服务器，然后由 ZooKeeper 的分布式锁功能来帮助选出一个"总管"，负责各种系统任务的调度和监控。
（六）Web 控制台
Web 控制台向用户提供系统管理页面。
（七）Proxy 服务器
Proxy 服务器向用户提供访问 MySQL 数据库的服务。它完全实现了 MySQL 协议，用户可以使用已有的 MySQL 客户端连接到 Proxy 服务器，Proxy 服务器通过用户名获取用户的认证信息、资源配额的限制，如 QPS、IOPS、最大连接数等，以及后台 MySQL 实例的地址，然后用户的 SQL 查询请求会被转发到相应的 MySQL 实例上。除了数据路由的基本功能外，Proxy 服务器中还实现了很多重要的功能，主要包括屏蔽 MySQL 实例故障、读写分离、分库分表、资源隔离、记录用户访问日志等。
（八）Agent 服务器
Agent 服务器部署在运行 MySQL 进程的机器上，用来管理每台物理机上的 MySQL 实例，执行主从切换、创建、删除、备份、迁移等操作，同时还负责收集和分析 MySQL 进程的统计信息、慢查询日志（Slow Query Log）和 bin-log。
（九）日志分析服务器
日志分析服务器存储和分析 Proxy 服务器传入的用户访问日志，并支持实时查询一段时间内的慢日志和统计报表。
（十）信息统计服务器
信息统计服务器定期对采集到的用户的连接数、QPS 数值以及 MySQL 实例的进程状态用 RRDtool 进行统计，可以在 Web 页面上可视化展示统计结果，也可以把统计结果作为今后实现弹性的资源分配和自动化的 MySQL 实例迁移的依据。
（十一）愚公系统
愚公系统是一个进行增量复制的工具，它结合了全量复制和 bin-log 分析，可以实现在不停机的情况下动态扩容、缩容和迁移。
三、UMP 系统功能
UMP 系统构建在一个大的集群之上，通过多个组件的协同作业，整个系统实现了对用户透明的容灾、读写分离、分库分表、资源管理、资源调度、资源隔离和数据安全等功能。
（一）容灾
云数据库必须向用户提供一直可用的数据库连接，当 MySQL 实例发生故障时，系统必须自动执行故障恢复，所有故障处理过程对于用户而言是透明的，用户不会感知到后台发生的一切。
为了实现容灾，UMP 系统会为每个用户创建两个 MySQL 实例，一个是主库，一个是从库，而且这两个 MySQL 实例之间互相把对方设置为备份机，任意一个 MySQL 实例上面发生的更新都会复制到对方。同时，Proxy 服务器可以保证只向主库写入数据。
主库和从库的状态是由 ZooKeeper 负责维护的，ZooKeeper 可以实时监听各个 MySQL 实例的状态，一旦主库死机，ZooKeeper 可以立即感知到，并通知 Controller 服务器。Controller 服务器会启动主从切换操作，在路由表中修改用户名与后端 MySQL 实例地址的映射关系，并把主库标记为不可用，同时，借助于消息队列中间件 RabbitMQ 通知所有 Proxy 服务器修改用户名与后端 MySQL 实例地址的映射关系。通过这一系列操作后，主从切换完成，用户名就会被赋予一个新的可以正常使用的 MySQL 实例，而这一切对于用户自己而言是完全透明的。
死机后的主库在进行恢复处理后需要再次上线。在主库死机和故障恢复期间，从库可能已经发生过多次更新。因此，在主库恢复时，会把从库中的这些更新都复制给自己，当主库的数据库状态快要达到和从库一致的状态时，Controller 服务器就会命令从库停止更新，进入不可写状态，禁止用户写入数据，这个时候用户可能感受到短时间的"不可写"。等到主库更新到和从库完全一致的状态时，Controller 服务器就会发起主从切换操作，并在路由表中把主库标记为可用状态，然后通知 Proxy 服务器把写操作切回主库上，用户写操作可以继续执行，再把从库修改为可写状态。
（二）读写分离
由于每个用户都有两个 MySQL 实例，即主库和从库，因此 UMP 系统可以充分利用主从库实现用户读写操作的分离，实现负载均衡。UMP 系统实现了对于用户透明的读写分离功能，当整个功能被开启时，负责向用户提供访问 MySQL 数据库服务的 Proxy 服务器，就会对用户发起的 SQL 语句进行解析。如果该 SQL 语句属于写操作，就直接发送到主库；如果该 SQL 语句属于读操作，就会被均衡地发送到主库和从库上执行。但是，有一种情况可能发生，那就是，用户刚刚写入数据到主库，数据还没有被复制到从库之前，用户就去从库读这个数据，导致用户要么读不到数据，要么读到数据的旧版本。为了避免这种情况的发生，UMP 系统在每次用户写操作发生后都会开启一个计时器，如果用户在计时器开启的 300 ms 内读数据，不管是读刚写入的这些数据还是其他数据，都会被强行分发到主库上去执行读操作。当然，在实际应用中，UMP 系统允许修改 300 ms 这个设定值，但是一般而言，300 ms 已经可以保证数据在写入主库后被复制到从库中。
（三）分库分表
UMP 支持对用户透明的分库分表（Shard / Horizontal Partition），但是用户在创建账号的时候需要指定类型为多实例，并且设置实例的个数，系统会根据用户设置来创建多组 MySQL 实例。除此以外，用户还需要自己设定分库分表规则，如需要确定分区字段，也就是确定根据哪个字段进行分库分表，还要确定分区字段里的值如何映射到不同的 MySQL 实例上。
当采用分库分表时，系统处理用户查询的过程如下：首先，Proxy 服务器解析用户 SQL 语句，提取重写和分发 SQL 语句所需要的信息；其次，对 SQL 语句进行重写，得到多个针对相应 MySQL 实例的子语句，然后把子语句分发到对应的 MySQL 实例上执行；最后，接收来自各个 MySQL 实例的 SQL 语句执行结果，合并得到最终结果。
（四）资源管理
UMP 系统采用资源池机制来管理数据库服务器上的 CPU、内存、磁盘等计算资源，所有的计算资源都放在资源池内进行统一分配，资源池是为 MySQL 实例分配资源的基本单位。整个集群中的所有服务器会根据其机型、所在机房等因素被划分为多个资源池，每台服务器会被加入相应的资源池。对于每个具体的 MySQL 实例，管理员会根据应用部署在哪些机房、需要哪些计算资源等因素，为该 MySQL 实例具体指定主库和从库所在的资源池，然后系统的实例管理服务会本着"负载均衡"的原则，从资源池中选择负载较轻的服务器来创建 MySQL 实例。在资源池划分的基础上，UMP 系统还在每台服务器内部采用 Cgroup 将资源进一步地细化，从而限制每个进程组使用资源的上限，同时保证进程组之间相互隔离。
（五）资源调度
UMP 系统中有 3 种规模的用户，分别是数据量和流量比较小的用户、中等规模用户，以及需要分库分表的用户。多个小规模用户可以共享同一个 MySQL 实例。对于中等规模的用户，每个用户独占一个 MySQL 实例，用户可以根据自己的需求来调整内存空间和磁盘空间，如果用户需要更多的资源，就可以迁移到资源有空闲或者具有更高配置的服务器上。对于分库分表的用户，会占有多个独立的 MySQL 实例，这些实例既可以共存在同一台物理机上，也可以每个实例独占一台物理机。
UMP 系统通过 MySQL 实例的迁移来实现资源调度。借助于阿里巴巴中间件团队开发的愚公系统，UMP 系统可以实现在不停机的情况下动态扩容、缩容和迁移。
（六）资源隔离
当多个用户共享同一个 MySQL 实例或者多个 MySQL 实例共存在同一台物理机上时，为了保护用户应用和数据的安全，必须实现资源隔离，否则，某个用户过多消耗系统资源会严重影响到其他用户的操作性能。UMP 系统采用表1所示的两种资源隔离方式。
表1 UMP系统采用的两种资源隔离方式
| 资源隔离方式 | 应用场合 | 实现方式 |
|---|---|---|
| 用Cgroup限制MySQL进程资源 | 适用于多个 MySQL 实例共享同一台物理机的情况 | 可以对用户的 MySQL 进程最大可以使用的CPU 使用率、内存和 IOPS 等进行限制 |
| 在Proxy服务器端限制QPS | 适用于多个用户共享同一个MySQL实例的情况 | Controller服务器监测用户的MySQL实例的资源消耗情况，如果明显超出配额，就通知Proxy服务器通过增加延迟的方法去限制用户的QPS，以减少用户对系统资源的消耗 |
（七）数据安全
数据安全是让用户放心使用云数据库产品的关键，尤其是企业用户，数据库中存放了很多业务数据，有些属于商业机密，一旦泄露，就会给企业造成损失。UMP 系统设计了多种机制来保证数据安全。
（1）SSL 数据库连接。安全套接字协议（Secure Sockets Layer，SSL）是为网络通信提供安全及数据完整性的一种安全协议，它在传输层对网络连接进行加密。Proxy 服务器实现了完整的 MySQL 客户端/服务器协议，可以与客户端之间建立 SSL 数据库连接。
（2）数据访问 IP 白名单。UMP 系统可以把允许访问云数据库的 IP 地址放入"白名单"，只有白名单内的 IP 地址才能访问云数据库，其他 IP 地址的访问都会被拒绝，进一步保证账户安全。
（3）记录用户操作日志。用户的所有操作都会被记录到日志分析服务器，通过检查用户操作记录，可以发现隐藏的安全漏洞。
（4）SQL 拦截。Proxy 服务器可以根据要求拦截多种类型的 SQL 语句，比如全表扫描语句"select *"。
小结
UMP 是阿里巴巴开发的 MySQL 云数据库方案，采用 Erlang 实现，遵循单一入口、高可用、可伸缩、资源弹性隔离四大原则。系统核心组件包括 Controller（管理集群与元数据）、Proxy（协议解析与路由）、Agent（管理实例）、日志与信息统计服务器、愚公系统（动态迁移），并依赖 Mnesia（分布式DB）、RabbitMQ（消息）、ZooKeeper（配置与锁）、LVS（负载均衡）。UMP 通过资源池与 Cgroup 实现资源虚拟化与隔离，支持主从热备、读写分离、分库分表、动态扩缩容。安全方面采用 SSL、IP 白名单、操作日志、SQL 拦截。容灾由 ZooKeeper 监控故障、Controller 切换路由实现透明恢复。读写分离通过写后 300ms 强制读主库避免不一致。
欢迎 点赞👍 | 收藏⭐ | 评论✍ | 关注🤗
