一、传统DB的瓶颈及问题

1.1、传统数据库的创建主要分以下几步：

1. 业务方&用户和DBA申请，并附上业务量和需要的资源等信息

2. DBA根据需求，选择相应的物理资源，并安装数据库

3. DBA交付数据库，并提供数据库连接信息如：IP、端口等

4. 业务方&用户初始化数据库，导入业务数据，然后找DBA建立访问指定库或者表的读写、只读等权限的连接账号

如下图：

可以看出几乎每一步都需要DBA的参与，在业务量小的情况下，并没有什么问题。但是当业务增量越来越大，每天有几十个甚至上百个数据库申请时，DBA的负担就会很大，而且影响业务上线速度。

1.2、数据库为什么要平台化

DBA每天都会遇到各个业务线的种种需求，每个业务线都会认为自己的需求重要，总会催DBA尽快完成。而DBA也是人，需要时间一个个的去完成这些需求。而这些需求其实90%以上都是重复性操作，很需要一个平台来把这些90%的重复任务用逻辑代码来实现，让用户或者DBA只需要点一点按钮就可以完成。

二、RDS发展

随着IaaS、PaaS平台的流行，数据库也从传统数据库服务逐渐转向了云平台数据库服务化，在私有云+公有云模式下，越来越多新技术力量革新产生了更多优质化的服务。RDS做为典型的在线数据库云服务，具有资源弹性伸缩，稳定性，易用性等特点。多重安全防护措施和完善的性能监控体系，并提供专业的数据库备份、恢复及优化方案，使企业用户能更加专注于应用开发和业务发展。为企业带来了成本核算上的收益，降低综合成本（硬件成本+管理成本）。

• 易用性

通过web方式管理数据库，能够短时间进行数据库的快速部署，将完整的数据库方案提供给用户的同时，解决繁杂的数据库维护成本，使得业务线能更高效的解决费时费力的重复性维护管理工作。

• 灵活性

RDS服务与用户自身搭建的数据库使用方式相同，对外IP+端口方式提供链接，能够与云服务内ECS、SLB、GCE等服务结合提供更好的服务。

• 水平扩展能力

RDS应对业务量大规模变化时，节点内能够快速进行硬件资源调整，节点间集群内也能快速的进行容量伸缩。有效的解决设备利用率偏低的问题，在不影响业务情况下进行动态迁移。

• 高可用性

RDS服务对外提供不同架构的可用性保障，在主业数据务节点失去响应能力的时候，能有相应的其他集群节点或从节点进行业务快速切换，防止因单点造成的业务损失。

• 云化

RDS服务是在原有传统关系型数据库服务发展的基础上，结合目前主流的云计算虚拟化等技术，将数据库管理实现成一键式、自动化、 资源池、在线集中管理等方式，减少很多繁杂管理操作，同时能够快速更加便捷的操作和使用数据库。

三、乐视RDS

3.1、诞生

3.1.1、为什么会有乐视RDS

在日常管理传统数据库的时候我们遇到了很多问题，比如：

• 乐视这几年快速发展的同时，业务对数据库的需求量也是越来越大，最开始的时候业务库还是人工或者人工+脚本的方式创建。业务紧急上线，数据库的搭建时间就是个瓶颈。

• 由于安全原因或者权限问题，用户需要紧急修改数据库账号密码，但由于联系不到DBA，不能及时修改，可能造成数据泄露、丢失。

• 用户想知道当前的数据库状态或者一些性能指标，而此时DBA在忙着处理线上问题，不能及时提供等等。

我们就开始思考，是不是需要作出一套乐视RDS，在业务方或者用户需要数据库资源的时候，只要登录平台轻轻一点数据库创建按钮，即刻使用。我们只提供基础的数据库服务平台，并负责其稳定性和可靠性。而用户有自己数据库大部分管理权限，让用户对数据库的操作脱离DBA，并且了解自己数据库的实时状态。这样既减轻了DBA的压力，又带来了更高的效率。

最终乐视RDS的雏形就建立了起来，乐视RDS基于docker虚拟化可以限制硬件层（CPU、内存、磁盘io）等资源，将同属于一个物理集群之间资源进行隔离。有效控制资源环境稳定性并提高资源利用率。

