摘要：3月10日，2017阿里云网站行业热点问题和解决方案线下研讨会在上海举行。在本次研讨会上，阿里云数据库团队产品专家王义成（花名挚尤）针对于大型网站的数据库架构设计以及阿里云ApsaraDB所提供的服务管理和解决方案进行了深入介绍。

分享者简介：王义成（花名挚尤），阿里云数据库团队产品专家，负责阿里云NoSQL数据库的产品规划。加入阿里巴巴近5年的时间，参与过多种云数据库的产品设计工作。目前主要负责阿里云的MongoDB、Redis以及MemCache产品，旨在为广大客户提供安全可靠的数据库解决方案。

以下内容根据演讲视频以及PPT整理而成。

最近一年整个数据库行业可以说是风生水起，同时也发生了包括MongoDB黑天事件以及最近的GitLab删库误操作事件在内的很多事件，这些事件导致了各自的业务都遭受了巨大损失。而很有意思的一件事情就是在MongoDB黑天事件发生之后，使用阿里云MongoDB服务的实例数开始出现暴涨，这其实是因为大家都抱着亡羊补牢的心态，开始使用云数据库。

今天就为通过以下四个主题为大家简单剖析为什么做大型网站需要使用云数据库：
一、通用数据库架构
二、ApsaraDB.概要介绍
三、ApsaraDB.服务管理
四、ApsaraDB.解决方案

本次分享中首先会介绍大多数互联网行业的数据库通用架构设计、自建数据库的一些常见问题以及面对的困难，之后将介绍ApsaraDB基于什么样的考量为用户设计出了什么样的产品以及ApsaraDB所提供的服务管理能力，最后还将介绍ApsaraDB为阿里云整体提供了什么样的数据库解决方案。

一、通用数据库架构

1.电商高并发，高性能场景
在第一部分将介绍互联网企业中常用的五个场景。第一个场景就是电商高并发，高性能场景。在电商高并发的场景下，很多架构采用了MySQL，也有一些架构采用了PostgreSQL，并且目前大量的电商行业也开始使用MongoDB数据库。而且对于新兴的电商企业而言，由于数据相对比较灵活，所以基本上都会选择使用MongoDB构建线上应用，还有一部分电商使用Redis做持久化存储，将用户信息类的数据直接使用Redis存储到数据库中。
这类场景对于数据库的要求关键字就是高性能和数据安全。那么如何保证数据库具有较高的性能并且保障数据安全，并且电商的核心交易往往存储在MySQL数据库中，该如何从网络层面来保护数据安全，又如何防止SQL注入，这些问题都是应用DBA或者开发同学需要考虑的事情。如果使用自建的数据库时就需要考虑应该采用什么样的手段来保障数据库的高性能和安全，应该采用一主多从策略还是采用水平分区策略，这些问题都需要进行考虑。

2.金融：安全交易类场景

第二个场景就是安全交易金融类的场景。在金融类场景下，数据库往往需要支持海量的数据存储，可以从上图中看到，可以结合前面的分布式Proxy和后面MySQL以及MongoDB数据库实现分布式数据库的架构。目前MySQL和MongoDB数据库是可以实现分布式数据库设计的，包括阿里云的DRDS以及开源的TADL等都可以用于构建自己的数据库系统。而在自建数据库时就需要去考量如何进行数据库的横向扩展以及如何保证分布式数据库能够平稳地运行，并且保证网络安全和数据安全。除此之外，金融类场景中的一个核心要求就是保证业务高度可靠，当单节点无法满足需求时需要使用双机热备，而当使用双机热备的时候如何保证在主机宕机的情况下备机不会丢失数据、某一个机房挂掉之后业务能够瞬间恢复、缓存数据宕掉之后能够避免对于后台整体业务的冲击过大以及在缓存宕掉之后能够迅速地拉起等问题，都是在自建数据库时需要仔细考虑的，而这些也正是处理中的难点。

