演讲嘉宾简介：陈招尚（胜通），资深DBA岗位从业者，有着十三年数据库领域从业经验，目前负责阿里云数据库RDS、专属集群MyBase产品管理工作。重点参与和负责阿里集团去O、双十一数据库管理等工作，对中大型企业的数据库管理工作有很丰富的经验。
以下内容根据演讲视频以及PPT整理而成。
观看回放https://developer.aliyun.com/live/245325
更多课程请进入“数据库大讲堂”了解
https://developer.aliyun.com/topic/database/lives
本次分享主要围绕以下四个方面：
一、自建数据库需要考虑的问题
二、阿里巴巴内部数据库的部署历史
三、经验总结
四、云数据库专属集群
一、自建数据库需要考虑的问题
其实无论是在云上还是云下，尤其是云下都是自建数据库，在自建数据库过程中DBA需要考虑很多问题。如下图所示，是曾经受困扰居多的一些实例。
首先是数据库高可用问题，第二是提升数据库资源利用效率问题，在提升数据库资源利用效率问题的同时又需要去解决资源瓶颈方面的问题，当然作为DBA运维数据库还存在运维幸福感的问题，否则连夜工作会影响到健康及生活。随着公司的业务发展或是各方面的情况，公司还有节省成本的一大要求。
自建数据库时会遇到的主要困扰如下图所示。DBA基本的岗位要求是应该将数据库管理好，装成有却无。如果数据库产品没有问题并且每年为公司节省成本，从公司管理层来说这是DBA管理工作者的基本功。数据库能否正常如所料想的去运行，其实在实际中还会受到很多因素的影响，这些影响因素会导致数据库存在一些问题，这时大部分情况下DBA会被拉出来背锅，因为数据库是最先需要处理的情景且无法扩机器解决。另外DBA人数和研发人数的比例严重失衡，研发者有一百或二百人，但DBA在疲于支持业务的同时还要解决运维间的问题，这就导致了失衡。DBA如果在业务上支持的多一些那么运维上投入就会少一些，运维一旦变少就会疲于支持业务上的问题，所以这两者是相互制约的。
从这些角度来说自建数据库要考虑的问题还有很多的，在过去很长一段时间里为了解决这些问题阿里采用了很多方式。例如为了提升运维幸福感，在处理小业务时为防止夜晚出现挂掉的情况出现，就会采用延时处理机制进行处理，根据这些业务的特点其实不会存在大问题，但是这样操作会提升运维幸福感。
所以作为DBA要尽最大努力并且一定要尽职做好工作，否则就会背锅担责，类似高危职业。担任DBA如果遇上聚会或是旅游需要随身携带电脑，也是为了防止出问题可以及时解决。
二、阿里巴巴内部数据库的部署历史
下面从阿里巴巴内部数据库的部署历史来了解如何部署数据库。尤其是MySQL的出现，MySQL在十多年前的版本比较低，并且没有运用于大型系统中，所以MySQL的运用规模较小。
1.稳定性压倒一切
部署形态很简单，相对以前来说机器硬件能力在不停提升，所以当时是处在如下图的简单部署当中，将所有的主机电源全部部署在一台机器上。由于公司的业务高速发展，所以在后端运维岗位的投入包括ID的资本投入都是非常大的。
连接数问题：从DBA的角度来说要稳定性压倒一切的，就要选择合适的部署方式，例如一台机器部署三个实例，这三个实例同时提供服务，只要这台机器资源利用率够用就使用该种部署方式。这样的部署在以前的平时是没有问题的。但是曾经在双十一时遇到过由于业务压力突然上涨而出现问题。如果一条数据库的实例实际服务两百台应用服务区，在平时连接到数据库中只有五个链接，这时正常情况下这条实例只有一千个人连接，但是如果在高压的情况下例如双十一，应用服务器可能会默默的从两百台扩充到一千台，为了撑住压力链接数一般会设置到二十、四十，这时突然到数据库里的连接可能达到上万或是超过一万。这样系统面临的情况就是应用数据库本身和各个方面都没有异常，但是应用的响应时间非常高。在当时MySQL5.1版本下，如果MySQL链接数建的很高，在处理连接时会存在很大的问题，压力大对数据库的响应时间会很长。这是当时面临的第一个挑战，阿里花了很长时间才解决此问题。
主机宕机问题：第二个挑战，如图所示，如果一台主机挂掉三个实例会全部切到新机器上，这时会产生很大影响。因为三个实例都会发生切换，致使受力面积变得很大，最后导致业务受到非常大的影响，如果三个实例服务1/3的业务，那么这1/3的业务都会受到影响。这是第一个阶段，接下来即便要进入第二阶段也轻易不敢进入，不敢进入的原因是如果一台主机挂掉备用机器要百分百支撑起主机挂掉的情况，这里的主机挂掉是指主机的CPU突然损坏或者常见的硬盘损坏等场景，导致主机可能会整个挂掉，这时备用机器就要百分百支撑起来，所以两台机器的配置都是一样的。在成本方面，主实例所在的机器投入与备实例所在的机器投入是一样的。
2.成本优化
由于后来业务发展超快，硬件达到指数级的投入，这时公司会做出成本优化。作为DBA想到的方法如下图所示，实现主备交叉部署。
部分超卖：相对来说主实例可以用到更多资源，备实例使用的资源会较少些。如果主机是64核，例如两个64核却可以部出96核节点，这就实现了部分超卖，有赌运气的成分。例如左边主机挂掉就会全部切到右边的主机上，就会超过原来64核物理上CPU总数。这是第一个面临的问题。
读写分离：第二个问题，主备挂掉时如果仍想提升资源利用效率，就需要读写分离，将读的请求放在备机上，这样左侧的主机与右侧的主机都具有流量，使得利用率提高。同样此操作具有赌运气的成分，在大型大促时关掉主备自动HA切换，相信尖峰时刻机器不会挂掉，另外在业务上切了很多机器，这样影响相对较小。
3.兼顾成本与稳定性
兼顾成本与稳定性，将不同机器进行打散，这里引入现在仍使用的内部移山系统来资源调度，监控每台机器资源的利用效率，及时根据一些触发条件将实例进行资源挪腾，让整个实例利用水位保持在相对均衡的状态，这样使整体利用率得到很大提升。
另外应对突然主备切换，备机不具备承担组时是冷启动过程，需要有个预热的过程。如果流量很大时突然启动备库可能会出问题，这时就需要备库预热。另外关于读写分离的问题，需要考虑到读的流量。
整体来说根据主机资源利用率例如CPU、IO，来考虑整个集群的水位。
4.重要系统和非重要系统交叉部署
在之前讲解的模式下核心系统和非核心系统是分成两个集群来处理，也就是核心系统更加偏向稳定性保守部署，而非核心系统向成本优化角度部署。这时就会出现虽然知道哪个为核心系统或非核心系统，但是核心系统会突然有一天变为非核心系统。这时就存在很大问题，认定的核心业务系统却在非核心业务系统集群中，这样非核心系统会有资源争抢等问题。
另外阿里又增加了对核心系统在此种情况下可进行资源绑定模式，有效制止了资源被争抢的情况，也就是锁定资源，不被争抢。非重要系统也可以实现资源随时的弹性，如果今天做活动流量会涨上来，那么就可以根据资源的利用效率将这台机器其他资源移走，这样会实现资源利用效率整体平衡。
三、经验总结
根据之前所讲解的内容，总结出以下四条经验。
经验1：主备交叉部署，一种伪超配的降成本方案
如图所示，一台机器用到96核，但是主机实际上是64核，由于主备交叉部署利用效率并没有达到满负载利用效率。
收益：
- 有利于CPU资源有效利用提高，整体上达到70%的- - 利用效率。
- 有利于连接资源达到有效利用效率。
相对来说成本更低。
注意点：
- HA机制需要做好，如果图中左侧主机挂着，什么时候需要切，或者前面提到尖峰时刻的时间点甚至可以直接关闭HA，这是之前应对高流量的预案。
- 主机问题监控，例如CPU、磁盘，图中所示两台机器为一对，如果有128台机器就有64对，一定要将核心资源进行充分打散。例如在双十一时在后端资源保障上都会将资源打散。
- 千万不要让主机实行满负载运行，这点非常重要，如果在满负载运行的状态下挂掉，则会出现雪崩情况，因为切过去另外一台也可能会挂掉。
经验2：应用分级，保障粒度差异化
一定要做应用分级，不同分级保障不同粒度差异化。
主要针对一般业务或是重要业务。一般业务可以利用主备交叉部署方式获得更多的资源利用，重要业务则要使用更偏向稳定性的方案，不会使用主备交叉部署运行。另外重要业务一定要有对外SLA保障，因为很多一般业务会依赖重要业务。运用应用分级不仅可以提升整体利用效率同时也提高可用性。
两种不同等级业务的数据库资源模式：
当两种不同等级业务的数据库资源进行模式部署时，MySQL实际上是吃内存性的，如果分了64G内存MySQL基本上会将64G内存全部用完，所以做不到超卖内存。
内存隔离，隔离过后在一台机器上不会出现抢占内存的情况。如果是稍微重要的业务，例如在非重要的集群中业务突然变得重要，这时需要绑定CPU集群实行CPU隔离，就不会被争抢。如果是核心业务就需要将其独立出来，进行物理机层面的隔离。
经验3：两种抽象的资源部署方案
无论是部署数据库还是部署应用，做资源调度对资源最底层的分配方式仅为两种：
- 均衡分配：如下图右侧所示，离散型数据库实例分布，会优先在更空的机器上分配实例，这样资源的利用效率会相对较为均衡，整体性会更稳定。此类方式比较偏向于核心性的业务。
- 紧凑分配：或者队列分配，先将两个机器全部分配完，再分配后面的两台机器，优先在更满的机器上分配资源，这时更关注成本，资源利用率会更高，但各个主机性能会表现不一。
紧凑型和均衡性交叉典型应用场景：
如果一开始是紧凑型分配则更关注成本，在大促时增加机器变成均衡分配实现资源均衡调度，大促过后要返回成紧凑型分配，这时会有机器空出来就可以拿到其他地方利用。实例挪腾可以自动化也可手动进行挪腾。以上为应对大促和平时所采用的方案，平时时更紧凑资源利用率更高成本更低，大促时更均衡稳定性更高。大促过后再将机器替换掉。
经验4：两资源弹性，消除业务流量评估焦虑
讲师作为DBA做了很多年开发支持的工作，也会遇到业务流量评估焦虑。
如下图所示，业务方在做新业务时心目中的数据库地位都是同等重要的，因为这项业务是业务方的全部，所以业务方会要求DBA重保所以数据库的内容，从业务方的角度来看每一个数据库都是很重要的。但是其实公司会有创新型或是实验型的业务，在实际运行一段时间后业务一定会出现其中某些业务才是真正的核心业务（如图中红色图形），而其他业务相对来说不会那么高，或者有些业务在运行一段时间以后下线了。所以从DBA角度来看实际表现中的数据库地位是具有差异性的方式，DBA在内部有专门处理混合型的集群，对于混合型的集群DBA不需要评估业务流量，只需放入该集群中就可以。如果某个业务突然上涨集群可以迅速锁定业务CPU不会被争抢，这样在一段时间内可以保证其地位，如果业务持续上涨，就需移动到专供集群中，在此过程中就保证了业务的重要性、稳定性和可用性。同时大大降低因为没有评估好而被指责的概率，例如一开始的业务指标可能是到1000万UV，或许实际只到10万UV（不排除真的到1000万UV），如果DBA按照100万UV出评估结果，那么评估就会出错，所以采用混合型的集群方法就能降低出错概率。
四、云数据库专属集群
在了解完阿里巴巴数据库的部署实践及累积的经验分享后，下面来学习一下阿里在云上推出的专属集群形态。
1.云数据库专属集群 -- 部署架构图
专属集群形态与普通PAAS集群形态的区别：普通PAAS集群形态购买的都是实例，而专属集群购买的则是主机，这样可以自己构建一整套集群模式并管理业务。
专属集群形态相对于普通PAAS集群形态的好处：专属集群可以做超配并自行管理，可以实现主备交叉部署的资源利用，可以实现在不同机器之间资源的调度、资源的再均衡、资源的迅速弹伸和收缩等方面的能力都提供在专属集群中。
以上为云数据库专属集群产品的简单介绍。总的来说，专属集群首先是云上专属数据中心，其次DBA可自主可控，最后根据不同业务实现成本最优化，提供最省成本的方案。
2.云数据库专属集群 -- 能力建设进展
目前专属集群能力建设基本都是支持的，除了混合部署还在研发当中，其他都已实现支持。
原数据库的PAAS服务拥有的功能，云专属集群全部都有，例如高可用、高可靠、高性能等。此外。还可以做资源的调度，关于本节课前面所分享的堆叠型、紧凑型、均衡型，通过移山进行资源均衡，资源的弹性伸缩等能力都在专属集群中提供。因为专属集群是以一个集群主机的形式来管理数据库资源，而不是像PAAS是以实例的形式管理。这款产品与本次课程讲解的主机具有一定关联，所以给大家进行了介绍。
扫码进群答题互动环节：
感兴趣的用户可以扫码进群讨论下面两道问题：
问题1:（多选）如果主实例都在同一个主机上，我们曾经遇到的问题有哪些？
问题2：（单选）一般抽象而言，有几种资源部署方案？