从2014年开始我们就尝试使用Docker容器技术，把容器作为RDS数据库集群各个节点运行的基础环境，这在国内可以说是比较早使用此种架构的互联网公司。

3.1.2、为什么会选用Docker技术

我们使用Docker主要的原因有：

• 开源程序，可定制开发

• 快速部署

• 灵活

• 丰富可定制的镜像资源

• 资源隔离

• 轻量，满足数据库运行环境即可，不会占用多余的系统资源

3.1.3、优势何在

对应云端的数据库来说，其实用户最想看到的就是，在申请完数据库后，立刻就能使用，并自主管理，而乐视RDS完全可以满足：

• 快速

• 稳定

• 可控

• SSD的加入，IO不再是数据库瓶颈

• 无需热备，所有节点都在激活状态，都为多主结构

• 应用可以从集群中任意节点进行读写

• 读写可水平扩展

• 可线上动态添加、删除数据节点

• 扩展，缩减数据节点对客户端透明

3.1.4、遇到的问题

在乐视RDS这几年的发展过程中，其实遇到了很多的困难和问题，下面大概说几点：

• 数据库的版本和架构选型

根据云平台的特性，我们最终选择了基于Percona Xtradb Cluster的数据库集群架构，并对其进行了一系列优化，使其在容器环境下更稳定的运行，我们内部命名为Mcluster。

• 数据库账号权限的管控

对数据库账号的管控很重要，我们严格控制数据库账号的权限，使之只能在指定的权限下，干相应的事。

• 数据库物理资源隔离限制

因为我们的数据库基于Docker技术，所以物理资源的隔离变得尤其重要，其中也遇到了很多问题。现在我们已经可以隔离包括CPU、内存、磁盘IO等物理资源

• 使用入门

能更好的把用户了解并熟练使用乐视RDS这其实是很难的一件事，因为内部用户的观念里还是认为数据库要DBA管理，不关他们什么事。

我们经常和用户进行交流，收集他们初次使用乐视RDS中遇到的各种问题，并完善我们的帮助中心和Web页面使用向导。

• 备份恢复

数据库备份重要性不言而喻，在硬件损坏、数据丢失、误删除等等的很多灾难性的时刻，如果做了充分的备份都可以保证数据的全量恢复，最大限度的挽救丢失的数据。

由于数据库集群的特性，数据是冗余三份或者更多的，备份功能我们也是经过了几个版本的迭代，正常业务每天都会有备份，在部分重要业务上可以开启实时备份功能。

• 全局数据库性能状态掌控

随着数据库的总量越来越大，对所有数据库性能的掌控变得尤其重要，为了实时了解数据库运行状态，我们定制了一系列的指标来完成此目的。

• 预警维度制定

预警维度的制定这个环节是我们最头痛的，由于前期定制的告警维度过于敏感，导致告警量很大，对于相关运维人员来说是个噩梦。

最终经过多次讨论，修改了很多不必要的预警维度，使现在的乐视RDS预警精确性大大提高。

经历了上面的种种问题和阻碍，乐视RDS终于横空出世。

3.2、发展和现有规模

3.2.1、乐视RDS主要发展大事记如下

乐视RDS现在主要还是给乐视集团内部各个子生态提供数据库服务，线上已经为900+的业务线提供数据库服务，3000+的容器规模，乐视RDS在集团内部数据库使用率已经达到60%以上。

3.2.2、RDS主要架构发展历史

RDS架构1.x：单实例多Database+LVS（ 起步 ）

RDS架构2.x：PXC+Docker+Gbalancer （ 发展 ）

RDS架构3.x：(PXC or PostgreSql or MariaDB or otherDB)+Docker+Gbalancer（多元化 ）

• 1.x主要是 起步 阶段，我们选择在每个物理机上安装单实例库，并在上面创建多个database，通过LVS进行负载，但使用中发现这种架构并不适合云平台的理念。

• 2.x主要是 发展 阶段，我们选择了PXC（Perconal Xtradb Cluster）数据库集群，运行在Docker上，并使用Gbalancer做数据库代理。

• 3.x主要是 多元化 阶段，经过前面两阶段大的架构演变，我们最终的目的是把平台当成插槽（既提供各种通用的接口）。不限于MySQL，任何数据库都可以插到平台上，进行创建、管理等一些列操作，为用户提供稳定、快捷、易维护的数据库服务。如下图：