3.网站：高性价比场景
第三类场景针对的是比较通用的网站类，也就是要求高性价比的场景。在这个场景下的数据存储可能会使用到缓存层以及后台的数据库层，数据库可能会使用MySQL、PG或者MongoDB，在缓存部分可能会使用到Redis或MemCache。这个场景下对于缓存的要求就是成本足够低并且性能足够高，这些也是在自建数据库时需要保证的，而对于后台存储数据库而言，则要求具有较高的性价比。因此如果使用一主一备的策略可能无法满足高性价比的需求，所以需要使用读写分离以及一主多从的策略。虽然MySQL、PG以及MongoDB都提供了原生的一主多从的策略模式，但是如何处理这样的模式以及读写分离策略，都是需要应用程序开发人员以及DBA进行联合考量的，所以在自建数据库时就将会耗费大量的人力、物力和财力。

4.游戏：行业高可用场景
第四类场景是游戏类通用的数据库场景，该场景的核心特点就是ECS和数据库具有分服的概念，也就是在游戏中会分出多个区。所以对于游戏数据库而言，需要保证其高稳定并且防止对于数据的误操作。对于一些游戏产品而言，往往发展非常迅速，可能一到两周就会更新一个版本，如果开发和测试不完善就可能因为误操作导致数据错误。那么DBA如何保证在发生误操作时，能够瞬间恢复到误操作发生之前的时间节点的数据状态，这也是整体维护上的难点。而且在游戏行业往往需要秒开数据库，可能一天开多个区，会有大量用户进来，那么如何保证整体的前端服务、CDN以及底层的数据库在一两分钟之内就能够将业务全部开启，这也是对于数据库的一个考验。

5.通用：大数据分析
第五个场景是大数据分析场景，在这个场景下的底层可能是一个Hadoop集群在晚上换算各种数据，白天就能够将数据展示给老板看。比如整个网站的交易量数据都需要经过一夜的运算存储到前端的MySQL或者Redis数据库中，快速方便地供业务内部人员审核。在这个场景下，对于数据库要求就是需要一个能够将Hadoop中的数据一键式地导入到MySQL中的工具，还需要增加易用性，使得各个业务方都能够方便地查看数据，并且需要低成本地应用MySQL和MongoDB数据库来满足内部查询需求。所以在大数据分析场景下数据库的关键词就是易用，需要数据库服务能够提供数据通道，保证在异构的数据引擎之间进行数据快速传输，并满足数据库层面的低成本诉求。

以上就是互联网应用中的五种通用的数据库架构，总结而言自建数据库的难点就在于以下四个方面：
1.稳定性，首先就是宕机怎么办？如果搭建了一主一备的数据库策略，就需要保证主机宕机之后服务能够快速恢复起来，并且机房宕机之后也要保证服务能够快速起来。如果发生了地域的灾难性事件之后需要能够在一天或者几个小时之内迅速恢复服务，而如果数据量非常大时就难以保证数据库服务能够在一天之内恢复，这些都是自建数据库的难点。另外如果数据丢失了怎么办？可能业务是正常的，但是被黑客黑掉了，发生了像MongoDB黑天这样的事件或者被SQL注入攻击了，在这样的情况下业务如何才能快速地恢复起来，还有白名单策略是否足够好，以及在SQL注入将数据删除之后是否能够迅速恢复SQL注入之前的数据库状态，并且判断出是谁对发起的SQL注入或者攻击，这些都是在自建数据库时需要考虑的难点。除此之外，还需要保证发生误操作时数据库的稳定性，虽然MySQL有比较合理的权限管理机制，但是像新兴的MongoDB以及Redis等数据库对于权限管理的处理还是比较粗放的，而在权限管理不合理的情况下，如果触发了误操作将可能修改了整个数据库，此时DBA如何才能够快速地将数据恢复以及恢复后会丢失多少数据都是需要考量的难点。

