打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮
乐视：基于Docker的RDS，我们是这样做的
5427
2016-10-01 09:52
文章摘要：一、传统DB的瓶颈及问题
1.1、传统数据库的创建主要分以下几步：
业务方&用户和DBA申请，并附上业务量和需要的资源等信息
DBA根据需求，选择相应的物理资源，并安装数据库
DBA交付数据库，并提供数据库连接信息如：IP、端口等
业务方&用户初始化数据库，导入业务数据，然后找DBA建立访问指定库或者
一、传统DB的瓶颈及问题
1.1、传统数据库的创建主要分以下几步：
业务方&用户和DBA申请，并附上业务量和需要的资源等信息
DBA根据需求，选择相应的物理资源，并安装数据库
DBA交付数据库，并提供数据库连接信息如：IP、端口等
业务方&用户初始化数据库，导入业务数据，然后找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完全可以满足：
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连接数据库的模式，并和业务代码相结合，最终可以实现数据库级别的高可用、负载、读写分离等功能。如下图：
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）构建
全球化分布式数据库
来源：CSDN 作者：高强 & 张成强 发布于【高效运维】，
1.1、传统数据库的创建主要分以下几步：
业务方&用户和DBA申请，并附上业务量和需要的资源等信息
DBA根据需求，选择相应的物理资源，并安装数据库
DBA交付数据库，并提供数据库连接信息如：IP、端口等
业务方&用户初始化数据库，导入业务数据，然后找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连接数据库的模式，并和业务代码相结合，最终可以实现数据库级别的高可用、负载、读写分离等功能。如下图：
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）构建
全球化分布式数据库
来源：CSDN 作者：高强 & 张成强 发布于【高效运维】，
版权声明：
凡本网内容请注明来源：T媒体（http://www.cniteyes.com）”的所有原创作品，版权均属于易信视界（北京）信息科技有限公司所有，未经本网书面授权，不得转载、摘编或以其它方式使用上述作品。
本网书面授权使用作品的，应在授权范围内使用，并按双方协议注明作品来源。违反上述声明者，易信视界（北京）信息科技有限公司将追究其相关法律责任。
评论