3.2.3、乐视RDS为各个子生态提供数据库服务

乐视RDS现在已经为乐视各个子生态提供稳定、高效的数据库服务，并根据业务方使用中反馈的各种需求和问题，完善着乐视RDS。

3.3、乐视RDS整体构架图

乐视RDS整体架构主要分为以下几大部分：

1） Database层为具体的数据库业务，和MySQL选择存储引擎一样，Database层也秉承着可插拔特性。既可以是MySQL，也可以是PostgreSQL等任何数据库（我们现在使用的为MySQL）

2）    Matrix层负责前端数据库创建、管理、监控、维护和相关资源调度

3）    Data Analysis层主要负责数据库日志的分析还有用户行为分析

4）    BeeHive层负责组件服务的调度管理

3.4、乐视RDS基本使用示意图

• 业务用户：可以通过Matrix云平台对数据库，进行创建、扩容缩绒、权限配置、性能查看、用户资源管理等等的一系列操作。

• DBA&平台管理员：有更高的权限管理所有数据库集群，并可以根据收集过来的日志分析数据库性能、用户行为等等。

• 业务服务器：会通过本地安装的Gbalancer中间件，来访问相应的数据库。

• ES集群：会收集Mcluster日志数据、容器里的相关日志，以供进行业务分析。

• 物理资源池：根据Mcluster的配置需求，在物理资源池里获取相应的资源，而且当物理资源不足的时候，可以动态的添加物理服务器到物理资源池里，来扩充整个物理资源池。

3.5、弹性伸缩

乐视RDS的弹性伸缩是基于 “大资源池的概念” ，所有物理服务器资源在整体看来其实一个大资源池，数据库可以在这个池子里自由的扩容、缩容、迁移。

3.5.1、弹性伸缩的主要特点

扩容&缩容

乐视RDS可以随着业务的瞬时增长，在业务高峰时自动扩容（包括节点数量、CPU、内存、IOPS等），当度过业务高峰后，在闲时自动缩容，在保证业务稳定的同时最大限度的节省硬件资源。

平滑迁移

随着业务量的的线性增长一定阶段后，出现物理资源瓶颈，乐视RDS能在可以实现不停业务或者说用户无感知的情况下，平滑的迁移数据库到更高配的物理服务器上，同时保证业务的不间断性。

3.5.2、使用场景介绍

1）    三节点的数据库集群已经不能满足用户大量并发查询的需求，需要弹性添加数据库节点

2）    由于物理服务器损坏，需要把物理服务器上的数据库放到健康的服务器上

3）    单个业务量增长巨大，之前使用的数据库集群所在的物理机资源（比如：CPU、内存、磁盘IO等）已经不能满足业务的要求，此时乐视RDS可以实现不停业务或者说用户无感知的情况下，平滑的迁移数据库到更高配的物理服务器上。

3.6、数据库预警

数据库预警对于提供平台服务的我们来说，其实是很重要的一块，如何保证数据库出问题的时候，第一时间通知相关责任人解决故障，这是我们提供更好服务的关键。

目前主要使用云平台的RDS预警功能模块进行数据库预警：

3.6.1、普通级别告警

数据库集群未出现明显异常，也没有对业务造成影响，但已经超过了平台预设的最低稳定指标，比如：数据库读写超时、集群节点间同步数据延迟等等。通过短息、微信、邮件的方式通知相关责任人，提前分析原因，并进行相应的处理措施。保证在未出现问题之前，就已经及时发现并把问题解决。

3.6.2、严重级别告警

数据库集群已经出现了明显异常，而且对业务操作了一定的影响，比如：严重超时、数据库节点或整个集群故障等。通过电话、短息、微信、邮件所有通知途径，告知相关责任人，及时上线解决问题，尽可能的减少因为数据库问题对业务造成的损失。

3.7、数据库监控

监控系统在云平台RDS服务中处于举足轻重的地位，监控系统的好坏直接决定了，RDS服务出现问题之前预测性能瓶颈，是RDS服务提供稳定服务的有利保障。

监控系统我们已经完全实现平台化收集并查看，监控指标包括容器的各类性能指标、数据库各种性能指标、数据库集群各个节点间同步状态的监控等等。

下面大概介绍一下：

3.7.1、容器的性能监控