2.扩展性，当业务快速发展的时候，数据库如何纵向地升级也需要在自建数据库时考虑。大家在ECS上可以自由调配资源，如果没有使用云服务而是使用的自建机房，当进行活动宣传时可能出现平时业务的十倍增长量，这使得数据库的压力也会急剧增加，纵向的数据库如何调度也将会成为难点。对于自建机房而言，服务器的采购周期也会很漫长，而搭建在ECS上就能够解决这个问题。但还存在一个问题就是数据库的纵向升级也是存在瓶颈的，即便是ECS也是有固定的配置，当单个ECS已经无法承担业务压力的时候，数据库又应该如何横向升级也需要在自建数据库时考虑。举个简单的例子，大家都知道Redis是单线程的，ECS配置再高也只能增加内存的数量，QPS的极限也就是十万，当业务迅速上来，纵向升级已经达到极限的时候，如何将Redis直接横向扩展为集群的实例，以及扩展成为集群之后如何进行维护，这些也都是DBA需要面对的巨大挑战。除此之外如何实现异构数据库之间的数据互通，如何将MySQL中的数据定向地导入到MongoDB或者Hadoop中，或者将Hadoop中的数据导入到MySQL中，这些都是需要耗费很多开发力量并且需要很多DBA的运维工作的。

3.安全性，如果能够预防SQL注入以及网络攻击，如何在遭受攻击的时候终止攻击，也就是在判断出这是一个SQL注入时，如何将其进行拦截也是在自建数据库时需要考虑的。还有如何亡羊补牢，在遭受攻击被脱库或者删库之后，在最短的时间内将数据找回并且将业务恢复起来，对于DBA而言也是难点。另外就是在遭受攻击之后，需要追查出攻击者到底是内鬼还是外部黑客，如果在管理比较混乱时，查出数据库是如何被删掉的以及到底是谁攻击的，都是自建数据库的难点所在。

4.优化和人力，SQL慢了该如何进行优化，在前期数据库管理时如果优化了数据库的性能就能够提升网站的整体性能。另外架构演练如何进行升级，比如从原本的只有MySQL的数据库架构演化成为前端+缓存并且使用更加合理的数据库的架构，这些都是优化中的难点。

其实除此之外，关系型数据库的DBA还是容易招募到的，但是招NoSQL领域的DBA还是相对比较困难的。那么在整体运维层面比较困难的情况下，如何最大地发挥数据库的价值就是阿里云推出的数据库服务的目标。围绕着在自建数据库中遇到的难点，就能够衬托出阿里云数据库产品的使命。

二、ApsaraDB.概要介绍
之前分享了在自建数据库中遇到的难点和需要解决的问题，接下来介绍一下阿里云的ApsaraDB数据库在做什么以及能够帮助用户解决什么样的问题。

飞天技术栈
下图是阿里云的飞天技术栈。最下层是阿里云的数据中心，其上层是阿里云的操作系统和文件系统，再上一层就是服务部署和资源调度，再上面一层就是任务系统、安全管理以及集群监控。在飞天技术栈最上面的这一层就是用户可见的云服务，这一层大致分为了七大板块：计算、存储、网络、数据库、内容分发、大数据以及中间件。目前阿里云数据库团队的产品有关系型数据库RDS、包括Redis、MongoDB、MemCached在内的NoSQL类的数据库以及金融类的数据库OceanBase、针对大数据的EMR和Greenplum以及自研集成了OLTP以及OLAP的数据库PetaData。

阿里云数据库-ApsaraDB产品家族
下图是阿里云数据库团队目前支持的几款产品，开源类的产品包括MySQL、PostgreSQL、MongoDB、Redis、MemCached、Greenplum以及Hadoop。而在商业化数据库体系里则支持SQL Server的2008和2012两个版本，以及PostgreSQL的高级版，可以兼容95%的Oracle协议的PPAS，其可以作为Oracle用户上云的临时替代方案，另外对于Oracle这部分，存在ApsaraDB的合作伙伴能够帮助用户去维护和构建云上Oracle，另外还有HAVA，也就是ApsaraDB的合作伙伴SAP上线的HANA1，在未来不久就可以在阿里云上售卖HANA的版本。

流量组件

下图是阿里云上的几个大的流量组件。
1.VPC+SLB，在安全性上，阿里云提供VPC + SLB的模式，这其中的SLB是购买RDS服务或者Redis、MongoDB自带，这个SLB其实是内部直接包在RDS中的，其主要帮助做四层的负载均衡。VPC的虚拟路由器和虚拟交换机保证在公有云之上该网络只有自己的专有网络内的用户能够连接，保障与其他网络用户的天然隔离，并且在整个数据库层面之前会绑定一层针对DDOS攻击的防御措施。

2.Proxy，Proxy也是阿里云数据库团队自研的组件，其主要作用是帮助用户实现七层的负载均衡。像分布式事务和读写分离这些都是在应用场景中帮助用户解决性价比问题的，当一个请求过来之后，可以直接通过Proxy判断该请求是读还是写，并根据策略分发到读或者写节点，不需要应用程序再进行解析和判断。SQL解析一方面就是将请求分析出来并且分配到相应的读或者写节点，另外就是及时地终止攻击，这个层面的SQL解析还处于研发阶段，未来希望通过SQL解析来判断请求中的语句是否存在SQL注入的嫌疑，如果用户选择让阿里云帮助进行判断，如果发现的确是SQL注入就会在应用程序上直接进行拦截，避免对于数据库造成灾难性的损失。还有一点就是连接保持，比如想要对于MySQL进行内核修复时，升级版本对于前端而言是非常痛苦的，应用程序就需要全部重连。而在主备进行切换或者主数据库进行内核升级的时候，如何保证业务不受影响，都需要依靠Proxy帮助进行连接的保持，而这则会免去对于运维干扰。

3.DB Engine，这里有多种数据复制方式保证RPO和RTO在相应的结合模式上进行处理，当对于数据可靠性要求比较高时，可能会选择双节点+半同步的模式；而当对RPO要求比较高时可能会选用异步复制的模式，这样就可以通过DB Engine来适配多种数据复制模式来解决不同用户的需求。另外DB Engine提供了插件式引擎，阿里云数据库团队提供了大的中台来支撑用户的服务能力，目前也已经实现了插件式引擎方式，比如在新建数据库时只需要一两个月的时间就可以实现产品的公测和商业化，能够快速地满足用户对于数据库的需求。除此之外还提供了源码级定制，数据库团队在开源领域吸收了中国顶尖的内核级开发人员来维护源码级的版本，目前使用的MySQL版本也都是去年开源的AliSQL的版本，其相比于原生MySQL内核性能提升了70%，而像MongoDB和Redis也都能够从内核层面帮助用户解决性能问题。

4.HA，用户使用数据库一个核心的需求就是稳定，而稳定性需要强大的HA系统来支撑。阿里云数据库团队的HA能够帮助用户进行健康检查、流量切换以及SLA计算。原生的流量切换只会检测程序的安全性，当内存hang住或者IO出现问题时，原生无法切换过来，而阿里云的HA策略是尝试真实地写磁盘IO，保证在受到影响之后HA都可以切换过来。

流量路径
下图是数据库架构的流量路径，这里介绍了用户购买阿里云数据库服务之后的数据流向。下图存在双节点，其实双节点的设计也会存在问题，比如某一机房断电或者网络出现故障，数据中心也就会瘫痪了，而阿里云的MySQL和Redis都提供了跨可用区的复制，也就是数据库实例存在多个可用区，当一个可用区出现故障之后可以直接将流量切换到备用机房，保障业务不受影响。下图展现的大致流程就是流量到来之后，数据将通过Proxy路由到DB Engine层，DB Engine层通过阿里云内网专线将数据复制到远端的跨可用区的数据库节点上，也就是如下图所示的左边是主节点，右边是备用节点，只不过备用节点平时不会承担流量，数据正常进行复制。如果发现主节点宕机之后就可以直接将流量全部一键切换到备用节点上，免除了用户自己维护稳定性的困难，也同时保障了服务的高可用。