因为我们是基于容器运行数据库服务，所以容器的性能监控至关重要。通过安装在各个物理集群里的agent程序，收集相关数据到Matrix平台，收集的信息包括所有数据库容器的CPU、内存、磁盘IO、网络等等的使用情况，DBA会通过平台多种维度的展现，来及时发现出现性能瓶颈数据库容器，并优化相关数据库服务。

下面为Matrix平台展现的，某个物理集群中，读写消耗Top3的容器相关指标曲线图：

3.7.2、数据库性能监控

包括数据集群的TPS、QPS、Innodb相关资源使用情况监控等等。下面为平台的部分截图：

1)    数据库基本运行指标

2）数据库集群实际read行数情况统计

3.7.3、集群数据同步监控

根据数据库集群同步参数，来收集集群各个节点间的同步状态。下面为平台的部分截图：

3.8、Gbalancer数据库中间件

为了保证数据库的高可用性，虽然基于Percona Xtradb Cluster的Mcluster数据库集群架构可以接受多节点写，但是在我们的实际使用中发现其在大量并发写的情况下，会出现各种问题。

而在2014年的时候，大多数中间件不能满足我们的需求，最终我们决定自己开发一款符合我们要求的数据库集群中间件。

我们开发了一款内部命名为Gbalancer的数据库中间件产品，Gbalancer的主要特点是轻便、高效、部署简单，并且充分利用了Mcluster数据库集群特性。

通过和业务代码的配合，其可以实现数据库级别的高可用、负载、读写分离等功能。

Gbalancer的几种主要运行模式有：

1）    轮询访问模式：把数据请求轮询转发到后端Mcluster数据库集群的所有节点

2）    单节点访问模式：把数据请求只转发到数据库集群中的一个节点上，只有当前数据库节点有问题的时候，才会切换到另外一个数据库节点上

3）    隧道模式：通过和数据库节点建立持久隧道连接，所有数据连接都通过隧道来访问数据库（适用于短连接）

不同模式有各自的特点和业务使用场景。

在实际线上应用中，通过在本地业务服务器上安装Gbalancer，根据需求配置Gbalancer连接数据库的模式，并和业务代码相结合，最终可以实现数据库级别的高可用、负载、读写分离等功能。如下图：

注：Gbalancer目前已经开源，项目地址为 https://github.com/zhgwenming/gbalancer

3.9、日志收集和分析

由于RDS数据库集群的数量激增，我们最头痛的就是数据库集群批量报错、单个业务线出现大量的低效的SQL语句等问题的及时发现和后期的分析工作，这些问题虽然短时间内也许不会造成致命问题。但如果不及时发现问题进行处理，后期很可能是致命性的。

目前通过ES，我们把所有日志进行统一的存储、管理和分析。其中对于数据库来说，最主要的日志还是错误日志和慢查询日志。

我们把收集过来的MySQL（错误、慢查询）日志、容器日志按各个关键指标和维度进行划分，在Matrix云平台上以图表的形式展现出来，可以宏观的查看所有的日志信息，这样保证了：

1）    出现数据库集群报错的时候我们能捕获报错并查看其规模、分类和具体信息

2）    如果批量出现大量慢SQL时，我们也能按照时间、数量、来源IP等一些列维度，来发现有问题的SQL语句，并对相关业务方提供优化建议

3）    数据库容器报错后，能捕获并及时发现问题、解决问题，还可以供后期分析问题原因，防范再次出现

如下图：

3.10、踩过的坑

1）    在线修改大表，会对整个集群造成影响

2）    多节点写，产生大量死锁

3）    大批量DML，整个集群pause

4）    导致数据库集群间不同步的场景

5）    集群级别从库坏了后的自动切换

6）    创建表为MyISAM引擎后的数据恢复步骤

四、展望

乐视RDS发展到现在，已经逐渐趋于成熟，但还有很多功能需要完善，在今年我们会继续发力乐视RDS。使其在功能和稳定性方面更上一层楼，并在不久的将来和大家见面。

• VSDL（Virtual SQL Data Layer）构建

• 全球化分布式数据库

五、关于我们

Q&A

Q1：你们的RDS有用Zabbix进行集中监控管理吗

A1：我们监控中有zabbix进行监控，zabbix通过调用我们自行开发的接口监控数据库状态，进行数据库容器集群事实监控。

Q2：请问运维标准化怎么定义的，怎么实施的

A2：运维标准化的范畴还是挺大的，比如服务器标准化，IDC标准化，网络标准化，架构设计标准化，容器标准化等等。就不一一列举了，我们通过规范与宣讲，起到了一定的效果，但是随着乐视集团与云公司的发展，已经赶不上变化，只有平台化，将各种标准系统化管控起来，才能将我们的标准与想法一一实现。这也是现在业界的一个普遍共识。

Q3：运维自动化用的什么平台

A3：运维自动化我们使用的是自主开发的Matrix管理平台

Q4：怎么快速扩容，快速部署

A4：依赖于Docker的先天特性，我们通过部署在物理机上的beehive程序，来快速部署容器。而容器里的mcluster-manager来进行数据库集群的扩容。

Q5：发布系统怎么做的

A5：目前我们发布系统是自行研发的系统，根据集群容器级别进行升级，以python +saltstack方式实现快速容器集群组件升级。

Q6：filebeat在使用过程中是否遇到发送重复数据，或者说超时重发导致日志大量重复，是否遇到过？怎么解决的

A6：我们使用filebeat中，并未发现发送重复数据，超时的话会有，我们通过date插件来把时间锁定在实际的日志记录时间。

Q7：集群日志会不会出现时间差异

A7：如果不用date插件的话，会出现。我们现在用date插件来获取日志实际的记录时间，并录入ES集群，可以避免日志记录时间和ES存储时间的差异。

Q8：后端存储用的是什么 是开源的分布式存储吗

A8:目前我们根据不同的业务线有不同的存储方案，一般RDS这边采用的存储相对比较传统，SAS、SSD，备份盘采用Gluster分布式系统。

Q9：请问你们对不对log做解析，把字符串解析成对应的参数值。如果是用logstash做，是否遇到解析速率的瓶颈，如何优化的

A9：我们会对log进行解析的，只会截取取关键数据指标录入ES集群。logstash我们也有在使用，通过把数据放到MQ里，然后用多个logstash解析MQ里的日志数据，加快解析速度。

Q10：关于Gbalancer中第三种方式隧道，这个主要解决的什么问题？是基于什么应用场景产生的？比另外两种的优势在哪

A10：主要解决短连接过多消耗数据库资源，通过和数据库节点建立持久隧道连接，所有数据连接都通过隧道来访问数据库，进而减小对数据库服务器资源的消耗。另外两种轮询和单节点访问，是不会建立持久连接（除非所用的编程程序支持）

Q11：能否将踩过坑中的解决方案例如多节点写产生死锁问题解决方案介绍下

A11：我们通过在业务端安装gbalancer，用端口区分，分别使用gbalancer轮询和单节点模式。然后在业务代码里把读和写用不同的gbalancer代理端口来访问数据库。

Q12：你们使用docker是如何进行编排的

A12：matrix+beehive，matrix是编排器，beehive是容器管理系统。请参考我们上次分享的一篇文章： http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=403162298&idx=1&sn=e1ccd26c4bd5619d30ad11d90a0cbc20&scene=1&srcid=0408CPAdONg0R3njhuaBvK7k#rd

Q13：在写入数据之后进行集群间同步的时候，是最终一致性还是实时一致性？设计时时如何考虑的

A13：Mcluster底层采用的是开源Percona Xtradb Cluster 进行封装，PXC集群数据为强一致性，架构设计之初考虑到互联网应用读写比例，读较为大的情景。PXC多节点数据一致性的同时，多节点读也带来读性能的提高。

Q14：您好老师，请教一下，当数据库链接突然断掉，数据需要回滚的时候，这个时候集群是如何做的

A14：PXC集群特点，在每一次数据库会话连接时候，保证多节点一致性，数据库会话提交都需要在多节点进行验证，验证通过后才会提交执行。这里所提到的当数据库会话连接突然断掉的场景，应该属于应用于数据库连接没有进行commit确认操作，会进行回滚。

Q15：请教下您这边，刚才讲到了数据库集群的扩容，请问下扩容之后，新的库是否要全量复制所有数据？还是增量保存

A15：扩容是会读取共享磁盘上备份数据，在扩容节点进行恢复，然后选择压力最小的作为donor，进行增量恢复。根据场景不同也有可能做SST全量复制，进行动态扩容。