连接优化
下图展现的则是Proxy的连接保持优势，其实在数据库层面往往需要两个节点，对于大型的云服务而言，某一台主机坏掉是很正常的情况，那么在宕机或者在数据库内核更新时如何才能不影响用户业务，其实背后都是依靠Proxy体系支撑的。内部的SLB直接连到为用户提供的Proxy上，Proxy连接DB Engine，当主机需要升级或者宕机的时候，可以把主机的链接断掉，直接将Proxy连接到备用节点，而在恢复时连接其实并没有断掉，在切换时可能会有一两秒的卡顿，但是对于却免去了业务重连的处理。总之，整个云服务就可以依靠Proxy实现连接保持。

复制方式
目前阿里云数据库服务一共提供了以下四种复制方式：

• RPO + RTO模式，该模式实现了瞬间恢复以及恢复后能够找到时间点，在默认的双节点情况下进行半同步复制，也就是数据必须要到达备端之后才能返回，所以当主节点宕机之后，备节点能够快速地运行起来，但是这样性能就会有相应的损耗，因为需要将数据传输到备端，如果选用了双可用区本身还会有3到5毫秒的延迟。
• RTO + Performance模式，这个模式下能够保证在数据宕机之后能够快速起来，这对于RTO不是很高的要求，可能起来之后数据会丢失一些，但是要求性能足够高，这种模式使用双节点 + 异步复制。
• RPO + Performance模式，这种模式下数据宕掉之后可能恢复时间会长一些，可能需要1到5分钟，但其RPO是没有问题的，其底层使用了共享存储并且性能足够高，并且使用的是单节点。
• RPO + RTO + Performance模式，它使用了多节点、强同步复制以及最终一致性，目前MongoDB的三节点都是复用的这种模式。

三、ApsaraDB.服务管理
之前概要性地介绍了ApsaraDB，接下来从服务管理层面为大家介绍与自建数据库相比，ApsaraDB的优势所在。
首先，对于服务可用性而言，阿里云的数据库提供主备架构、同城容灾和异地容灾模式，可以在半天之内将流量切换到备节点，并且不影响业务，还支持直接在控制台上点击主备切换来演习故障发生时的情况。如果自建数据库，则需要在自己的ECS上去考虑如何处理服务可用性以及在宕机时如何进行切流量的问题。

对于数据可靠性而言，阿里云提供的数据库通过本地RAID5实现了在线存储冗余，而ECS采用的是高效云盘 + SSD云盘，所以在本地存储方面两种方案是差不多的。在离线长效备份方面，阿里云ApsaraDB支持一键式将文件存储到OSS上并且可以存储延长至两年，而ECS自建数据库时则需要自己写OSS脚本来上传数据。第三方面就是按时间点恢复，就是当出现开发的误操作或者删除了一个表格之后，需要将数据恢复到误操作前一秒的状态，其实ApsaraDB支持将增量日志和AOF日志等全部存储到OSS上。在控制台发起操作之后，后台就会将备份文件以及增量日志在一个新的时序上恢复起来，数据就能够直接回滚回来。在数据复制方面，ApsaraDB支持异步 + 半复制的方式，则使用ECS自建数据库则需要自己进行配置。

在数据安全性部分，目前ApsaraDB支持白名单分组，而ECS则是支持安全组，在未来四、五月份的时候数据库团队就会将白名单分组取消，并将其和ECS安全组融合起来，解决目前客户在使用时的体验较差的问题。在审计日志方面，ApsaraDB会依靠内部的系统将SQL的审计日志收集起来并且存储到远端的存储中，用户可以定期地将SQL审计日志拉到本地进行查看，而且这个系统对于整体的性能损耗并不大，但是可以实现有踪可查，当发生问题的时候，就可以知道到底是谁发动了攻击，以及时间点、所使用的IP以及进行的操作。在网络加密和存储加密方面，阿里云数据库也处于比较领先的位置，ApsaraDB经过数据库的的等级认证，目前已经支持了SSL网络加密以及TDE存储加密。如果选择了TDE存储加密，即使数据被拖走对方在没有密匙的情况下也无法解析自己的数据，这部分在金融行业里也是要求非常严格的。

在监控与报警部分，阿里云数据库支持资源类的监控，也就是对于实例的CPU、内存、磁盘等的资源进行监控，还有就是引擎层面的监控，对于MySQL、Redis以及MongoDB等引擎层面的监控。在数据库引擎层面存在很多可以监控的指标，这些都可以通过图形化的方式展现给用户。在秒级监控部分，ApsaraDB支持300s和60s的监控模式，后续还可能对于像缓存等业务实现更细的粒度。并且ApsaraDB支持云监控的报警，对于数据库的监控指标而言，当发现这些指标出现异常时可以通过云监控直接向运维人员的手机或者邮箱发送报警信息。

在参数管理部分，ApsaraDB可以在数据库运维层面为用户提供参数模板和修改历史以及开销的分析。

在性能优化部分，阿里云数据库会为用户提供一套系统来帮助用户审查所有的SQL日志，并对于日志进行相应的去重分析来判断对于SQL应该加什么样的索引以及对于某张表应该如何处理给出相应的建议。

而一站式服务就是对于阿里云数据库整体的生态提供的工具。阿里云数据库提供了数据管理的工具，大家使用MySQL可能知道有Navicat等，在ECS上自建数据库时可以装上这样的工具，但是对于像MongoDB以及Redis这样的数据库，可视化的数据库管理工具却是很少的，现在的DMS可视化操作工具已经和阿里云数据库完全结合，可以支持SQLServer、PG、MySQL、MemCache、Redis以及MongoDB等所有的引擎，购买了阿里云的这些数据库之后就可以直接以图形化的方式进行管理了。而对于数据同步方面，对于如何轻松地将Hadoop中的数据同步到MongoDB中，或者对于两个同构的数据库如何进行数据同步以及如何实现增量同步的同时不影响业务而言，阿里云的整个数据同步工具是非常健全的，首先对于云上云下的同构的数据库同步来说，阿里云数据库都是支持全量 + 增量的，比如用户在ECS上有MySQL和MongoDB数据库，就可以直接选择DPS实现全量和增量的数据同步，目前对于异构数据库而言也是支持Oracle到PPAS的。数据同步这部分也是在迅速地发展，后续也会加更多的引擎进来，将会实现更多的数据库的异构同步来打通数据库的整体生态。

数据安全
下图展现了阿里云数据库可以从几个维度帮助用户构建事前、事中和事后的安全防范措施。在事前阿里云数据库会使用VPC专有网络形成隔离的网络环境，另外还会要求用户设置精细粒度的白名单，而且所有的数据库都是要求强密码认证的。在比如像MongoDB的黑天事件中，其实根源在于用户将自己的MongoDB的IP地址暴露于公网之上，直接导致黑客有了入侵的机会，所以阿里云对于NoSQL的数据库都需要强制用户设置强密码，并且不会暴露公网IP供外网调用，保证数据库处于一个相对比较安全的网络环境内。在事中还会使用SSL的网络加密以及TDE的数据加密。在事后的防范中还使用了一整套详细的审计日志，当真正发生了问题之后可以将审计日志调出来查看谁在什么时间点对于数据库进行了什么操作。除此之外，最后还有一套克隆实例保证数据库能够实现数据秒级恢复。

监控报警
下图介绍的是阿里云数据库的监控报警能力，目前阿里云RDS正在打造一套整体中台，也就是内部的“天象”的指挥端的系统，这个系统能够帮助用户将流量从ECS上直接打通到RDS上去的所有网络延迟监控下来并展现给用户，使得用户能够了解RDS或者MongoDB在一定时间内的压力负载究竟在哪，知道QPS反应比较慢的时候究竟卡在哪个链路上，到底是ECS出网口的问题、ECS到RDS链路的问题还是RDS引擎层面的问题，这些都会通过链路的监控图展示给用户。

性能优化
对于阿里云数据库的性能优化部分，可以分为如下图所示的资源分析、引擎分析、SQL分析以及专家系统这四大部分。

四、ApsaraDB.解决方案

异地容灾解决方案
第一个是在云上实现异地容灾的解决方案，比如在金融行业会需要考虑的一个可用区出现问题的场景下衍生出的服务就是异地容灾，可能数据库的主可用区在上海，而备可用区在深圳，当上海这个主可用区出现两个机房都瘫痪或者城市发生了电力故障不能提供服务的时候，都可以通过一定容灾模式保证服务的。而异地容灾的架构是需要所有的阿里云产品进行配合的，但其中最难做并且最重要的还是数据库。其实没有数据的部分是很好做容灾的，但是一旦涉及到数据就会很难实现。如上图中的解决方案所示，其支持的是两地四中心的概念，两个节点在不同的可用区之内，两个节点之间通过原生复制的方式实现数据同步，而自己搭建数据库时异地复制就会出现困难，如何保证数据能够追上并且RPO和PTO处于合理范围之内都是难点。

混合云解决方案
对于混合云的解决方案而言，其实实现混合云架构的难点还是在数据库，只要在有数据的地方实现多中心的同步都会比较困难。如上图的架构中左边所示就是如何将云下机房和云上机房进行数据互通和同步，而右边则是如何将阿里云上的数据同步到云下，这个场景都是真实存在于很多的金融场景中的，金融行业可能以云上作为备份、云下为主，还有一些新兴的金融行业因为其业务是依靠云发展起来的，而又因为需要合规所以需要将数据备份到云下，所以采用了云上做主、云下做备的方式。这套混合云解决方案还是依赖于整体的同步机制，云下到云上的的同步可以直接拽一个backup上去存储到对端之后，再通过增量数据将两部分数据一直挂同步和同载实现云上和云下的同步。而云上到云下的同步就是会将MySQL的Binlog或者MongoDB的OPlog直接开放权限给DTS服务，将数据通过通道传输到远端的自建数据库中，从而完成混合云的架构。

快速部署解决方案
上图展现的是一个快速部署的场景。快速恢复的功能支持整体的克隆实例，可以基于备份文件将数据整体克隆出来，并进行快速部署。而Flashback功能是阿里云数据库团队的彭立勋开发的，目前已经整合到MariaDB版本中并成为了其中核心的功能，这个功能主要就是抓起Binlog文件。因为平时做数据恢复时需要保证一个全量的备份，而Flashback的开发直接将Binlog的数据收集到里面，保证在很短的时间之内能够将数据恢复出来。对于Flashback功能感兴趣的同学可以到网上进行详细了解。

实时计算解决方案
最后的场景展现的实时计算的解决方案，目前很多业务都要求LTP和LAP两套机制。本身的一套数据库系统可能是实现LTP的，也就是正常的增删改查，还有一套系统需要将数据拉回来做LAP和分析，常规都是有一套LAP的数据库每天定时将LTP的数据直接同步到LAP中，而这个同步也是非常痛苦的。实时计算的解决方案希望在一套架构中为用户解决LAP和LTP的问题。阿里云的PetaData产品目前正处于邀测阶段，预期会在三月底进行商业化，PetaData能够通过一套存储机制帮助用户解决LAP和LTP的问题，大家有兴趣可以关注一下。