随着互联网快速发展，我们的结构化关系数据库在高并发、海量数据的情况下面临单机扩展性问题，首先是单机数据库容量瓶颈，单机数据库在业务高速增长的情况下依赖硬件升级也会到达天花板，并且使用成本变得非常高，而且扩展性的复杂性也是比较高，传统数据库扩容往往意味着服务中断，很难做到业务无感知或者少感知。     通过数据水平切换来现实分库可以帮助提升数据库整体性能、横向扩展性，切分后有效的降低了单台机器的访问负载，同时最大限度的降低了数据库服务节点宕机后的损失。      传统应用业务层逻辑或组件分库实现方式                                 应用和数据库按业务地域水平拆分                                        应用JDBC驱动层组件封装实现水平拆分   传统模式的分库我们看以看到有把系统应用及数据库按业务属性（比如城市、区域、类型等）水平拆分为多个独立分系统，通过在接入层做路由；另外就是在应用通过封装JDBC Driver组件来实现访问分库，类似于通过MySQL的JDBC驱动访问MySQL。传统模式的分库方式虽然使用简单实用容易上手，但是版本难以控制/问题难以追踪排除，并且DB连接仍然和传统数据库一样无法收敛。   阿里云DRDS+RDS分布式数据库功能及优势 基于阿里云DRDS+RDS实现的分布式数据库数据读写存储集群化，不受单机限制，业务使用的连接数也无限制，DRDS中间件服务节点及后端RDS存储服务点都可以支持横向和纵向升级扩展，支持多种拆分模式规则，实现数据水平拆分；兼容 MySQL 协议和大部分 MySQL SQL 语法，无业务侵入式使用读写分离，提供全面的运维和监控能力:      分库分表:支持 RDS/MySQL 的分库分表，在创建分布式数据库后，只需选择拆分键，DRDS 就可以按照拆分键生成拆分规则，实现数据水平拆分。透明读写分离:通过使用 RDS 只读实例或者 MySQL 备机实现读写分离，帮助应用解决事务、只读实例或者备机挂掉、指定主备访问等细节问题，对应用无侵入，在 DRDS 控制台即可完成读写分离相关操作。数据存储平滑扩容:当出现数据存储容量和访问量瓶颈时，DRDS 支持在线存储容量扩展，扩容无需应用改造，扩容进度支持可视化跟踪服务升降配:DRDS 实例可以通过改变资源数量实现服务能力的弹性扩展。分布式运维指令集:DRDS 提供独有分布式数据库运维指令集，如 SHOW SLOW、TRACE、SHOW NODE 等指令，快速发现和定位问题。全局唯一数字序列:DRDS 支持分布式全局唯一且有序递增的数字序列。满足业务在使用分布式数据库下对主键或者唯一键以及特定场景的需求。数据库账号权限体系:DRDS 支持类单机 MySQL 账号和权限体系，确保不同角色使用的账号操作安全。分布式事务:DRDS 结合分布式事务套件 GTS，可以支持分布式事务，保证分布式数据库数据一致性。监控报警:DRDS 支持对核心资源指标和数据库实例指标的实时监控和报警，如实例 CPU、网络 IO、活跃线程等，实时发现资源和性能瓶颈。       数据迁移-多分库DB数据迁移到DRDS+RDS分布式单个逻辑库      目前阿里云提供数据迁移工具DTS或数据集成等产品，另外数据集成开源版Datax可以下载部署支持更灵活的方式；      数据传输(数据传输(Data Transmission)是阿里云提供的一种支持RDBMS(关系型数据库)、NoSQL、OLAP等多种数据源之间数据交互的数据服务。它提供了数据迁移、实时数据订阅及数据实时同步等多种数据传输能力。通过数据传输可实现不停服数据迁移、数据异地灾备、跨境数据同步、缓存更新策略等多种业务应用场景)是阿里云提供的一种支持RDBMS(关系型数据库)、NoSQL、OLAP等多种数据源之间数据交互的数据服务。它提供了数据迁移、实时数据订阅及数据实时同步等多种数据传输能力。通过数据传输可实现不停服数据迁移、数据异地灾备、跨境数据同步、缓存更新策略等多种业务应用场景 Mysql到DRDS数据迁移指导手册： https://help.aliyun.com/document_detail/48470.html   数据集成是稳定高效、弹性伸缩的数据同步平台，提供丰富的异构数据源之间数据高速稳定的数据移动及同步能力。丰富的数据源支持:文本存储(FTP/SFTP/OSS/多媒体文件 等)、数据库(RDS/DRDS/MySQL/PostgreSQL 等)、NoSQL(Memcache/Redis/MongoDB/HBase 等)、大数据(MaxCompute/ AnalyticDB/HDFS 等) 、MPP数据库（HybridDB for MySQL等） 迁移工具 部署方式 迁移方式 优势 DTS PAAS云服务 全量+增量 不停服迁移/白屏化操作 数据集成 PAAS云服务 全量 支持数据库类型丰富/白屏化操作/同步任务管理 Datax 自建部署 全量 灵活，可满足复杂数据迁移场景      1.     对于传统分库方式往DRDS+RDS的数据迁移，分库数比较少/要求不停服的情况下可以使用DTS，主要是因为每个源分库需要创建一个数据迁移任务，如果分库数较多，那么创建迁移任务的工作量也是很大的；另外对于目标数据源结构变化大，需要源数据库多表合并jion迁移到目标库的场景不适应DTS，可以使用数据集成 2.     分库数较多和需要源数据库多表合并jion迁移到目标库，比如几十上百分库数的，建议使用数据集成或datax来迁移数据；但不支持增量迁移，要实现增量迁移的需要源表有insert或update时间戳

由于云的便利性及高可靠等特性，越来越多的企业客户选择上云。大家上云遇到的第一个问题就是如何在业务不受影响的情况下，平滑得完成业务的上云迁移。在上云过程中，数据迁移无疑是重中之重。阿里云数据传输服务DTS提供的不停服数据迁移能力，能够在源数据库正常提供服务的情况下，平滑得完成业务的上云迁移。 什么是DTS数据传输服务？DTS是阿里云提供的实时数据流服务，它能够支持常见关系型数据库NoSQL、搜索引擎、消息队列及大数据引擎等数据源间的数据迁移、数据库日志实时订阅及数据实时同步。DTS已为阿里云数万企业用户提供安全、稳定的数据传输服务。天弘基金、一一五网盘、银泰百货、UC浏览器及客如云等各领域的精英企业都是DTS的忠实客户。 与传统迁移方案相比DTS数据迁移功能有哪些优势？相对于传统迁移方案,DTS主要有两个方面的优势：第一 热迁移方案：使用DTS的数据迁移功能，在迁移过程中，源数据库可以正常提供服务，DTS会将迁移过程中源实例的更新数据实时同步至目标实例，最后目标实例跟源实例保持动态同步，业务验证通过后，将流量切换到目标实例。迁移过程中，业务的停机时间就是业务的切换时间，停机时间可以降低至秒级。 第二 迁移回滚方案： DTS为业务提供了一整套迁移异常的回滚方案，降低业务迁移的风险。在迁移过程中，DTS支持建立目标实例到源实例的反向回流链路，当业务切换到目标实例后，DTS可以将目标实例的更新数据同步回源实例，这个时候如果业务出现异常，可以随时回切回源实例。DTS数据迁移功能目前已被广泛应用在 零停机上云迁移、数据库扩容拆分、数据库合并等数据库迁移场景。 除了数据迁移，DTS还提供哪些功能？可应用于怎样的业务场景？除了数据迁移功能，DTS还提供数据库Binlog实时订阅功能，可以支持Oracle、MySQL及分布式数据库DRDS等数据源的Binlog的实时订阅。数据库Binlog订阅功能已被广泛应用在异步消息通知、缓存更新、含复杂ETL逻辑的数据实时同步等场景。 除上述功能，DTS还支持数据库、搜索引擎、消息队列及大数据产品之间的数据实时同步，基于数据库日志同步，可在距离上万公里的两个数据源之间实现毫秒级同步延迟。通过数据同步功能，您可以轻松构建业务异地灾备及异地多活，有效规避地域故障导致的服务不可用问题。 针对数字化转型的大趋势 DTS可提供怎样的助力？在产业互联网的大背景下，越来越多的企业开始进行数字化转型，重投入到实时数据分析以挖掘商机并快速得进行商业策略调整。为此，DTS推出数据库业务数据实时同步到数据仓库的解决方案，帮助用户轻松构建实时数据仓库，快速挖掘商业机会。 省钱小贴士 教你如何一年省出十万元DTS 将在2月~4月推出新年特惠活动，针对ADB及关系型数据库DRDS的数据同步包年包月实例折扣低至0折，欢迎大家扫码试用。 0折直通车https://www.aliyun.com/acts/product-section-2019/apsaradbcaigouji#%E5%B7%A5%E5%85%B7%E7%A4%BC%E5%8C%85%E8%B5%A0%E5%93%81%E5%8C%BA 快速了解数据传输服务DTShttps://www.aliyun.com/product/dts 配送文档学习https://help.aliyun.com/document_detail/26592.html 点击了解阿里云新品发布会https://promotion.aliyun.com/ntms/act/cloud/product.html

摘要：迁移&容灾是数据库的强需求，传统的迁移&容灾技术已经发展多年，随着云时代的来临，在迁移&容灾的使用场景、网络、技术都有很大的变化，如何在云时代下更简单的实现数据库的迁移&容灾，云厂商如何通过新的技术实现弯道超车，本文中阿里云智能数据库产品事业部高级技术专家付大超就为大家分享了阿里云在此领域的技术新进展和应用。 专家简介：付大超（花名：千震），阿里云智能数据库产品事业部高级技术专家，2012年加入阿里巴巴，目前负责DTS&DBS团队和研发，在阿里云提供迁移、同步和容灾的服务，支持阿里巴巴、蚂蚁、阿里云等异地多活单元化架构，曾负责阿里全球最大的HBase集群的开发和维护工作，曾先后工作于IBM、Cisco。 直播回放 链接：https://yq.aliyun.com/live/1048 议题PPT下载，戳这里！ https://yq.aliyun.com/download/3564 本文将主要围绕以下四个方面进行分享： 现状和问题 云时代的机会 阿里云的新进展 应用案例 迁移&容灾现状与问题 2014年，xx银行核心数据库出现故障，导致存取款、网银、ATM等业务全部中断长达37小时。2017年，xx游戏数据库故障，30小时无法服务，数据丢失，导致游戏回档。2018年，xx著名代码托管服务商数据库故障，24小时无法服务。以上这些问题的根源都是数据库。而整体而言，数据库的问题和程序开发是类似的，按照墨菲定律来讲就是只要有出现问题的可能，那么问题就一定会出现。 我们不能和墨菲定律赛跑，因此需要做好数据的迁移和容灾等工作。从业界的两个公开报告分析了数据库出现问题的一些原因。可以看到，在2015年，备份恢复软件收入达到44.49亿美元，这一市场的份额还是比较大的。 国家标准《信息系统灾难恢复规范》可以给大家一些参考，也就是说大家愿意投入的成本和收益是正相关的，花费的钱越多，数据丢失的时间和恢复的市场就会越小。因此，需要在投入成本和数据丢失情况之间进行平衡。上图中右侧是国标中定义的一张表，虽然年代比较久远，但是在今天仍旧有一定的参考意义。 数据复制技术现状 对于迁移和容灾本身而言，都是使用的数据复制技术，包括了逻辑复制和物理复制，这两者之间各有优劣。两者相比而言，逻辑数据复制对于数据库的兼容比较好，实时性好，目的库基本都是可用的，而物理备份目的库却可能是不可用的。 云时代的机会 这里列出了三份涉及到数据库迁移和容灾的Gartner报告，不同报告的金额不同。但是总体来讲，数据库迁移和容灾市场在不断增大，而云上市场更是在翻倍地增长。市场的现状是数据库多种多样，所有的数据都存储在各个数据库系统或者其他存储系统里面，数据是企业的核心资产，一般而言，如果出现了问题都是最高级别的故障，因此可能会造成极大的影响。此外，灾备事故本来发生的就比较多，可能出现数据无法恢复的情况，并且RPO、RTO也可能比较大。而新的变化在于，用户在持续地上云，对于阿里云而言，从2016年到如今，用户处于爆发式增长。而云厂商在快速推进云上数据迁移和灾备服务，而传统软件厂商仍属于领导者，但都在快速云化。 云时代的变化 云时代下，除了数据库迁移和灾备的市场发生了变化之外，其实玩法也变了。场景、网络以及技术都发生了变化。对于场景而言，比如线下网络是隔绝的，但是云上就会出现一些问题，存在很多监管或着合规的要求。还有出海、混合云、多活以及云备份等，私有云自己搭建是比较困难的，但是上云之后可能就会容易很多，可能只需要点击几下鼠标就好了。对于网络而言比较复杂，因为要做网络隔离来保证安全性，因此需要做VPC、专线以及网关等，实现每个用户互不干扰。对于技术而言，很多用户从线下迁移上云存在公网的问题，可能网络质量不是特别好，并且需要解决用户的秒级RPO问题和快照技术问题，还需要保证用户的备份数据集能够提供查询。 云时代的网络架构 可以看到，云服务与阿里云之间、用户本地自建数据库与阿里云之间以及订阅消费与阿里云之间，可能的网络类型包括了公网、私网、VPC、专线和VPN网关，这就为数据库迁移备份带来了很多困难，因为网络是基础设施，如果网络存在很大问题，那么整个服务的性能和稳定性就会遇到非常大的挑战。对于数据迁移而言，最大的不可控因素就是源库和网络。 阿里云的思考 对于阿里云而言，首先需要考虑数据如何流动起来，通过阿里云数据传输服务DTS和数据库备份能够帮助用户搞定迁移和备份问题。 数据高速公路—DTS 数据传输服务(Data Transmission Service，简称DTS) 支持以数据库、大数据、文件为核心的结构化存储产品之间的数据传输，它是一种集数据迁移、数据订阅及实时同步于一体的数据传输服务。DTS是支持增量数据传输的，其增量方法基于日志解析实现，并且支持Oracle、SQL Server、PG、Redis、MongoDB等数据库，这项能力目前在全球都处于领先地位。阿里云DTS应该是公有云上第一个数据传输服务，处于技术的领先地位。并且无论是源端数据库还是目标数据库，DTS都支持友商以及用户本地的数据库。如果用户想要做订阅，比如流计算、搜索、广告等数据库下游业务都需要通过DTS服务来解决问题。 DTS核心模块如下图所示，DTS整体分为几个模块。为了解决数据同步或者迁移过程中，因为用户的DDL而引起的数据库表结构变更，此时就需要MetaBuilder进行解决。数据解析完成之后放入到DStore里面，变成结构化的数据，其能够支持索引，比如Tag或者Index，DStore类似于简单的数据库，因为其能够支持快速查找。此外，在数据写入的时候还实现了一些Bucket冲突算法等。 日志解析能力这里介绍一下DTS的DReader基本架构。DReader是插件化的，可插拔的架构，对于源端的各种数据库开发一个插件，将这个插件放到DTS上去之后就能够支持源端数据库到目标数据库的增量数据同步了。 日志解析DReader对于日志解析而言，存在一定的问题，这里选取几个重点问题进行讲解。第一个问题就是如何构建Schema快照，无论是什么数据库，在解析日志的时候如果源端数据表发生了变更，如何实现对于变更的解析，这就需要将源端数据库的Schema信息和本地适配起来，因此DReader需要Schema的构造和维护能力。第二个关键问题就是大事务、穿插以及回滚事务的解析，这对于MySQL而言比较简单，但对于Oracle而言就会存在很多的问题，而DReader很好地解决了这个问题。 因为Oracle有归档和Redo的功能，DReader可以同时支持这两者，去解析日志的时候需要通过Extractor将其转化成结构化的Record，进而按照事务进行聚合，再实现二进制转化，最终还要做Update回查数据。上图中下侧讲的是断点续传，这里也存在几个问题，当面对大事务的时候，数据存在交叉，正常的安全位点都是记录Commit的位置。而在用户数据库的迁移和同步过程中发现有些任务很奇怪，可能并没有业务数据但是延迟很大，分析其原因是用户存在一些无操作的长事务，只是开启了Begin但是一直没有Commit，这就导致了几方面的问题。一个就是延迟很大，就是一旦重启，因为安全位点很老旧，就会将数据拉倒老旧的安全位点，需要拉取很长一段时间的增量数据，使得数据同步的速度非常慢。另外一点就是很有可能redo等日志已经删除掉了，那么此时就可能无法恢复数据了。因此DReader希望能够判断出来事务是不是一个无操作的事务，这样就能将安全位点移动到合适的位置上来解决相应的问题。对于大事务问题，可能一个事务提交过来100G的数据，那么就需要通过落盘操作将事务解析出来进行进一步处理。这里还有一些其他的问题，比如SQL Server的堆表页迁移和DDL支持问题、PostgreSQL的DDL日志问题以及Redis的resharding日志问题等，还有分布式事务解析问题以及反查对源库影响问题。 幂等同步 幂等同步原理较为简单，但是非常有用。主要就是Insert唯一性冲突的时候，进行Replace语义操作；Update不命中的时候，插入新镜像值；Update唯一性冲突的时候，Delete旧镜像值，插入新镜像值。这一点在DTS中可以做到，数据随意回拉都能够保持一致性。 DTS Any To Any 架构 Any To Any的意思就是任何一个源端数据库到任何一个目标端数据库都只需要开发一次即可。从源端数据到中间是确定的转换，而从中间到目的端数据却是不确定的转换。阿里云DTS为用户提供了转换模型，但是用户也可以自己选择转换逻辑。 分布式解析和同步 如果源端数据库属于分布式架构，采用了分库分表的方式或者使用了集群架构，这种情况下如何实现数据迁移呢？这里支持分布式架构的数据迁移的最关键的问题就是做协同，比如有DDL该怎么办，DDL谁先做谁后做都存在很大的问题。阿里云DTS采用了分布式Raft算法来解决这样的问题。 数据库时光机—DBS 数据库备份服务（Database Backup Service，简称DBS）是为数据库提持续的、可靠的、低成本的备份服务。它可以为多种环境的数据提供强有力的保护，包括企业数据中心、其他云厂商、混合云及公共云。备份主要包括几种环境，公网自建、本地IDC以及ECS自建的数据库，可以支持将数据备份到阿里云OSS和阿里云NAS上。 DBS核心模块DBS核心模块如下图所示，Full表示全量备份，Inc表示增量备份，这两者都属于逻辑备份，此外DBS还提供了物理备份。 DBS秒级备份DBS能够实现秒级备份，做到秒级RPO。在做数据库恢复时需要知道想要恢复到哪个库和哪个表，但是因为数据一直在变，难以知道恢复到哪个时间点，而DBS能够帮助用户恢复到任意时间点。 DBS物理备份对于DBS物理备份而言，需要有一个Agent，比如用户只有本地IDC而没有公网IP，当他想要进行数据备份只需要下载一个Agent即可。Agent能够自动升级，并且一旦启动之后就能够自动汇报心跳，所有的操作都在阿里云上完成，只需要点击几下就能够将全部数据备份或者恢复完成。 双11大屏下图展示了双11大屏的情况，大屏上展示了实时交易量，那么2135亿这个数字是怎么计算出来的呢？因为全球的交易都发生在不同的地方，想要实时统计并展现这个数字就需要刚才讲到的DTS技术，通过实时增量订阅来获取数据。 阿里云Region单元化 阿里云本身Region单元化的架构都是借助了DTS技术完成的，从而实现了全球同步。 案例1：基于DTS搭建的银泰新零售混合云举例而言，银泰在全球有几十个商场，之前其数据库都是Oracle，而为了实现“去O”，银泰基于DTS搭建了新零售混合云架构。通过共享Store+源端过滤将银泰专线带宽占用从300Mb->30Mb每秒，源库CPU从40%降低到10%，并且实现了双副本实现秒级容灾。 案例2：某新零售公司异地多活对于传统架构而言，异地多活是一件比较困难的事情，而如果今天在阿里云上做这件事情就会相对比较简单了。该公司业务上在多地有多套服务，这些服务同时承担业务流量，且服务之间互为备份。借助阿里云，通过双向同步功能，进行各业务中心的数据同步，实现数据全局一致。当某个节点出现异常时，业务秒级切换到其他节点。 案例3：某用户备份数据在线查询 数据库备份DBS和Data Lake Analytics深度合作，发布备份数据在线查询能力，让备份数据“活”起来。无需恢复，用户可以通过SQL语句交互式查询备份数据，查询结果集立刻返回给用户。相对于传统备份，数据在恢复后才有价值，DBS备份数据在线查询对用户最大的价值：快速，在备份验证、归档查询、数据订正、数据提取等场景上，用户可以快速获取备份数据。 案例4：某集成商集成DBS阿里云的某个用户拥有几十万的SQL Server数据库，想要为用户提供SQL Server能力，这个厂商就将阿里云DTS封装完成之后来提供服务。由此也可以看出，生态伙伴可以借助阿里云以很低的成本做很多事情，最终实现集成商、终端用户、阿里云的三赢。 案例5：某互联网公司-缓存更新业务解耦用户为了提升读并发，在业务中引入缓存，业务更新请求落在DB，读请求落在缓存。希望在不影响业务的情况下解决缓存更新问题。对于存在依赖关系的上下游业务，希望不影响上游稳定性的情况下，低成本得实现下游业务通知机制。使用阿里云DTS的数据订阅功能，实时获取上游业务的数据库更新数据，更新缓存内容，解决缓存更新问题；触发下游业务逻辑。 案例6：某小视频公司-业务数据实时分析很多用户会通过自己搭建的Flink集群或者Storm集群实现实时数据分析，想要将这些数据实现增量地写入目的端数据库，通过DTS就能轻松地完成。 案例7：城市大脑城市大脑是阿里云树立的很好的名片，通过城市大脑帮助很多城市减轻了交通拥堵问题，城市大脑也使用了阿里云的一系列产品，包括DTS、ADB、TSDB、DRDS、DMS等。

乔帮主的直播内容经精炼整理、分以下5篇：一、分享介绍&架构三原则二、云架构、架构的原始阶段和基础阶段三、架构动静分离和分布式阶段四、架构数据缓存阶段和两个维度拓展阶段五、架构微服务阶段 架构微服务阶段：容器、Fast Data架构 在微服务阶段，结合容器技术，未来业务跨云平台分布式架构才是最主流的形态。如左边架构图所示，在这个架构阶段采用的云产品，相比水平扩展的分布式阶段，主要增加了DNS智能解析、时序数据库InfluxDB、阿里云容器服务kubernetes（ACK）、数据库传输服务DTS。 这阶段有四个核心技术特点。第一点：我们通过容器技术DOCKER+K8S，让业务部署跨平台，不依赖云平台或者底层物理环境。 第二点：通过DNS智能解析，我们能将用户请求分别调度转发到不同平台中。说到DNS智能解析，其实CDN的就近访问核心功能就是依靠CDN的智能解析。 第三点：在跨云平台分布式架构中，最难的技术点其实就是核心技术点，就是数据同步。我们把业务部署在不同平台上，意味着数据在不同地域上，我们怎么样保障不同地域连接的数据库的数据做实时同步，保障数据一致性呢。阿里云有DTS成熟的同步方案，加上专线高速通道解决数据传输速度等问题，这也是这方面较成熟的解决方案。 第四点：采用时序数据库InfluxDB，实现海量数据实时采集及存储，并且实现海量数据的实时查询计算。具体我们看一个FAST DATA的案例：驻云DataFlux产品功能架构图。 驻云DataFlux当然也是采用微服务+容器的架构。在这里主要跟大家分享的是fast data技术特点，即如何体现在fast上？如图架构图，我主要说三个实时的技术特点，让大家理解fast data阶段的技术特性。第一，数据的采集上，DataFlux可以采集各类业务场景数据源，并且是实时的采集的。采集器有驻云自主研发的datakit、wdf、pdf采集器，也支持telegraf、prometheus等热门采集器。这是第一个实时性。 第二，数据实时采集后，通过数据网关（类似zabbix proxy代理），上报到数据处理开发平台，进行实时处理。 第三，最为核心的实时性特点，数据经过实时处理后，核心通过influxdb时序数据库进行统一存储。 Influxdb是个分布式数据库，读写速度能轻松达到秒级千万级数据量。特别是在查询分析上这是influxdb的核心优势。利用这第三个实时性的特点，我们把数据输出到数据洞察等多种企业级应用场景中，能轻松应对大规模海量数据的实时分析。这也influxdb为什么适合物联网IOT海量数据读写的重要原因，也基本上是物联网IOT架构中不可缺少的技术环节。 通过“Fast Data”的一个案例，本次围绕“阿里云千万级架构构建”的主题分享就这些，更多精彩可购阅我新出版书籍哦。

3月11日，Redis企业版（Tair）& 专属主机组将召开重磅新品发布会！ 时间：3月11日（周三）15:00-16:00 观看直播 产品详情 性能提升高达3倍，TCO最高降低90%！十年磨一剑，打造旗舰级缓存服务，邀您一同见证商业和技术的创新！ 本文作者皓楠，阿里云数据库产品专家 Redis 是世界上最流行的 KV 缓存数据库，2009年诞生至今，已发展超过十个年头，伴随着互联网行业的发展，Redis 在过去十年取得了辉煌的成绩。 Redis 服务在中国有着非常庞大的用户群体和商业市场，根据 similarweb 的统计，redis.io 的流量访问中，超过 50% 来自于中国大陆，中国开发者对 Redis 的喜爱程度可见一斑。 2019年 阿里云 Redis 缓存服务取得了不小的成就，上线 5.0 版本，行业率先提供模块服务，按时间点恢复能力等。在致力于提供业内最优秀的缓存服务上，我们一直不遗余力。 回顾2019 1.1上线 Redis 5.0 2019年4月，阿里云全地域上线了最新稳定版 Redis 5.0，提供 Stream 数据类型，ZPOPMIN/MAX，增强 HyperLogLog 等最新功能。 其中 Stream 是继 Redis 3.2 版本 GEO 功能以来时隔两年多全新的数据结构。Stream 类似于日志的数据结构，允许在单一 Key 上基于自动的有序时间序列存储多个字段，在消息队列，事件通知，统一日志架构等业务场景中有非常大的发挥空间。 阿里云 Redis 目前支持 2.8，4.0，5.0 三个大版本，版本丰富度国内领先。全系列支持主从双副本，分片集群，自动读写分离架构，满足客户多样的业务需求。 1.2提供全新数据库自治服务（DAS） 性能诊断和性能调优是数据库使用中最棘手的问题。为了更好的帮助用户找出数据库性能隐患点、提升问题排查的效率。阿里云 Redis 缓存上线了全新自治服务工具 DAS 服务，支持 Redis 慢请求分析、实时性能查看、缓存分析、会话管理： Redis 慢请求分析，慢请求一目了然 实时性能 实时性能以5秒的采集粒度，实时的采集、分析和展示核心性能指标的趋势，帮助用户在大促、应用发布等场景下一眼确认数据库性能。 缓存分析 缓存健康情况对于Redis的性能是至关重要的，通过 DAS 的缓存分析功能，您可以直接确认确认Key分布情况，减少因为Key倾斜引发的内存不足、性能下降等问题。 会话管理 如果Redis的异常正在发生，我们第一时间需要确认正在执行的请求或者操作，该功能直接将正在执行的请求通过白屏化的方式直观的展示给客户，并且支持各个维度的统计和排序，同时也支持终止异常会话. 多个Redis实例批量管理的功能，是很多企业级客户需要的，除了上述功能外，我们也新增了自定义监控大盘的功能，支持企业级用户在管理多个实例的场景下，自定义跨实例的监控大盘，满足日常运维中多实例、多指标的关联、对比、查看需求。 1.3审计日志系统全面升级 Redis 社区版最被客户诟病的一点就是不支持审计，客户无法实现快速定位历史操作信息。发生性能问题，误操作时，没有排查依据。阿里云 Redis 服务，通过内核改造提供全操作日志（modify）及高危命令的审计功能，性能开销通常低于 5%，为客户提供 7x24 基本无业务无损的审计服务，近日又对审计功能进行了全面升级，提供关键字模糊查询，代理及数据节点审计，账号，DB，客户端 IP 多条件过滤等能力，方便客户在众多审计日志中快速定位。同时提供访问用户数，客户端数，审计日志书，平均 RT，平均 QPS 的聚合展示，以及 Top 用户，客户端及命令的聚合展示，系统运行状态一目了然。 审计日志提供，账号，客户端IP，DB，执行命令等信息展示，并支持控制台直接导出。 同时我们还支持定期推送审计日报，基于审计信息的邮件告警等功能，审计日志功能全面升级。 展望2020 “今天的最好表现, 是明天的最低要求”, 疫情阻止不了阿里云 Redis 前进的脚步, 2020 还有哪些值得期待的功能? 1. 推出 Redis 企业版（Tair）品牌系列 Tair 是阿里云自研分布式键值存储(KVS)系统，几乎涵盖了淘宝、天猫、阿里妈妈、菜鸟、钉钉、优酷、高德等阿里巴巴所有核心业务。2019年底阿里云 Redis 企业版（Tair）系列全站发布。 这里要先聊一聊社区版 Redis 的一些核心问题：单线程 C10K 问题，即在大链接状态下抗冲击能力很差。大型和超大型应用动辄就有一万或者几万进程连接Redis，一个冲击响应或者一个慢查询就可能导致连接数雪崩。 单分片处理能力有限。Redis单进程对于 O(1) 的操作大致有10～13w OPS的服务能力，虽然对比其他数据库，性能已经非常优秀，但是在互联网极端和突发场景下处理能力依然不足。 数据结构模块（Module）。Redis提供的基础的Hash、List、Set等是通用的是对通用互联网环境的总结，而在互联网大型企业有着更多的模块需求。 跨地域分布式缓存需求。随着互联网全球化进程的发展，实例多活成为了愈来越多客户的刚需。多活不但能够实现高性能的“就近访问”，还能作为跨地域复制（Geo Replica）的一个重要容灾手段，可以极大的提升客户的业务稳定性和架构灵活度。 低成本缓存。针对大容量低访问但对RT（latency）不敏感的应用，纯内存显然代价过高。 针对上面的通点问题，阿里云 Redis 企业版（Tair）推出了两个系列，性能增强系列和混合存储系列。 性能增强系列，业内最快的缓存系统 多 IO 线程改造，引入更多计算资源，减少 IO 事件等待提升处理能力。单节点 30-40w OPS 是社区版处理能力 3 倍以上，30-50k 链接下稳定运行，轻松应对高并发，突发流量等业务场景。同时性能增强系列还提供了多达 5 种自研 module，进一步拓展 Redis 缓存的应用场景。 混合存储系列，低成本超大规模持久化KV存储解决方案引入 SSD 磁盘作为缓存介质，提升缓存容量的同时大大降低了缓存成本，单分片最高支持 1T 存储，集群版最高可扩展至 9TB，同时整体成本下降 70%-90%。为客户带来真正的实惠。混合存储系列所有操作都在内存中完成，完全兼容 Redis 协议，对于客户来说可以 0 成本启动。目前支持 DTS 和 redis-shake直接导入数据。 2. Redis 专享主机形态，云上最灵活的大规模集群解决方案 随着云业务的发展，云服务被越来越多的企业所接受，但是云发展的过程中，如何解决规模化集群管理，客户级别资源隔离，定制化管控需求是当下云 PaaS 服务面临的一大挑战。阿里云 Redis 服务推出专享主机形态是商业上的一次创新和技术上的一次突破。这里有三个主要概念： 主机组：逻辑主机群的概念，主机组间资源互相不可访问，可以按需申请多个。我们建议按照业务垂直拆分主机组，提供业务间资源隔离。 主机：服务器主机，一台主机可以开通多个实例，我们支持灵活地添加，删除主机，也支持针对主机的管理，比如替换主机，重启主机，清空主机实例，迁移主机实例等，方便客户进行资源调配管理。 缓存实例：一台主机上面可以开通多个 Redis 缓存实例，这个实例概念等同于 PaaS 服务的 Redis 实例。我们提供云上 Redis 缓存的全部能力，包括监控告警，日志管理，备份恢复，账号管理等基础能力。 专享主机形态，相当于将客户的 IDC 无缝搬迁到云上，提供大规模主机管理，调配能力，主机对用户更透明。同时开放主机管理能力，支持用户登陆采集信息，同时支持自定义脚本，代理安装，方便大客户定制管控开发。主机提供超卖比设置，可以将不同资源类型，业务高峰的业务错峰部署，提升资源利用率，实现超高性价比。同时 Redis 缓存实例无缝对接阿里云管控平台，可以轻松开通，删除实例并展开实例变配，监控告警，日志管理等基本运维管理工作，让客户享受云平台技术红利，降低运维成本，提高人效，让客户专注于核心业务。 3. 业内首先支持多种 module，使用更灵活，功能更强大 TairString Redis String性能增强命令包含CAS和CAD，可以实现简洁高效的Redis分布式锁。使用说明及示例请参见CAS/CAD命令。 TairString数据结构及相关命令TairString是一种带版本号的string类型数据结构。原有的Redis String由key和value组成，而TairString不仅包含key和value，还携带了版本（version），可用于乐观锁等场景。除此之外，TairString在Redis String加减功能的基础上支持了边界设置，可以将INCRBY、INCRBYFLOAT的结果限制在一定的范围内，超出范围则提示错误，适用于限流器等场景。 TairHash TairHash是一种hash类型的数据，不但和原有的Redis Hash一样支持丰富的数据接口和高处理性能，还突破了Redis Hash只能为key设置过期时间的限制，支持为field设置过期时间和版本，极大地提高了hash数据结构的灵活性，简化了很多场景下的业务开发工作。TairHash使用高效的Active Expire算法，可以在不对响应时间造成明显影响的前提下，更高效的完成对field的超时判断和删除。 TairBloom TairBloom是一种可动态扩容的布隆过滤器，完全兼容RedisBloom模块的命令。TairBloom首先是一种概率性数据结构（space-efficient probabilistic data structure），主要使用较低的内存消耗来判断一个元素是否存在；其次，TairBloom具有动态扩容的能力，可在扩容的同时维持证误判率的稳定。 TairDoc TairDoc是一种文档类型的数据结构，支持JSON标准，完全兼容ReJSON模块的命令。TairDoc数据以二进制树的方式存储，支持对JSON中子元素的快速访问。 TairGIS TairGis是一种使用R-Tree做索引，支持地理信息系统GIS（Geographic Information System）相关接口的数据结构。Redis的原生GEO命令是使用GeoHash和Redis Sorted Set结构完成的，使用1D索引，主要用于点的查询，TairGIS使用2D索引，除了对点的查询，还支持线、面的查询，尤其适合用于判断相交或包含关系，功能更加强大。 4，支持按时间点恢复 社区版 Redis 提供 RDB 和 AOF 两种持久化方式，但是缺少类似于 Binlog 的日志形式，AOF 没有记录时间和位点信息，导致无法按照时间点恢复数据。虽然 Redis 纯缓存的场景下，这种恢复模式可以满足大多数业务场景需求，但是在游戏等行业下，如果支持按照时间点恢复数据可以实现快速回档，极大提减少停机维护时间。阿里云 Redis 缓存服务，通过在 AOF 追加时间戳信息，可以实现按照时间点恢复数据，实现了从缓存到数据库的飞跃。这种日志改造在主从复制，跨地域备份等场景下也有非常好的应用，可以实现断点续传等能力。 5.全球分布式缓存服务助理企业级客户全球化业务布局 随着企业级客户全球化业务的发展，全球分布式缓存服务的需求应运而出，跨地域数据双向，多向同步，全局就近访问，成熟的链路监控体系是这一类服务的标签，2020 年阿里云 Redis 服务将在企业版基础上推出全球分布式缓存服务形态，满足企业级客户业务出海，全球业务的诉求，方便客户跨地域业务的展开。 结语 从 2009 年 Redis 服务面世以来，Redis 缓存已经经历了 10多个年头，缓存行业也经历了翻天覆地的变化。 2019年底，Redis 6.0 RC 版面世，预计稳定版也会很快面向用户正式开放。用作者的话说，这个版本是迄今为止最大的更新，从 RC 版 Release Note 来看，最新版 Redis 在客户端缓存，多 IO 线程，集群代理，SSL 加密，模块 API 优化都有提及，可谓是赚足了眼球。 不过回头看看阿里云 Redis 服务的发展历史，我们早在几年前就布局了 SSL 加密，多 IO 线程改造，集群代理，混合存储，模块等方方面面，某种意义上来说，阿里云 Redis 服务是走在了缓存时代的最前沿。我们在为用户提供最优秀，好用的缓存服务上一直不断努力前行。 在可以预见的未来，缓存依然会是数据库产品阵营中的主流，且不可替代，这里我们也做个趋势预测缓存需要更贴近客户业务，缩短 RT，多级缓存或成为标准。 产品架构会对客户更加透明，对客户无感，主从版与集群版的使用差异会越来越小，客户无需感知后端产品架构。 弹性热伸缩或成为刚需，满足互联网场景下突发流量，瞬间峰值等极端业务场景。 全球分布式缓存或成为大型国际化互联网行业的标准诉求，双向甚至多向复制成为行业基准能力。 面向 IOT & 5G 的爆发，缓存更轻量化，解决边缘计算场景下的缓存需求。 最后打一个小广告，阿里云 Redis 企业版（Tair）产品限时折扣中，1年7折，2年6折，欢迎采购。 Redis企业版（Tair）& 专属主机组[重磅新品发布会](https://yq.aliyun.com/live/2148)3月11日 15:00-16:30邀您一同见证商业和技术的创新！

云计算时代，云原生分布式数据库和数据仓库开始崛起，提供弹性扩展、高可用、分布式等特性。 数据库将面临怎样的变革？云原生数据库与数据仓库有哪些独特优势？在日前的 DTCC 2020大会上，阿里巴巴集团副总裁、阿里云数据库产品事业部总裁、ACM杰出科学家李飞飞就《云原生分布式数据库与数据仓库系统点亮数据上云之路》进行了精彩分享。 阿里巴巴集团副总裁、阿里云数据库产品事业部总裁、ACM杰出科学家李飞飞 以下为小编整理的演讲干货实录： 一、背景与趋势 1.背景 数据库的本质是全链路的对“数据”进行管理，包括了生产—处理—存储—消费等，在当下的数据化时代，数据是所有企业最核心的资产之一，所以数据库的价值一直在不断地提升，不断地在新领域发现新的价值。 2.业界趋势 趋势一：数据生产/处理 正在发生质变关键词：规模爆炸性增长、生产/处理实时化与智能化、数据加速上云 从Gartner、IDC及各个传统厂商分析中可以得到以下几个结论： 数据在爆炸性增长，非结构化数据的占比越来越高； 生产/处理实时化与智能化的需求越来越高，并追求离在线一体化； 数据库系统、大数据系统、数据管理分析系统等上云的趋势明显，数据加速上云势不可挡。 趋势二：云计算加速数据库系统演进关键词：商业起步 - 开源 - 分析 - 异构NoSQL - 云原生、一体化分布式、多模、HTAP 数据库和数据仓库从上世纪八十年代至今的发展缩影 云计算面临两大挑战 挑战一：分布式和ACID的结合 从传统的大数据处理来看，牺牲部分ACID换来的分布式水平拓展虽然非常好，解决了很多场景下的需求，但是应用对ACID的需求一直存在，即使是分布式并行计算的场景当中，应用对ACID的需求也变得越来越强。 挑战二：对资源的使用方式 传统的冯诺依曼架构下计算和存储是紧密耦合的，可将多个服务器通过分布式协议和处理的方式连成一个系统，但是服务器和服务器之间、节点和节点之间，分布式事务的协调、分布式查询的优化，尤其要保证强一致性、强ACID的特性保证的时候，具有非常多的挑战。 全球云数据库市场格局 关键词：资源池化，资源解耦 云的本质是用虚拟化技术将资源池化，并且将资源进行解耦。阿里云是核心云厂商之一，基于云原生技术，打造了云原生数据库产品体系，代表中国的数据库厂商，在Gartner将OPDBMS(事务处理 )与DMSA(管理与分析)合二为一的挑战下，历史性第一次进入Gartner Cloud DBMS云数据库全球领导者象限，市场份额来全球第三，在中国业界领先。 数据库系统架构演进 关键词：单节点、共享状态、分布式 上图是基于存储计算紧耦合，DB代表计算节点，架构当中计算节点的CPU Core和内存还是紧耦合在一起。左边的架构单一，资源紧耦合。右边分布式架构，通过Shared Nothing将多个部分连成一片，理论上具备非常好的水平扩展能力，利用分布式的协议进行分布式的事务处理和查询处理，但是也遇到分布式场景下分布式事务处理、分布式查询等非常多的挑战。 不管是传统的中间件分布分表的形式还是企业级的透明分布式数据库都会面临一个挑战，一旦做了分布式架构，数据只能按照一个逻辑进行Sharding和Partition，业务逻辑和分库逻辑不是完美一致，一定会产生跨库事务和跨sharding处理，每当ACID要求较高的时候，分布式架构会带来较高的系统性能挑战，例如在高隔离级别下当distributed commit占比超过整个事务的5%或者更高以上的话，TPS会有明显的损耗。 完美的Partition Sharing是不存在的，这些是分布式业务需要解决的核心挑战，以及在这个架构需要做到的高一致性保障。 云原生的架构，本质上底下是分布式共享存储，上面是分布式共享计算池，中间来做计算存储解耦，这样可以非常好地提供弹性高可用的能力，做到分布式技术集中式部署，对应用透明。避免传统架构当中的很多挑战，比如分布式事务处理、分布式数据如何去做partition和sharding。 共享存储、共享资源池、共享计算池的时候，它的水平拓展性还存在一定局限性。我们可以结合分布式和云原生的架构融合来解决这个问题。 在上图展示中，把Shared Nothing的能力和Shared Storage/Shared everything的能力打通，每个shard下面是一个资源池，能力非常强，弹性很高，同时也可以把这样的部分用分布式技术联系起来，既享受到分布式水平拓展的能力的好处，同时又避免大量的分布式事务和分布式处理场景。因为单个节点计算存储能力都特别强，200TB的数据按照传统的分布式架构，假设1个节点只能处理1TB，那就需要200个分布式节点。云原生架构1个节点可以处理100TB，也就是为2000TB的数据，传统分布式架构需要200个节点，将云原生架构结合起来需要两三个节点，分布式事务处理、分布式查询的概率会大大降低，整个系统的效率会大大提升。 趋势三：下一代企业级数据库关键技术关键词：HTAP:大数据数据库一体化、云原生+分布式、智能化、Multi-Model 多模、软硬件一体化、安全可信 大数据、数据库一体化的趋势包括离在线一体、Transaction and Analytical Processing一体化，离线计算和在线交互式分析的一体化，统称为大数据与数据库一体化。 云原生和分布式技术的深度融合，智能化、机器学习、AI技术在数据库领域的融合，如何简化运维、简化数据库的使用方式。除了结构化数据，如何处理非结构化数据，比如文本等数据，软硬件一体化，如何结合硬件的能力如RDMA和NVM，发挥出硬件的优势。最后是系统的安全可信能力。 二、核心技术&产品介绍 2.1企业级云原生分布式数据库 1）云原生关系型数据库PolarDB 阿里云自研关系型数据库的核心产品是云原生关系型数据库PolarDB，通过这下面张图就可以理解PolarDB的思想，存储和计算分离，通过RAFT来做高可用、高可靠的保障，在计算节点来做一个计算池，下一代版本的PolarDB可以做到多写多读multi-master,计算节点在下一代会进一步解耦，做成共享内存池，CPU Core可以做到共享计算池，然后去访问一份共享内存， PolarPorxy负责做读写分离和负载均衡工作。 基于这个架构，100%兼容MySQL/PG和高度兼容Oracle的PolarDB诞生了，针对开源和商业数据库的使用场景，在性能上做了大量的优化，比如做Parallel Query Processing，取得了非常优异的性能，整个TCO相对传统数据库可以做到只有1/3到1/6，TPCC同样的负载下性能有大幅度提升。 在PolarDB的基础上做了Global Database，跨Region的架构解决了很多出海客户就近读写的需求。 2）云原生分布式数据库PolarDB-X 分布式版本的PolarDB-X：基于X-DB以及原来的分库分表DRDS将二者合二为一成为一个透明的一体化分布式数据库PolarDB-X。每个分布式节点包括两个数据节点、一个日志节点，通过优化Paxos确保数据节点和日志节点的数据一致性。 它的特点在于三节点可以做到跨AZ部署做到同城容灾，不需要传统的商业数据库利用数据同步链路来做容灾，直接在存储层做到同城容灾。 异地的两地三中心甚至更多异地容灾架构，比如跨异地的直接部署，因为网络的Latency非常大，可能会影响到性能，还是需要通过类似ADG、DTS这样的产品架构来做数据同步，做到异地容灾架构。 3）数据库及应用迁移改造ADAM ADAM，全称Advanced Database Application And Application Migration，通过对应用代码和逻辑树的分析生成一个评估报告。评估报告自动生成，可以提供从传统数据库迁移到PolarDB和ADB的迁移分析。 一键迁移的方案通过ADAM来做应用代码的扫描，通过DTS去做数据的实时同步，迁移到云原生的数据库当中，可以做到对于客户的应用无切入的改造。 如图所示： 总结来说，分布式只是一个技术，实际上很多数据库的应用是不需要分布式，通过云原生的能力就可以很好地满足应用弹性、高可用、水平拓展的需求。真正需要分布式的能力就可以结合Shared Nothing架构和技术来做扩展，所以要根据应用需求从客户视角出发设计系统和应用迁移改造方案。 2.2云原生数据仓库与数据湖 一体化设计成为下一代数据分析系统的核心理念 数据库市场不仅是TP关系型数据库。这也是为什么Gartner将传统的OPDBMS（事务处理）与DMSA（管理与分析）合二为一成为Cloud DBMS，并且断言Modern DBMS can do both and there is only one Cloud DBMS market。除了事务处理，数据库系统也需通过计算分析实现数据处理的一体化，例如在数据仓库和数据湖领域发挥作用。 云原生数据仓库+云原生数据湖构建新一代数据存储、处理方案 数据分析领域是群雄格局的现状，在线查询、离线计算，有非常多细分领域，利用云原生计算技术的资源池化、资源解耦，会看到下一代云原生的数据系统。下一代的云原生数据仓应该具备实时在线的“增删改查”能力，在此基础上支持离在线一体化，既能做在线交互式分析和查询又能做复杂的离线ETL和计算，支持多维度的数据分析，这就是对云原生数据仓库的核心要求。 数据仓库当中的增删改查和TP数据库存在一定区别，因为对隔离机制的要求相比没有那么高，例如不需要做到snapshot isolation，因为是一个分析系统，但是一定要支持传统数据库的在线增删改查的能力，不是只能支持Batch Insertion的场景。 1）云原生数据仓库 数据仓库适用于范式化、有结构的数据处理，适用于已经Normalized数据管理和应用，已经有了非常清晰稳定的业务逻辑，需要范式化进行管理。 云原生数据仓库利用云原生架构对传统数据仓库进行升级和改造，资源池化、资源解耦实现弹性、高可用、水平拓展、智能化运维是云原生的核心本质之一。 如果把这些结合在一起，阿里云就是OSS、亚马逊就是S3，低成本的对象存储作为冷存储池,同时利用高效的云盘做一个本地的缓存，计算节点进行解耦，对本地节点进行加速，通过高速网络连成一个池，再对应用做统一的透明式服务。 AnalyticDB 云原生数据仓库 这个架构展开底下是对象存储，利用RAFT协议实现数据一致性，对每个计算节点的本地缓存加速利用ESSD弹性云盘。上面是计算池，在数据仓库为了实现大数据和数据库一体化，数据仓库领域的计算节点也需要将大数据的离线计算能力做得更强，离线大数据系统基本上都是基于BSP+DAG，传统数据库领域则是MPP架构，所以为了做到离在线一体化将MPP和BSP+DAG进行结合，做一个Hybrid的计算引擎，针对此再做一个Hybrid的查询和计算优化器。上面的是MetaData管理，力求做到原数据共享。 云原生数据仓库AnalyticDB MySQL AnalyticDB(ADB)就是基于这个思想设计的云原生数据仓库，ADB MySQL兼容MySQL这个生态，成为TPC-DS性能与性价比榜单第一。将交互式分析和复杂的离线ETL计算统一支持起来。ADB基于PG也做了另外一个版本，就是ADB for PG。针对传统数据仓库，例如TeraData、利用PG对Oracle的兼容性来做传统数据仓库的升级，利用云原生的架构，存储和计算分离，针对传统数据仓库进行云原生的升级改造，查询执行器和其他模块中做了大量优化。 云原生数据仓库AnalyticDB for PostgreSQL 例如向量化执行（vector execution）、Code Generation，ADB PG也支持把非结构化数据向量化变成高维向量数据以后处理，然后将向量数据和结构化数据在一个引擎当中进行处理实现非结构化数据和结构化数据的融合处理。ADB PG拿到了TPC-H性能和性价比榜单第一的成绩。 2）新一代数据仓库解决方案 基于此推出了新一代数据仓库的架构，底下是核心的云原生数据仓库ADB，上面是数据建模和数据资产管理，因为数据仓库领域不仅仅是引擎的问题，还包括建模等一系列问题。针对传统数据仓库做了升级到云原生数据仓库的解决方案，利用ADB、生态合作伙伴以及整个智能化工具实现一体化的解决方案。 DLA 云原生数据湖分析(Serverless，统一元数据+开放存储与分析计算) 数据源更加复杂与多样的场景是云原生数据湖和数据仓库最大的区别。数据湖的核心场景是对多源异构的数据源进行统一的管理和计算与分析处理。云原生数据湖拥有统一的界面对多源异构数据进行管理、计算和分析，核心点在于元数据管理和发现，集成不同的计算引擎对多源异构数据进行管理和分析。 Data Lake Analytics + OSS 云原生数据湖 上图为云原生数据湖分析Data Lake Analytics的架构，下面是对象存储或者其它不同的存储源，搭载Kubernetes+Container技术，通过serverless技术来做分析和计算，以及多用户之间的隔离安全保护，这样可以满足客户针对多源异构数据实现低成本、弹性的丰富的计算和分析处理需求。 2.3智能化、安全可信与生态工具 1）云原生+智能化数据库管控平台 智能化的数据管控平台利用云原生技术和人工智能技术进行智能化的数据库管理运维，包括分区、索引推荐、异常检测、慢SQL治理、参数调优等，这样可以大量提升管理运维的效率，我们研发了一个Database Autonomy Service模块(DAS)来实现数据库系统的自动驾驶，大幅度提升运维管控的效率。 2）云端全程加密数据永不泄露 除了传统的Access Control，传输与落盘加密，我们研发了全加密数据库，确保数据的绝对安全，结合安全硬件TEE来做到这一点，可以做到数据处理的全程加密。 3）数据库生态工具 除了前面提到的数据库应用迁移工具ADAM和数据库同步工具DTS，我们还提供了丰富的其他数据库生态工具，包括数据管理服务DMS和数据数据库备份服务DBS，可以提供数据血缘关系、数仓开发与建模、数据安全管理、数据备份容灾、CDM等一系列的企业级数据处理能力和面向开发者的服务能力。 4）数据库备份解决方案DBS DBS可以做传统数据多云多端的备份，把线下的数据备份到云上，也可以把云上的数据备份到线下，实现秒级RPO，支持多种数据源多源多端的云备份，并且支持Snapshot Recovery。 三、案例分析 1）双十一购物节•数据库挑战 上图为2020年“双十一”真实曲线，145倍的系统峰值瞬间迸发，利用云原生能力和分布式能力的结合可以完美平滑地支持“双十一”高并发海量数据的挑战。 2）中国邮政•大型传统商用数据库替换 中国邮政以前是基于传统的商业数据仓库，如今利用ADB云原生数仓进行升级，提供更可靠的离在线一体化计算分析能力，实现对全国数据寄递平台统一到一个系统的诉求。 3）某超大型部委客户 国税总局的全国税务数据统一系统应用，利用PolarDB-X分布式数据库以及DTS和ADB实现了从TP到AP数据处理、计算、分析、查询、处理一整套的解决方案，同时通过DMS来做数据开发和管理。支撑高并发、低延迟的复杂查询；支撑海量实时数据实时可见和高效入库；支持金融级别的精准计算。 4）阿里云数据库技术对抗新冠疫情 利用云原生数据库提供的弹性高可用和智能化运维能力，结合分布式去做水平拓展，为广大的企业和用户提供非常好的弹性高可用能力，疫情期间在线教育行业开始大规模地使用云原生、分布式的新一代数据库技术架构和产品实现降本增效对抗疫情。 5）客户案例•中国联通 中国联通的核心cBSS系统，针对传统的商业数据库进行升级改造，利用分布式数据库PolarDB-X的能力帮助实现这种核心的计费系统实时在线的交易数据处理。 6）客户案例•马来西亚电商巨头 PrestoMall 马来西亚的第三大电商PrestoMall，因为用传统的商业数据库Oracle成本太高，尤其是大促场景瞬间高并发的挑战，利用云原生数据库PolarDB对传统商业数据库进行升级改造，实现了TCO的大幅下降。 7）客户案例•国际广告商数据湖分析+计算解决方案 某国际领先广告厂商，文字、图片、和结构化数据等多源异构数据的处理无法统一到一个数据仓库里面进行，利用数据湖来做一个统一的分析引擎。利用DLA+OSS构建了新一代serverless数据湖，大大提升了对多源异构数据的访问处理和计算能力、同时节省了大量的计算成本。针对复杂丰富的计算分析场景，实现平滑的解决方案顺利从AWS迁移过来。 四、总结 上图为阿里云数据库的产品大图，从OLTP、OLAP、NoSQL到数据库生态工具与云原生智能化管控，阿里云希望利用丰富的云原生数据库产品体系为企业级客户和用户提供更好更可靠的产品与性价比更高的解决方案。 【相关阅读】 【内含干货PPT下载】DTCC 2020 | 阿里云叶正盛：数据库2025 【内含干货PPT下载】DTCC 2020 | 阿里云赵殿奎：PolarDB的Oracle平滑迁移之路 【内含干货PPT下载】DTCC 2020 | 阿里云朱洁：NoSQL最新技术发展趋势 【内含干货PPT下载】DTCC 2020 | 阿里云王涛：阿里巴巴电商数据库上云实践 【内含干货PPT下载】DTCC 2020 | 阿里云张鑫：阿里云云原生异地多活解决方案 DTCC 2020 | 阿里云梁高中：DAS之基于Workload的全局自动优化实践 【内含干货PPT下载】DTCC 2020 | 阿里云程实：云原生时代的数据库管理 【内含干货PPT下载】DTCC 2020 | 阿里云吉剑南：在线分析进入Fast Data时代的关键技术解读

一 、稳定大于一切 盒马的线下作业稳定性要求极高，假如门店pos无法付款了，排起的支付长队伍能让人把门店闹翻，假如配送员无法揽收了，在家里预定的午餐材料的饥肠辘辘的客户能把投诉电话打爆，甚至会形成广泛的社会舆论。盒马安全生产至关重要，稳定大于一切。​盒马配送智能调度负责将订单指派给骑手，是配送作业实操的第一环节，也是最重要的环节之一，假如调度出现问题，那么会导致大量订单超时履约，导致客户投诉，也会造成客户取消造成的销售资损。理论上系统不变更就会降低稳定性的风险，然而随着盒马配送提效降本的业务诉求和新业务的调度需求，以及配送智能调度上线两年来补丁重重导致的开发运维困难，急需系统架构重构，使得我们必须在高压下砥砺前行，对系统进行不断的重构改造，同时支撑日益发展的业务和提效降本的业务诉求。 配送智能调度系统今年系统完全重构一次，迁移了o2o、b2c、冷链等重要业务，上线了mall调度新需求，支撑了预调度和实时运力调度的提效降本需求，支撑了算法数据白盒化改造，在此基础上将继续耕耘，已产出了策略化运营方案、仿真改造方案和算法结果智能诊断方案，我们用实际行动表明，在系统飞速发展的同时，也能做到了智能调度系统全年0故障。 二、 智能调度链路分析 系统稳定性保障前提是要对系统关键链路了如指掌，关键链路包括对外依赖和我们提供的服务，因此在接手智能调度系统升级改造时，我们做了非常全面的智能调度的链路分析，并在不断上线新需求后，及时完善链路，使得我们不管在大促期间或者日常监控，不管是我们自己运维还是给团队伙伴运维backup都能了解系统全貌，基于统一链路图进行讨论，并在告警发生时能够分析和解决问题。 配送O2O智能调度涉及调度系统、压力系统、基础资料、骑手平台、算法策略、分布式计算、路径规划、单据分发等系统，涉及DTS、diamond、tair、作业DB、降级DB等存储和中间件，链路非常长，我们绘制了一张o2o智能调度时序图，基于同一张大图，产品、技术、测试、算法能在大促和系统变更前评估系统稳定性风险。 三、稳定性因素分析和实践 有了详细的系统调用链路，我们可以把链路中的每条线的稳定性按类别进行梳理。 3.1 DB依赖 （1）慢sql DB依赖主要分析依赖DB的稳定性，首先，DB有没有慢SQL，盒马早期大多数故障原因是慢sql导致，后来对DB的集中治理才使得这块不稳定因素被逐步瓦解，但是慢SQL治理是长期的事情，不管是上新业务的sql事前分析，还是流量自然增长需要做的DB定时check都至关重要。 （2）逻辑读行数多 有些sql不是慢sql，但是逻辑读非常大，比如超过10万行，那么这些sql在业务自然增长时很可能发展为慢sql，如果不治理，假以时日必定让你“刮目相看”。 （3）CloudDBA中的属性（cpu、内存、load、qps趋势） 查看DB的cpu是否正常，load是否比较高水位，是否有很多qps/tps尖刺。配送智能调度依赖的walle库在大促前发现db整体水位较低，但是cpu尖刺特别高,尖刺有到达60%，而且非常有规律，经过排查是一个网格任务没有离散导致。该问题咨询过DBA如果双11大促三倍流量，DB扛不住，幸好及时发现，紧急发布做了网格任务离散化。 （4）DB不隔离 DB不隔离常见有核心与非核心数据在一起，非核心qps高或者逻辑读高影响了整个DB的稳定性，配送从一个库拆分为核心、次核心、非核心、归档库，就是为了做到业务重要性分层。 冷热数据不隔离，一个不经常访问的超慢sql生成的报表使用了核心库，该case在盒马发展史上出现多次，常见的有统计报查询、报表导出使用了核心库。 读写不分离，上述报表类需求、前端展示类需求、看板类需求属于读业务，线下实操核心的是写DB，两者不隔离也会同样产生问题。 （5）DB降级 在智能调度系统中，DB依赖核心作业库中的单据，核心作业稳定性高于智能调度，为了保障核心作业稳定，我们为DB做了降级策略，用精卫同步一份数据到读库。DB降级主要衡量DB不稳定对该DB上业务的影响。 （6）上下游同一业务字段存在DB字段大小和类型不一致 上下游DB使用了同一业务字段但容量不一样会造成极端场景下数据无法写入。配送关联发货单字段是组合字段，包含批次关联的所有发货单，正常情况下一个批次关联1～3个发货单，在大促期间仓为了作业方便，关联了7个发货单，导致配送64位字符串超长，导致关联发货单无法写入，后来紧急变更，将字段改为256位得以解决。商品重量配送的字段是int，表示毫克，某次大促仓库将一瓶饮料录入为2吨（商品重量当时无业务应用场景，预留字段），配送子订单表存储了多瓶饮料的子订单，导致配送无法创建运单。 上下游同一业务字段要保持一致，如果有字段转义，需要做好字段截取、报警、应急预案，在保护好自己的同时，能快速解决异常case。 （7）DB容量、索引等 DBA单表建议小于500万，不用索引要删除，以免影响写入性能。 （8）DB变更导致 改索引、改字段类型、字段扩容会引起锁表，有的会影响主备同步，假如恰好有业务报表依赖备库，会造成业务报表不可用。凌晨做的数据结构变更没有设置停止时间，导致早上7点DB变更还没结束，影响了业务。数据变更批量改了gmt_modified时间，恰好有该字段的索引导致索引重建，影响库性能，所有依赖精卫都产生延迟。 DB变更要评估变更影响，自己拿不定主意的要找DBA确认，多找老司机咨询。 （9）db表非utf8mtd emoji格式文本存储到非mtd类型表后，查询导致emoj无法显示。 3.2 HSF依赖 （1）hsf服务超时 hsf超时时间不能设置太长，特别是高qps和高可用接口，hsf超时时间过长会导致hsf线程池打满，智能调度算法数据采集中，由于qps较高，同时访问ADB容易造成抖动，hsf服务的超时时间设置默认3秒导致hsf线程池打满，数据采集功能在预发环境中排查出不可用。 （2）hsf超时重试 由于网络抖动造成的hsf超时可通过重试避免，相对短的超时时间+重试机制比默认超时时间更可靠，在揽单上限hsf服务接口请求时，由于默认3秒超时和没有重试导致每天五百万服务揽单上限请求有25次左右失败率，使用了500ms重试+2次重试机制后一周失败量才1次。 （3）服务缓存 访问数据相对稳定的接口，并且耗时较长的接口需要设置前置缓存，减少访问依赖，同时保证稳定性。强依赖的接口，容易做缓存的接口需要设置后置缓存，当访问服务失败后能够请求缓存数据，同时每次请求成功需要更新缓存。 （4）服务降级 强依赖接口当服务不可用时需要设置降级机制，比如降级到上述缓存，或者降级到其他接口，降级到diamond，降级到内存等等，保证服务链路走通的同时，配合接口报警机制，即时发现依赖服务的问题。 （5）服务隔离 核心应用不能依赖非核心服务，同样，非核心应用不能依赖核心应用，两者都会造成核心服务被影响，配送仓配一体化调度和o2o智能调度同时使用walle-grid计算服务，但是一体化调度重要程度低，只影响调度效果，o2o服务重要程度高影响指派。我们通过版本号对服务进行隔离，如果有需要可根据分组规则或者自定义路由规则进行隔离。 （6）流量预估和压测 上新功能增加了依赖，或者会有较大新流量的，需要对流量进行预估，并且按流量进行单接口压测。配送批次组相似度打分服务上预调度功能时，预估增加0.5倍批次，两两计算的笛卡尔积是2.25，估计全量开预调度增加3倍以内流量，当前系统在不增加机器情况下可以扛住洪峰，实际开启预调度后验证无问题。 3.3 HSF服务提供 （1）服务超时 相应的服务提供者要提供相对可控的超时时间，以防被人把线程池打满，承诺的超时时间可根据系统压测后得到，或者通过线上鹰眼的统计给出一个相对靠谱的超时时间，并不断优化，默认3秒的超时在高稳定要求领域尽量少用。 （2）限流 除了设置相对靠谱的超时时间，还需要对服务能够提供的流量进行限定，核心服务一定要增加sentinel做限流。sentinel可根据单机限流，粒度可以是qps或者hsf线程数。一般按qps限流较多，微服务也可按线程数限流。 智能调度请求骑手服务，正常情况下骑手服务性能很高，简单的db的uk查询，按理说该服务不会有问题，某次大促时db发生了主备切换（DB当时非单实例，其他DB影响了），导致长时间db不可用，高qps流量过来把骑手服务应用线程池打满，通过限流措施截断流量，这时上游调度系统使用后置缓存正常返回，如果没有限流，骑手服务导致线程池被打满，整体系统将陷入不可用状况。 （3）幂等 上游服务重试，下游保证幂等，幂等包含简单单据幂等，也有比较复杂的幂等逻辑，比如批量请求的接口。和上游约定好幂等逻辑，以及幂等返回值。幂等要返回成功，服务端自己吃掉异常。 （4）服务缓存 服务提供者通过前置缓存提高系统支撑流量，可应用于返回值相对稳定的服务，服务缓存是否设置前置缓存可根据缓存命中率评估，有的为了支撑高qps流量但缓存命中率低也可考虑。配送某个打分服务是一个笛卡尔积类型的服务，n个单据就有n*(n-1)/2次调用，假如20秒调用一次，这时候设置1分钟缓存，理论命中率虽然只有67%，但提高了2倍流量，可有效减少机器数量。 服务后置缓存通常用来做服务降级逻辑，揽单上限这个核心服务，有三级兜底逻辑，分别是骑手值、城市值、内存值，保证服务端的高可用。 （5）服务隔离：同上 （6）流量预估和压测：同上 3.4 tair依赖 （1）tair各种产品适用场景 MDB是常用的缓存，常用扛高qps，但是MDB不保证持久化，MDB分单集群和独立集群，独立集群有两个集群数据存储完全独立，不能保证数据缓存后能被访问到，MDB不适合用分布式锁。LDB持久化存储，非此场景都不需要用。RDB有同步淘汰策略，当容量不够时会触发该策略，导致写入延迟。批量接口单次请求限制在1024个，建议批量接口单次请求不超过100个。 （2）缓存容量和qps 缓存容量和qps不足时要扩容，MDB一般可支持qps 100万，RDB10万。 （3）吞吐量 tair都任何场景都不适合大key和大value的情况，key 1k，value不超过10k，极端情况下会造成数据被拆分，导致数据丢失，批量写入要减少批次数，skey不超过5120。 （4）缓存超时 缓存一定要设置超时时间，单位是秒，新同学有认为单位毫秒导致超时时间过长缓存超容量的情况。 （5）独立集群和单集群 MDB独立集群两个集群完全独立，na61只提供给61机房的系统访问，62访问不到，由于独立集群的问题，会导致缓存数据访问不到。 （6）tair分布式锁 tair锁使用put和get方法，锁的version从2开始，锁要考虑超时情况，可通过重试机制避免超时造成的影响，锁网络超时的ResultCode返回值可能ResultCode.CONNERROR,ResultCode.TIMEOUT,ResultCode.UNKNOW。 （7）缓存数据一致性 简单的一致性问题比如DB和缓存，db更新成功后可多增加几个通道保证db执行成功后发出消息，缓存做好幂等，考虑系统挂了的情况可以依赖db变更的精卫消息或者binlog消息做数据对账。 我们遇到的一致性问题比较隐蔽，某个打分服务做缓存减少笛卡尔积计算，最开始设置缓存Key是单据，value是相似度分数对象，但是算法在使用单据对象的时候，相似度分数类包含了已分配单据对应到站骑手，假如为骑手1，第二次计算的时候，还是拿到的骑手1，但是骑手1已经离站了，导致一个NP问题，后改成单据+骑手的缓存key才解决该问题。 总结一下，会被上下文修改的对象不适合做缓存，缓存对象要做到粒度小，且不被上下文改变。 （8）缓存击穿 缓存失效访问DB是一件高风险的事情，特别是高qps情况下，非常容易把DB搞挂，当缓存击穿之时就是故障来临之日。设置热点数据延长过期时间，稳定的数据使用内存缓存兜底，使用加锁策略保护db，db访问限流等。 3.5 Metaq依赖 （1）Metaq consumer线上未注册 该问题会导致注册后批量消息发送。在消息平台中短信业务接入后忘记去线上订阅导致订阅时短信一起发出去，造成业务大大的黑人问号。可以通过低峰期清理topic的消息后，再进行订阅。 （2）metaq size限制 单条消息限制128k，超过该限制会发送失败。 （3）metaq 发送失败 虽然metaq比较稳定，但是偶尔会有metaq发送时失败的case，可能是metaq broker集群抖动，网络问题等，重要的Metaq消息发送要做发送失败监控，可通过手动补发，或者通过消息对账，自动重试。 （4）metaq 消费失败 消费最多重试16次，最大重试间隔2小时，可修改重试间隔减少重试时间，可以设置Metaq循环重试，超过15次后再发送一条metaq，形成metaq循环，不建议死循环，可通过消费时间进行控制。 （5）metaq qps/tps 发送和消费的单topic qps/tps都应小于3000，某次topic tps超过3000被Metaq同学钉钉通知，最后发现是一些废弃的blink任务在写，停止后重启metaq恢复。 （6）metaq 堆积监控 metaq堆积一般是由于业务系统自身处理失败引起的，少部分原因是metaq的服务端问题导致部分通道无法消费，metaq平台可配置消费堆积监控，默认值1万条，重要业务可设置相对较少的堆积条数，比如设置1000条上限左右。 3.6 精卫依赖 （1）精卫数据传输乱码导致无法写入DB json字段 db有个字段是json格式，通过精卫传输到读库时，由于中文解析问题导致json格式被破坏，无法写入db，db字段慎用json格式。 （2）精卫延迟 DB变更，DB索引不一致，字段不一致等导致精卫延迟或者精卫自身问题导致延迟，重要业务需要配置延迟报警，在DBA和精卫同学双方确认下，可以加大写入并发，扩大精卫同步tps，追赶延迟数据。 （3）精卫暂停任务 精卫任务暂停可设置检测自动重启，或者订阅精卫delay监控，手动重启任务。 3.7 DTS依赖 （1）DTS 网格任务/并行任务离散化 并行类任务需要考虑下游的承载能力做离散化，否则会造成qps热点。 （2）DTS 降级 可实现一个本地分布式调度任务，在DTS不可用时可降级。 （3）DTS监控 设置DTS超时监控，DTS返回失败监控，DTS没有正常启动监控，除了中间件级别的监控以外，还应该设置DTS运行的应用级别调用量监控，在量级稳定的情况下，DTS每分钟的调度次数应该在阈值之内。 3.8 开关 （1）开关推送检查和监控 开关推送要检查是否生效，推送完开关后要刷新开关页面，查看当前值，最好做一个开关生效日志监控，推送开关后查看日志是否所有机器都生效。 （2）多个diamond分批发布开关 多个diamond开关分批发布要注意，某个开关分批发布暂停时，其他开关发布无法生效，需等待其他开关发布完成。 （3）开关初始化 开关编码时要注意初始化影响，在系统启动时，被依赖的开关没有初始化会有NP风险。 （4）开关多线程影响 我们的开关基本都是单例在多线程环境中使用，开关发布要注意数据的可见性，比较复杂的数组或map结构，推荐使用影子实例完成开关状态变更。 （5）开关接入changefree 开关变更最好接入changefree，审批人要设置多个，以防紧急开关推送和开关回滚找不到联系人。 3.9 监控 （1）流量监控 流量监控包括提供的服务的qps，依赖服务的qps，周期任务的执行次数等，流量监控反应业务稳定期间的大致流量。配置监控包括周同比、天环比、流量阈值。流量监控需要不断评估和探索业务在合理变化范围，可用odps统计近一个月的数据，设置相应监控值。 （2）错误数量/成功率监控 有些业务流量较低，重要层度却很高，这时候错误数量和成功率监控是最合适的，可以按照分钟均值来统计，避免网络原因或系统load抖动造成的正常服务失败。 （3）错误原因监控 错误原因监控可快速定位业务错误，错误日志按照固定格式打印，错处原因数量按错误分类计数。 （4）RT监控 RT是服务时长，反应服务的当前健康度，可按照分钟均值统计，避免网络原因或系统load抖动造成的正常服务失败。 （5）大盘 P级故障具备监控条件的都需要配置在监控大盘，监控大盘能够总览所有系统业务监控指标，快速定位具体问题。 （6）系统异常监控 可对所有系统配置NP错误监控、数据越界监控、类型转换错误，此类runtime错误肯定是系统bug导致，很可能是发布导致的问题，配置该监控能够第一时间发现发布的问题。 3.10 灰度 （1）系统对服务有多次状态依赖不可分布发布 一个链路中两次依赖系统中的状态值（db或tair或内存或其他存储），系统正在发布中，两次依赖导致访问了两个不同的状态值，状态不一致阻塞了系统链路。在很多下线作业场景，灰度的粒度是以业务划分粒度的，而不是以流量，因此某些场景下使用业务单元灰度较合适。 （2）切流前评估流量 在大规模切流前，要评估系统即将承受的流量，在前期切10%左右流量后，能够近似的根据业务特征对后面90%流量作出合理评估。评估流量后可使用压测评估机器是否能扛住后续流量。 （3）灰度预期和方案回滚 灰度要有业务预期和系统预期，业务预计比如是否按产品流程执行完成，是否灰度流量覆盖了所有TC的case，系统预期比如是否系统error数同比和环比一致，是否有新增的异常，是否有NP错误。 灰度不符合预期需要立即回滚，不用考虑任何原因和后果，事后再做分析。预调度灰度期，正好盒马封网，经过层层审批才上线灰度一个站点，灰度开始10分钟内业务表现正常，但是系统出现了未曾出现的错误日志，随后出现预调度批次不指派，我们立即进行回滚。事后分析了一整天（只在低峰期出现），是缓存对象被改变了导致NP错误。 3.11 测试 （1）预发空跑验证 预发造测试站点流量，验证功能可行性，预发空跑是测试验证前期要完成的，按照TC造多个case，验证是否符合预期。 （2）预发引流验证 预发从线上引导流量，验证产品逻辑，预发从线上引流是为了用大流量验证系统功能。像智能调度如此长的链路，我们用引流可以验证一些数据难造的场景，以及TC之外的场景 （3）线上引流比对 可单独为线上站点开起新调度和老调度，并对业务最终指派结果进行比对，从日志上分析行为差异性，是正常的时延差异还是系统bug。还可按照统计学的方法对系统核心指标进行比对分析。 3.12 应急响应 没有完美设计的系统，bug总是存在，当出现线上问题的时候如何应急处理呢？为了避免线上问题出现时手忙脚乱，需要做好“天晴修屋顶”，这里的“修”既包含上述架构治理、监控完善，也包含应急预案梳理和故障演练。 （1）应急预案梳理 应急预案包括系统上的开关、限流工具、降级预案等也包含业务测的应急响应措施，在系统短期无法恢复时，也能正常作业下去，比如配送小票作业，能在配送系统无法揽收时，通过小票完成货物揽收和配送。 系统上的预案要做到事前验证，在预案上线后验证预案的有效性；一键推送，通过预案平台能够一键触达，快速生效预案；组织培训，预案要深入人心，让组内每个同学都掌握如何操作，以及何时操作。 （2）故障演练 为了避免故障来临时人心慌乱，提高决策效率，缩短问题定位时间，需要在平常做好故障演练。故障演练要当作线上故障对待，由测试在安全生产环境发起，故障演练要做到真实，演练要保密，推荐测试和开发人员使用红蓝对抗实践故障演练。 为了提高开发应急运维能力，需要有一套故障应对响应机制，盒马配送从组织、发现、决策、善后四个角度出发，沉淀了一套故障应急响应方法，在故障来临之际要组织团队leader和团队成员停下手头工作，All In故障处理，首先建立沟通群，其次从大盘监控发现问题点，然后针对问题点决策执行相应预案，当报警恢复时再评估影响面，是否存在故障引起的遗留问题。 （3）故障处理 经过多次故障演练，能有效培养团队故障发生的应急运维能力，故障发生时切记不要盲目的分析故障原因，而是应以最快速度止血和恢复。80%以上的故障是由变更引起，不管是发布、开关推送、新增配置、上下游有发布等等，少部分是由于流量增长和其他上下文环境变化引起。如果发生故障时存在变更，则需第一时间回滚，如果是其他原因，那么可根据系统症状，决策推预案、重启、扩容等，如果无上述措施，则要分工合作，组织人对外沟通、排查日志、检查DB、查看服务流量、分析链路trace等，以最快的速度定位问题。 四、总结 智能调度在不停发展中，我们接下来还有策略运营、智能诊断、仿真等进行中的项目，除了已有的稳定性作战经验之外，我们还将继续迎接新的稳定性挑战，探索不同环境下稳定性最佳实践。

产品简介 DRDS 是一款基于 RDS for MySQL 、采用分库分表技术进行扩展的分布式 OLTP 数据库服务产品，产品目标旨在提升数据存储容量、并发吞吐、复杂计算效率三个方面的扩展性需求。 DRDS 核心能力采用标准关系型数据库技术实现，构建与公共云( cloud native )，配合完善的管控运维及产品化能力，使其具备稳定可靠、高度可扩展、持续可运维、类传统单机 MySQL 数据库体验的特点。 DRDS 在公共云和专有云沉淀多年，历经各界天猫双十一核心交易业务及各行业阿里云客户业务的考验。承载大量用户核心在线业务，横跨互联网、金融&支付、教育、通信、公共事业等多行业，是阿里巴巴集团内部所有在线核心业务及众多阿里云客户业务接入分布式数据库的事实标准。 产品特点 稳定 对于绝大部分应用而言，关系型数据库所承担的职责是整个数据管理系统中最为核心基础的，不光直接影响到终端用户的服务体验，同时也是业务数据的最后一道保险，所以稳定性是数据库最为核心的选型因素。 DRDS 的稳定性建立在对久经考验的 MySQL 合理使用的基础上，单机 MySQL 在高并发、大量数据存储和复杂计算场景下，呈现出相对弱势的状态。 DRDS 将数据拆分到多个 RDS MySQL，使每个 RDS MySQL 承担合适的并发、数据存储和计算负载，各个 RDS MySQL 处于稳定状态，DRDS 层面处理分布式逻辑a，最终得到一个具有稳定可靠、高度扩展性的分布式关系型数据库系统。 相比于全自研分布式 NewSQL 数据库，DRDS 产品始终以持续稳定性和可运维性作为第一要务，同时通过标准数据库技术弥补与单机数据库的体验差异，让用户便捷、快速地上手使用，充分发挥产品的业务价值。 高度可扩展 相比传统单机关系型数据库，DRDS 采用分层架构可确保在并发、计算、数据存储三个方面均可线性扩展，通过增加 DRDS 节点 和 RDS for MySQL 实例达到水平扩展效果。 相比基于分布式存储的新型 cloud native 数据库，理论上 DRDS 的扩展性没有上限，打消业务在快速发展的过程中针对数据库扩展性产生的后顾之忧与运维压力。 持续可运维 关系型数据库对于绝大部分应用而言需要 7 * 24 小时稳定工作，持续可运维是数据库的核心关键能力。 DRDS 在公共云和专有云持续深耕多年，提供丰富的产品化能力及完备的运维体系，通过完整的 OpenAPI 可让业务自行定时与集成。 生命周期管理 实例创建、重启、释放 数据库创建、删除 数据白屏化操作 容量管理 水平拆分、垂直拆分 读写分离 分析型只读实例 并发型只读实例 弹性变配 平滑扩容、热点扩容 拆分变更 安全与审计 VPC IP 白名单 账号与权限管理 SQL 审计与分析 容灾管理 一体化备份恢复(快速&一致性) SQL 闪回 表回收站 多可用区实例容灾部署 监控告警 自有分层监控 云监控接入与关键指标报警管理 数据生态 DTS 数据迁移、同步、订阅 数据集成 DMS 数据管理 QuickBi 集成 搜索OpenSearch、Elasticsearch 大数据计算与数据仓库 标准类关系型数据库能力 传统关系型数据库具备良好的用户认知和使用习惯，DRDS 采用标准关系型数据库技术实现，在提供分布式扩展能力的基础之上，大幅兼容单机 MySQL 使用体验。 通过 RDS for MySQL 提供稳定的存储支持，DRDS 内核专注于分布式 SQL 层，整个分布式 SQL 层如同大部分单机关系型数据库，分为网络和协议层、SQL 解析层、优化层和执行层。其中优化层包含逻辑优化和物理优化，执行层包含单机两阶段执行、单机并行执行( Parallel Query )和多机并行执行( DAG )，采用多种传统单机数据库优化和执行技术。 与单机数据库不同的是，DRDS 将数据拆分逻辑加入到了 SQL 优化和执行过程中，与其他分布式数据库不同的是，在面向 OLTP 场景时，DRDS 着重关注因分布式而带来的代价，提供了包括自定义数据拆分、算子 move-arround 和 pushdown、join 和 aggregation 的 co-located 优化和计算、分布式事务的处理和优化、分布式全局二级索引、面对远超单机数据容量的外置 DAG 计算等技术。 适用场景 按应用类型选择 DRDS 能够很好的服务面向个人客户、消费者、设备的事务型业务，关注响应时间，SQL 偏向点查点写，具备较高并发特征，类似互联网、移动互联网、互联网+业务(通信、支付&金融、教育、出行、零售餐饮等)有非常好的效果。 针对传统的企业级应用，因为数据不断扩充，急需更强计算能力的在线事务数据库，DRDS 最近两年在复杂 SQL 优化、并行执行、分布式事务等方面进展较大，很好的满足这种诉求，因为天然的数据分片，数据处理并行度效果不错。 按容量选择 OLTP 业务领域，容量包含并发度、数据存储、复杂 SQL 响应时间 3 个维度。任意一个维度已经出现问题，或者按照业务规划，在不久的未来就会出现。那么 DRDS 是一个合适的选择。 对于业务发展初期选择分布式还是不选择分布式，总会面临很多考量，但是从数据库角度出发来看，业务使用的 SQL、数据类型、事务、索引、其他功能是确定的，对于大部分业务来说，只要 SQL 支持度、数据类型、事务、索引支持比较完整，并且有有效手段在各种极端情况下具备能力扩展，那么这项技术对于业务的未来发展，较低概率存在瓶颈效应，相反，它可能是所有方案中最有生命力的方式。 按成本选择 业务对于数据库的成本考量，分为 3 个部分， 1、业务开发上手使用难度， 2、长期稳定性和性能表现， 3、服务持有成本。 业务开发上手难度过高，往往会导致项目延期，业务效果差强人意。对于一个新型数据库而言，如何有效兼容现有流行数据库使用习惯、功能支持完整度至关重要。DRDS 兼容 MySQL 生态，对于主流的客户端、驱动有着较好兼容性，SQL 兼容层面，已经比较少碰到功能报错问题，业务迅速进行功能对接成为可能。 长期稳定性和性能表现，因为 DRDS 将数据、负载分担到多个 RDS 中，所以面对逐步加大的工作负载，DRDS 相比大规格单机数据库有着更好的稳定性表现，性能表现层面，因为天然分布式，并发表现是其强项，配合单机并行计算、多机 DAG 计算，能够覆盖大部分在线数据的复杂计算需求。 服务持有成本方面，按照相等负载对标其他方案, DRDS 使用相对低配 RDS ，展现出的成本曲线随着 RDS 数量上升，相比其他方案,成本曲线趋向平缓。DRDS 的客户群体中，不乏 1 个 DRDS 下挂载几十个 RDS 实现数据高效存取和计算的需求。 按应用生命周期发展选择 DRDS 除了提供水平拆分能力，也提供了垂直拆分能力，并且应对极端热点，提供热点拆分能力，很好的满足了业务在整个生命周期中对数据库的诉求，可在业务发展的各个阶段切入。每个阶段的转换，DRDS 又提供各项能力保驾护航。 产品架构 业务架构 DRDS 在业务构建数据管理体系所处的位置如下图所示， DRDS 承担业务面向在线事务数据存取与计算的诉求，通过数据集成、数据传输产品，和缓存产品、大数据生态配合使用。 内核架构 DRDS 使用体验兼容 MySQL 体系 , 采用标准关系型数据库技术实现，并且大幅度增强其适应分布式场景的能力，因为有 MySQL 存储支持，所以 DRDS 内核技术能力展现主要是在分布式 SQL 层。 整个分布式 SQL 层如同大部分传统单机关系型数据库，分为网络和协议层、SQL 解析层、优化层和执行层，其中优化层包含逻辑优化和物理优化，执行层包含单机两阶段执行、单机并行执行和多机并行执行，应用了多种传统单机数据库优化和执行技术。 和单机数据库不同的是，DRDS 将数据拆分逻辑加入到了 SQL 优化和执行过程中，并且和其他分布式数据库不同的是，在面向 OLTP 场景时，DRDS 特别关注分布式所带来的代价，提供了包括数据拆分的可定制化(指定拆分字段和算法)、算子 move-arround 和 pushdown 、 join 和 aggregation 的 co-located 优化和计算 、分布式事务的处理和优化、分布式全局二级索引、面对远超单机数据容量的外置 DAG 计算等核心技术。 部署架构 DRDS 服务部署在公有云上，采取多种方式确保生产安全，其中包括 支持 VPC、IP 白名单、非对称账号密码、TLS 等方式，确保数据服务安全 使用独享高性能物理资源、实例间充分隔离、支持多可用区实例，确保数据服务稳定 支撑系统采用多 region 隔离部署、核心数据服务 SLA 与管控 SLA 解绑，确保不出现系统性问题 目前 DRDS 已经在国内大部分 region 部署，并且具备海外输出能力，逐步开放海外各 region , 助力业务区域扩张。 了解更多 分布式关系型数据库服务 DRDS，领军客户实战场景 实例规格 版本说明 上手指南

李艳鹏 易宝支付平台架构师，专注线上和线下支付平台的应用架构和技术架构的规划与落地，负责交易、支付、渠道、账务、计费、风控、对账等系统的设计与实现，在移动支付、聚合支付、合规账户、扫码支付、标记化支付等业务场景上有产品应用架构规划的经验。 1 背景 一致性是一个抽象的、具有多重含义的计算机术语，在不同应用场景下，有不同的定义和含义。在传统的IT时代，一致性通常指强一致性，强一致性通常体现在你中有我、我中有你、浑然一体；而在互联网时代，一致性的含义远远超出了它原有的含义，在我们讨论互联网时代的一致性之前，我们先了解一下互联网时代的特点，互联网时代信息量巨大、需要计算能力巨大，不但对用户响应速度要求快，而且吞吐量指标也要向外扩展（既：水平伸缩），于是单节点的服务器无法满足需求，服务节点开始池化，想想那个经典的故事，一只筷子一折就断，一把筷子怎么都折不断，可见人多力量大的思想是多么的重要，但是人多也不一定能解决所有事情，还得进行有序、合理的分配任务，进行有效的管理，于是互联网时代谈论最多的话题就是拆分，拆分一般分为“水平拆分”和“垂直拆分”（大家不要对应到数据库或者缓存拆分，这里主要表达一种逻辑）。这里，“水平拆分”指的是同一个功能由于单机节点无法满足性能需求，需要扩展成为多节点，多个节点具有一致的功能，组成一个服务池，一个节点服务一部分的请求量，团结起来共同处理大规模高并发的请求量。“垂直拆分”指的是按照功能拆分，秉着“专业的人干专业的事儿”的原则，把一个复杂的功能拆分到多个单一的简单的元功能，不同的元功能组合在一起，和未拆分前完成的功能是一致的，由于每个元功能职责单一、功能简单，让维护和变更都变得更简单、安全，更易于产品版本的迭代，在这样的一个互联网的时代和环境，一致性指分布式服务化系统之间的弱一致性，包括应用系统一致性和数据一致性。 无论是水平拆分还是垂直拆分，都解决了特定场景下的特定问题，凡事有好的一面，都会有坏的一面，拆分后的系统或者服务化的系统最大的问题就是一致性问题，这么多个具有元功能的模块，或者同一个功能池中的多个节点之间，如何保证他们的信息是一致的、工作步伐是一致的、状态是一致的、互相协调有序的工作呢？ 本文根据作者在互联网企业的实际项目经验，对服务化系统中最难解决的一致性问题进行研究和探讨，试图从实践经验中找到规律，抽象出模式，分享给大家，希望对大家的项目实施有所帮助，在对实践的总结中也会对相关的一致性术语做最朴实的解释，希望能帮助大家彻底理解一致性的本质，并能将其应用到实践，解决读者现实中遇到的服务化系统的一致性问题，本文使用理论与实践相结合的方法，突出在实践中解决问题的模式，因此叫做《分布式服务化系统一致性的“最佳实干”》。 2 问题 本节列举不一致会导致的种种问题，这也包括一例生活中的问题。 案例1：买房 假如你想要享受生活的随意，只想买个两居，不想让房贷有太大压力，而你媳妇却想要买个三居，还得带花园的，那么你们就不一致了，不一致导致生活不愉快、不协调，严重情况下还会吵架，可见生活中的不一致问题影响很大。 案例2：转账 转账是经典的不一致案例，设想一下银行为你处理一笔转账，扣减你账户上的余额，然后增加别人账户的余额；如果扣减你的账户余额成功，增加别人账户余额失败，那么你就会损失这笔资金。反过来，如果扣减你的账户余额失败，增加别人账户余额成功，那么银行就会损失这笔资金，银行需要赔付。对于资金处理系统来说，上面任何一种场景都是不允许发生的，一旦发生就会有资金损失，后果是不堪设想的，严重情况会让一个公司瞬间倒闭，可参考案例。 案例3：下订单和扣库存 电商系统中也有一个经典的案例，下订单和扣库存如何保持一致，如果先下订单，扣库存失败，那么将会导致超卖；如果下订单没有成功，扣库存成功，那么会导致少卖。两种情况都会导致运营成本的增加，严重情况下需要赔付。 案例4：同步超时 服务化的系统间调用常常因为网络问题导致系统间调用超时，即使是网络很好的机房，在亿次流量的基数下，同步调用超时也是家常便饭。系统A同步调用系统B超时，系统A可以明确得到超时反馈，但是无法确定系统B是否已经完成了预定的功能或者没有完成预定的功能。于是，系统A就迷茫了，不知道应该继续做什么，如何反馈给使用方。（曾经的一个B2B产品的客户要求接口超时重新通知他们，这个在技术上是难以实现的，因为服务器本身可能并不知道自己超时，可能会继续正常的返回数据，只是客户端并没有接受到结果罢了，因此这不是一个合理的解决方案）。 案例5：异步回调超时 此案例和上一个同步超时案例类似，不过这个场景使用了异步回调，系统A同步调用系统B发起指令，系统B采用受理模式，受理后则返回受理成功，然后系统B异步通知系统A。在这个过程中，如果系统A由于某种原因迟迟没有收到回调结果，那么两个系统间的状态就不一致，互相认知不同会导致系统间发生错误，严重情况下会影响核心事务，甚至会导致资金损失。 案例6：掉单 分布式系统中，两个系统协作处理一个流程，分别为对方的上下游，如果一个系统中存在一个请求，通常指订单，另外一个系统不存在，则导致掉单，掉单的后果很严重，有时候也会导致资金损失。 案例7：系统间状态不一致 这个案例与上面掉单案例类似，不同的是两个系统间都存在请求，但是请求的状态不一致。 案例8：缓存和数据库不一致 交易相关系统基本离不开关系型数据库，依赖关系型数据库提供的ACID特性（后面介绍），但是在大规模高并发的互联网系统里，一些特殊的场景对读的性能要求极高，服务于交易的数据库难以抗住大规模的读流量，通常需要在数据库前垫缓存，那么缓存和数据库之间的数据如何保持一致性？是要保持强一致呢还是弱一致性呢？ 案例9：本地缓存节点间不一致 一个服务池上的多个节点为了满足较高的性能需求，需要使用本地缓存，使用了本地缓存，每个节点都会有一份缓存数据的拷贝，如果这些数据是静态的、不变的，那永远都不会有问题，但是如果这些数据是半静态的或者常被更新的，当被更新的时候，各个节点更新是有先后顺序的，在更新的瞬间，各个节点的数据是不一致的，如果这些数据是为某一个开关服务的，想象一下重复的请求走进了不同的节点（在failover或者补偿导致的场景下，重复请求是一定会发生的，也是服务化系统必须处理的），一个请求走了开关打开的逻辑，同时另外一个请求走了开关关闭的逻辑，这导致请求被处理两次，最坏的情况下会导致灾难性的后果，就是资金损失。 案例10：缓存数据结构不一致 这个案例会时有发生，某系统需要种某一数据结构的缓存，这一数据结构有多个数据元素组成，其中，某个数据元素都需要从数据库中或者服务中获取，如果一部分数据元素获取失败，由于程序处理不正确，仍然将不完全的数据结构存入缓存，那么缓存的消费者消费的时候很有可能因为没有合理处理异常情况而出错。 3 模式 3.1 生活中不一致问题的解决 大家回顾一下上一节列举的生活中的案例1-买房，如果置身事外来看，解决这种不一致的办法有两个，一个是避免不一致的发生，如果已经是媳妇了就不好办了:)，还有一种方法就是慢慢的补偿，先买个两居，然后慢慢的等资金充裕了再换三居，买比特币赚了再换带花园的房子，于是问题最终被解决了，最终大家处于一致的状态，都开心了。这样可以解决案例1的问题，很自然由于有了过渡的方法，问题在不经意间就消失了，可见“过渡”也是解决一致性问题的一个模式。 从案例1的解决方案来看，我们要解决一致性问题，一个最直接最简单的方法就是保持强一致性，对于案例1的情况，尽量避免在结婚前两个人能够互相了解达成一致，避免不一致问题的发生；不过有些事情事已至此，发生了就是发生了，出现了不一致的问题，我们应该考虑去补偿，尽最大的努力从不一致状态修复到一致状态，避免损失全部或者一部分，也不失为一个好方法。 因此，避免不一致是上策，出现了不一致及时发现及时修复是中策，有问题不积极解决留给他人解决是下策。 3.2 酸碱平衡理论 ACID在英文中的意思是“酸”，BASE的意识是“碱”，这一段讲的是“酸碱平衡”的故事。 1. ACID（酸） 如何保证强一致性呢？计算机专业的童鞋在学习关系型数据库的时候都学习了ACID原理，这里对ACID做个简单的介绍。如果想全面的学习ACID原理，请参考ACID。 关系型数据库天生就是解决具有复杂事务场景的问题，关系型数据库完全满足ACID的特性。 ACID指的是： A: Atomicity，原子性 C: Consistency，一致性 I: Isolation，隔离性 D: Durability，持久性 具有ACID的特性的数据库支持强一致性，强一致性代表数据库本身不会出现不一致，每个事务是原子的，或者成功或者失败，事物间是隔离的，互相完全不影响，而且最终状态是持久落盘的，因此，数据库会从一个明确的状态到另外一个明确的状态，中间的临时状态是不会出现的，如果出现也会及时的自动的修复，因此是强一致的。 3个典型的关系型数据库Oracle、Mysql、Db2都能保证强一致性，Oracle和Mysql使用多版本控制协议实现，而DB2使用改进的两阶段提交协议来实现。 如果你在为交易相关系统做技术选型，交易的存储应该只考虑关系型数据库，对于核心系统，如果需要较好的性能，可以考虑使用更强悍的硬件，这种向上扩展（升级硬件）虽然成本较高，但是是最简单粗暴有效的方式，另外，Nosql完全不适合交易场景，Nosql主要用来做数据分析、ETL、报表、数据挖掘、推荐、日志处理等非交易场景。 前面提到的案例2-转账和案例3-下订单和扣库存都可以利用关系型数据库的强一致性解决。 然而，前面提到，互联网项目多数具有大规模高并发的特性，必须应用拆分的理念，对高并发的压力采取“大而化小、小而化了”的方法，否则难以满足动辄亿级流量的需求，即使使用关系型数据库，单机也难以满足存储和TPS上的需求。为了保证案例2-转账可以利用关系型数据库的强一致性，在拆分的时候尽量的把转账相关的账户放入一个数据库分片，对于案例3，尽量的保证把订单和库存放入同一个数据库分片，这样通过关系型数据库自然就解决了不一致的问题。 然而，有些时候事与愿违，由于业务规则的限制，无法将相关的数据分到同一个数据库分片，这个时候我们就需要实现最终一致性。 对于案例2-转账场景，假设账户数量巨大，对账户存储进行了拆分，关系型数据库一共分了8个实例，每个实例8个库，每个库8个表，共512张表，假如要转账的两个账户正好落在了一个库里，那么可以依赖关系型数据库的事务保持强一致性。 如果要转账的两个账户正好落在了不同的库里，转账操作是无法封装在同一个数据库事务中的，这个时候会发生一个库的账户扣减余额成功，另外一个库的账户增加余额失败的情况。 对于这种情况，我们需要继续探讨解决之道，CAP原理和BASE原理，BASE原理通过记录事务的中间的临时状态，实现最终一致性。 2. CAP（帽子理论） 如果想深入的学习CAP理论，请参考CAP。 由于对系统或者数据进行了拆分，我们的系统不再是单机系统，而是分布式系统，针对分布式系的帽子理论包含三个元素： C：Consistency，一致性, 数据一致更新，所有数据变动都是同步的 A：Availability，可用性, 好的响应性能，完全的可用性指的是在任何故障模型下，服务都会在有限的时间处理响应 P：Partition tolerance，分区容错性，可靠性 帽子理论证明，任何分布式系统只可同时满足二点，没法三者兼顾。关系型数据库由于关系型数据库是单节点的，因此，不具有分区容错性，但是具有一致性和可用性，而分布式的服务化系统都需要满足分区容错性，那么我们必须在一致性和可用性中进行权衡，具体表现在服务化系统处理的异常请求在某一个时间段内可能是不完全的，但是经过自动的或者手工的补偿后，达到了最终的一致性。 3. BASE（碱） BASE理论解决CAP理论提出了分布式系统的一致性和可用性不能兼得的问题，如果想全面的学习BASE原理，请参考Eventual consistency。 BASE在英文中有“碱”的意思，对应本节开头的ACID在英文中“酸”的意思，基于这两个名词提出了酸碱平衡的结论，简单来说是在不同的场景下，可以分别利用ACID和BASE来解决分布式服务化系统的一致性问题。 BASE模型与ACID模型截然不同，满足CAP理论，通过牺牲强一致性，获得可用性，一般应用在服务化系统的应用层或者大数据处理系统，通过达到最终一致性来尽量满足业务的绝大部分需求。 BASE模型包含个三个元素： BA：Basically Available，基本可用 S：Soft State，软状态，状态可以有一段时间不同步 E：Eventually Consistent，最终一致，最终数据是一致的就可以了，而不是时时保持强一致 BASE模型的软状态是实现BASE理论的方法，基本可用和最终一致是目标。按照BASE模型实现的系统，由于不保证强一致性，系统在处理请求的过程中，可以存在短暂的不一致，在短暂的不一致窗口请求处理处在临时状态中，系统在做每步操作的时候，通过记录每一个临时状态，在系统出现故障的时候，可以从这些中间状态继续未完成的请求处理或者退回到原始状态，最后达到一致的状态。 以案例1-转账为例，我们把用户A给用户B转账分成四个阶段，第一个阶段用户A准备转账，第二个阶段从用户A账户扣减余额，第三个阶段对用户B增加余额，第四个阶段完成转账。系统需要记录操作过程中每一步骤的状态，一旦系统出现故障，系统能够自动发现没有完成的任务，然后，根据任务所处的状态，继续执行任务，最终完成任务，达到一致的最终状态。 在实际应用中，上面这个过程通常是通过持久化执行任务的状态和环境信息，一旦出现问题，定时任务会捞取未执行完的任务，继续未执行完的任务，直到执行完成为止，或者取消已经完成的部分操作回到原始状态。这种方法在任务完成每个阶段的时候，都要更新数据库中任务的状态，这在大规模高并发系统中不会有太好的性能，一个更好的办法是用Write-Ahead Log（写前日志），这和数据库的Bin Log（操作日志）相似，在做每一个操作步骤，都先写入日志，如果操作遇到问题而停止的时候，可以读取日志按照步骤进行恢复，并且继续执行未完成的工作，最后达到一致。写前日志可以利用机械硬盘的追加写而达到较好性能，因此，这是一种专业化的实现方式，多数业务系系统还是使用数据库记录的字段来记录任务的执行状态，也就是记录中间的“软状态”，一个任务的状态流转一般可以通过数据库的行级锁来实现，这比使用Write-Ahead Log实现更简单、更快速。 有了BASE理论作为基础，我们对复杂的分布式事务进行拆解，对其中的每一步骤都记录其状态，有问题的时候可以根据记录的状态来继续执行任务，达到最终的一致，通过这个方法我们可以解决案例2-转账和案例3-下订单和扣库存中遇到的问题。 4. 酸碱平衡的总结 使用向上扩展（强悍的硬件）运行专业的关系型数据库（例如：Oracle或者DB2）能够保证强一致性，钱能解决的问题就不是问题 如果钱是问题，可以对廉价硬件运行的开源关系型数据库（例如：Mysql）进行分片，将相关的数据分到数据库的同一个片，仍然能够使用关系型数据库保证事务 如果业务规则限制，无法将相关的数据分到同一个片，就需要实现最终一致性，通过记录事务的软状态（中间状态、临时状态），一旦处于不一致，可以通过系统自动化或者人工干预来修复不一致的情况 3.3 分布式一致性协议 国际开放标准组织Open Group定义了DTS（分布式事务处理模型），模型中包含4个角色：应用程序、事务管理器、资源管理器、通信资源管理器四部分。事务处理器是统管全局的管理者，资源处理器和通信资源处理器是事务的参与者。 J2EE规范也包含此分布式事务处理模型的规范，并在所有的AppServer中进行实现，J2EE规范中定义了TX协议和XA协议，TX协议定义应用程序与事务管理器之间的接口，而XA协议定义了事务管理器与资源处理器之间的接口，在过去，大家使用AppServer，例如：Websphere、Weblogic、Jboss等配置数据源的时候会看见类似XADatasource的数据源，这就是实现了DTS的关系型数据库的数据源。企业级开发JEE中，关系型数据库、JMS服务扮演资源管理器的角色，而EJB容器则扮演事务管理器的角色。 下面我们就介绍两阶段提交协议、三阶段提交协议以及阿里巴巴提出的TCC，它们都是根据DTS这一思想演变出来的。 1. 两阶段提交协议 上面描述的JEE的XA协议就是根据两阶段提交来保证事务的完整性，并实现分布式服务化的强一致性。 两阶段提交协议把分布式事务分成两个过程，一个是准备阶段，一个是提交阶段，准备阶段和提交阶段都是由事务管理器发起的，为了接下来讲解方便，我们把事务管理器称为协调者，把资管管理器称为参与者。 两阶段如下： 准备阶段：协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指令可以完成，参与者会写redo或者undo日志（这也是前面提起的Write-Ahead Log的一种），然后锁定资源，执行操作，但是并不提交 提交阶段：如果每个参与者明确返回准备成功，也就是预留资源和执行操作成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任何一个参与者明确返回准备失败，也就是预留资源或者执行操作失败，协调者向参与者发起中止指令，参与者取消已经变更的事务，执行undo日志，释放锁定的资源 两阶段提交协议成功场景示意图如下： 两阶段提交协议 我们看到两阶段提交协议在准备阶段锁定资源，是一个重量级的操作，并能保证强一致性，但是实现起来复杂、成本较高，不够灵活，更重要的是它有如下致命的问题： 阻塞：从上面的描述来看，对于任何一次指令必须收到明确的响应，才会继续做下一步，否则处于阻塞状态，占用的资源被一直锁定，不会被释放 单点故障：如果协调者宕机，参与者没有了协调者指挥，会一直阻塞，尽管可以通过选举新的协调者替代原有协调者，但是如果之前协调者在发送一个提交指令后宕机，而提交指令仅仅被一个参与者接受，并且参与者接收后也宕机，新上任的协调者无法处理这种情况 脑裂：协调者发送提交指令，有的参与者接收到执行了事务，有的参与者没有接收到事务，就没有执行事务，多个参与者之间是不一致的 上面所有的这些问题，都是需要人工干预处理，没有自动化的解决方案，因此两阶段提交协议在正常情况下能保证系统的强一致性，但是在出现异常情况下，当前处理的操作处于错误状态，需要管理员人工干预解决，因此可用性不够好，这也符合CAP协议的一致性和可用性不能兼得的原理。 2. 三阶段提交协议 三阶段提交协议是两阶段提交协议的改进版本。它通过超时机制解决了阻塞的问题，并且把两个阶段增加为三个阶段： 询问阶段：协调者询问参与者是否可以完成指令，协调者只需要回答是还是不是，而不需要做真正的操作，这个阶段超时导致中止 准备阶段：如果在询问阶段所有的参与者都返回可以执行操作，协调者向参与者发送预执行请求，然后参与者写redo和undo日志，执行操作，但是不提交操作；如果在询问阶段任何参与者返回不能执行操作的结果，则协调者向参与者发送中止请求，这里的逻辑与两阶段提交协议的的准备阶段是相似的，这个阶段超时导致成功 提交阶段：如果每个参与者在准备阶段返回准备成功，也就是预留资源和执行操作成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任何一个参与者返回准备失败，也就是预留资源或者执行操作失败，协调者向参与者发起中止指令，参与者取消已经变更的事务，执行undo日志，释放锁定的资源，这里的逻辑与两阶段提交协议的提交阶段一致 三阶段提交协议成功场景示意图如下： 三阶段提交协议 然而，这里与两阶段提交协议有两个主要的不同： 增加了一个询问阶段，询问阶段可以确保尽可能早的发现无法执行操作而需要中止的行为，但是它并不能发现所有的这种行为，只会减少这种情况的发生 在准备阶段以后，协调者和参与者执行的任务中都增加了超时，一旦超时，协调者和参与者都继续提交事务，默认为成功，这也是根据概率统计上超时后默认成功的正确性最大 三阶段提交协议与两阶段提交协议相比，具有如上的优点，但是一旦发生超时，系统仍然会发生不一致，只不过这种情况很少见罢了，好处就是至少不会阻塞和永远锁定资源。 3. TCC 上面两节讲解了两阶段提交协议和三阶段提交协议，实际上他们能解决案例2-转账和案例3-下订单和扣库存中的分布式事务的问题，但是遇到极端情况，系统会发生阻塞或者不一致的问题，需要运营或者技术人工解决。无论两阶段还是三阶段方案中都包含多个参与者、多个阶段实现一个事务，实现复杂，性能也是一个很大的问题，因此，在互联网高并发系统中，鲜有使用两阶段提交和三阶段提交协议的场景。 阿里巴巴提出了新的TCC协议，TCC协议将一个任务拆分成Try、Confirm、Cancel，正常的流程会先执行Try，如果执行没有问题，再执行Confirm，如果执行过程中出了问题，则执行操作的逆操Cancel，从正常的流程上讲，这仍然是一个两阶段的提交协议，但是，在执行出现问题的时候，有一定的自我修复能力，如果任何一个参与者出现了问题，协调者通过执行操作的逆操作来取消之前的操作，达到最终的一致状态。 可以看出，从时序上，如果遇到极端情况下TCC会有很多问题的，例如，如果在Cancel的时候一些参与者收到指令，而一些参与者没有收到指令，整个系统仍然是不一致的，这种复杂的情况，系统首先会通过补偿的方式，尝试自动修复的，如果系统无法修复，必须由人工参与解决。 从TCC的逻辑上看，可以说TCC是简化版的三阶段提交协议，解决了两阶段提交协议的阻塞问题，但是没有解决极端情况下会出现不一致和脑裂的问题。然而，TCC通过自动化补偿手段，会把需要人工处理的不一致情况降到到最少，也是一种非常有用的解决方案，根据线人，阿里在内部的一些中间件上实现了TCC模式。 我们给出一个使用TCC的实际案例，在秒杀的场景，用户发起下单请求，应用层先查询库存，确认商品库存还有余量，则锁定库存，此时订单状态为待支付，然后指引用户去支付，由于某种原因用户支付失败，或者支付超时，系统会自动将锁定的库存解锁供其他用户秒杀。 TCC协议使用场景示意图如下： TCC 总结一下，两阶段提交协议、三阶段提交协议、TCC协议都能保证分布式事务的一致性，他们保证的分布式系统的一致性从强到弱，TCC达到的目标是最终一致性，其中任何一种方法都可以不同程度的解决案例2：转账、案例3：下订单和扣库存的问题，只是实现的一致性的级别不一样而已，对于案例4：同步超时可以通过TCC的理念解决，如果同步调用超时，调用方可以使用fastfail策略，返回调用方的使用方失败的结果，同时调用服务的逆向cancel操作，保证服务的最终一致性。 3.4 保证最终一致性的模式 在大规模高并发服务化系统中，一个功能被拆分成多个具有单一功能的元功能，一个流程会有多个系统的多个元功能组合实现，如果使用两阶段提交协议和三阶段提交协议，确实能解决系统间一致性问题，除了这两个协议带来的自身的问题，这些协议的实现比较复杂、成本比较高，最重要的是性能并不好，相比来看，TCC协议更简单、容易实现，但是TCC协议由于每个事务都需要执行Try，再执行Confirm，略微显得臃肿，因此，在现实的系统中，底线要求仅仅需要能达到最终一致性，而不需要实现专业的、复杂的一致性协议，实现最终一致性有一些非常有效的、简单粗暴的模式，下面就介绍这些模式及其应用场景。 1. 查询模式 任何一个服务操作都需要提供一个查询接口，用来向外部输出操作执行的状态。服务操作的使用方可以通过查询接口，得知服务操作执行的状态，然后根据不同状态来做不同的处理操作。 为了能够实现查询，每个服务操作都需要有唯一的流水号标识，也可使用此次服务操作对应的资源ID来标志，例如：请求流水号、订单号等。 首先，单笔查询操作是必须提供的，我们也鼓励使用单笔订单查询，这是因为每次调用需要占用的负载是可控的，批量查询则根据需要来提供，如果使用了批量查询，需要有合理的分页机制，并且必须限制分页的大小，以及对批量查询的QPS需要有容量评估和流控等。 查询模式的示意图如下： 查询模式 对于案例4：同步超时、案例5：异步回调超时、案例6：掉单、案例7：系统间状态不一致，我们都需要使用查询模式来了解被调用服务的处理情况，来决定下一步做什么：补偿未完成的操作还是回滚已经完成的操作。 2. 补偿模式 有了上面的查询模式，在任何情况下，我们都能得知具体的操作所处的状态，如果整个操作处于不正常的状态，我们需要修正操作中有问题的子操作，这可能需要重新执行未完成的子操作，后者取消已经完成的子操作，通过修复使整个分布式系统达到一致，为了让系统最终一致而做的努力都叫做补偿。 对于服务化系统中同步调用的操作，业务操作发起的主动方在还没有得到业务操作执行方的明确返回或者调用超时，场景可参考案例4：同步超时，这个时候业务发起的主动方需要及时的调用业务执行方获得操作执行的状态，这里使用查询模式，获得业务操作的执行方的状态后，如果业务执行方已经完预设的工作，则业务发起方给业务的使用方返回成功，如果业务操作的执行方的状态为失败或者未知，则会立即告诉业务的使用方失败，然后调用业务操作的逆向操作，保证操作不被执行或者回滚已经执行的操作，让业务的使用方、业务发起的主动方、业务的操作方最终达成一致的状态。 补偿模式的示意图如下： 补偿模式 补偿操作根据发起形式分为： 自动恢复：程序根据发生不一致的环境，通过继续未完成的操作，或者回滚已经完成的操作，自动来达到一致 通知运营：如果程序无法自动恢复，并且设计时考虑到了不一致的场景，可以提供运营功能，通过运营手工进行补偿 通知技术：如果很不巧，系统无法自动回复，又没有运营功能，那必须通过技术手段来解决，技术手段包括走数据库变更或者代码变更来解决，这是最糟的一种场景 3. 异步确保模式 异步确保模式是补偿模式的一个典型案例，经常应用到使用方对响应时间要求并不太高，我们通常把这类操作从主流程中摘除，通过异步的方式进行处理，处理后把结果通过通知系统通知给使用方，这个方案最大的好处能够对高并发流量进行消峰，例如：电商系统中的物流、配送，以及支付系统中的计费、入账等。 实践中，将要执行的异步操作封装后持久入库，然后通过定时捞取未完成的任务进行补偿操作来实现异步确保模式，只要定时系统足够健壮，任何一个任务最终会被成功执行。 异步确保模式的示意图如下： 异步确保模式 对于案例5：异步回调超时，使用的就是异步确保模式，这种情况下对于某个操作，如果迟迟没有收到响应，我们通过查询模式和补偿模式来继续未完成的操作。 4. 定期校对模式 既然我们在系统中实现最终一致性，系统在没有达到一致之前，系统间的状态是不一致的，甚至是混乱的，需要补偿操作来达到一致的目的，但是我们如何来发现需要补偿的操作呢？ 在操作的主流程中的系统间执行校对操作，我们可以事后异步的批量校对操作的状态，如果发现不一致的操作，则进行补偿，补偿操作与补偿模式中的补偿操作是一致的。 另外，实现定期校对的一个关键就是分布式系统中需要有一个自始至终唯一的ID，ID的生成请参考SnowFlake。 在分布式系统中，全局唯一ID的示意图如下： 唯一ID 一般情况下，生成全局唯一ID有两种方法： 持久型：使用数据库表自增字段或者Sequence生成，为了提高效率，每个应用节点可以缓存一批次的ID，如果机器重启可能会损失一部分ID，但是这并不会产生任何问题 时间型：一般由机器号、业务号、时间、单节点内自增ID组成，由于时间一般精确到秒或者毫秒，因此不需要持久就能保证在分布式系统中全局唯一、粗略递增能特点 实践中，为了能在分布式系统中迅速的定位问题，一般的分布式系统都有技术支持系统，它能够跟踪一个请求的调用链，调用链是在二维的维度跟踪一个调用请求，最后形成一个调用树，原理可参考谷歌的论文Dapper, a Large-Scale Distributed Systems Tracing Infrastructure，一个开源的参考实现为pinpoint。 在分布式系统中，调用链的示意图如下： 调用链 全局的唯一流水ID可以把一个请求在分布式系统中的流转的路径聚合，而调用链中的spanid可以把聚合的请求路径通过树形结构进行展示，让技术支持人员轻松的发现系统出现的问题，能够快速定位出现问题的服务节点，提高应急效率。 关于订单跟踪、调用链跟踪、业务链跟踪，我们会在后续文章中详细介绍。 在分布式系统中构建了唯一ID，调用链等基础设施，我们很容易对系统间的不一致进行核对，通常我们需要构建第三方的定期核对系统，以第三方的角度来监控服务执行的健康程度。 定期核对系统示意图如下： 定期核对模式 对于案例6：掉单、案例7：系统间状态不一致通常通过定期校对模式发现问题，并通过补偿模式来修复，最后完成系统间的最终一致性。 定期校对模式多应用在金融系统，金融系统由于涉及到资金安全，需要保证百分之百的准确性，所以，需要多重的一致性保证机制，包括：系统间的一致性对账、现金对账、账务对账、手续费对账等等，这些都属于定期校对模式，顺便说一下，金融系统与社交应用在技术上本质的区别在于社交应用在于量大，而金融系统在于数据的准确性。 到现在为止，我们看到通过查询模式、补偿模式、定期核对模式可以解决案例4到案例7的所有问题，对于案例4：同步超时，如果同步超时，我们需要查询状态进行补偿，对于案例5：异步回调超时，如果迟迟没有收到回调响应，我们也会通过查询状态进行补偿，对于案例6：掉单、案例7：系统间状态不一致，我们通过定期核对模式可以保证系统间操作的一致性，避免掉单和状态不一致导致问题。 5. 可靠消息模式 在分布式系统中，对于主流程中优先级比较低的操作，大多采用异步的方式执行，也就是前面提到的异步确保型，为了让异步操作的调用方和被调用方充分的解耦，也由于专业的消息队列本身具有可伸缩、可分片、可持久等功能，我们通常通过消息队列实现异步化，对于消息队列，我们需要建立特殊的设施保证可靠的消息发送以及处理机的幂等等。 消息的可靠发送 消息的可靠发送可以认为是尽最大努力发送消息通知，有两种实现方法： 第一种，发送消息之前，把消息持久到数据库，状态标记为待发送，然后发送消息，如果发送成功，将消息改为发送成功。定时任务定时从数据库捞取一定时间内未发送的消息，将消息发送。 消息发送模式1 第二种，实现方式与第一种类似，不同的是持久消息的数据库是独立的，并不耦合在业务系统中。发送消息之前，先发送一个预消息给某一个第三方的消息管理器，消息管理器将其持久到数据库，并标记状态为待发送，发送成功后，标记消息为发送成功。定时任务定时从数据库捞取一定时间内未发送的消息，回查业务系统是否要继续发送，根据查询结果来确定消息的状态。 消息发送模式2 一些公司把消息的可靠发送实现在了中间件里，通过Spring的注入，在消息发送的时候自动持久消息记录，如果有消息记录没有发送成功，定时会补偿发送。 消息处理器的幂等性 如果我们要保证消息可靠的发送，简单来说，要保证消息一定要发送出去，那么就需要有重试机制，有了重试机制，消息一定会重复，那么我们需要对重复做处理。 处理重复的最佳方式为保证操作的幂等性，幂等性的数学公式为： f(f(x)) = f(x) 保证操作的幂等性常用的几个方法： 使用数据库表的唯一键进行滤重，拒绝重复的请求 使用分布式表对请求进行滤重 使用状态流转的方向性来滤重，通常使用行级锁来实现(后续在锁相关的文章中详细说明) 根据业务的特点，操作本身就是幂等的，例如：删除一个资源、增加一个资源、获得一个资源等 6. 缓存一致性模型 大规模高并发系统中一个常见的核心需求就是亿级的读需求，显然，关系型数据库并不是解决高并发读需求的最佳方案，互联网的经典做法就是使用缓存抗读需求，下面有一些使用缓存的保证一致性的最佳实践： 如果性能要求不是非常的高，尽量使用分布式缓存，而不要使用本地缓存 种缓存的时候一定种完全，如果缓存数据的一部分有效，一部分无效，宁可放弃种缓存，也不要把部分数据种入缓存 数据库与缓存只需要保持弱一致性，而不需要强一致性，读的顺序要先缓存，后数据库，写的顺序要先数据库，后缓存 这里的最佳实践能够解决案例8：缓存和数据库不一致、案例9：本地缓存节点间不一致、案例10：缓存数据结构不一致的问题，对于数据存储层、缓存与数据库、Nosql等的一致性是更深入的存储一致性技术，将会在后续文章单独介绍，这里的数据一致性主要是处理应用层与缓存、应用层与数据库、一部分的缓存与数据库的一致性。 3.5 专题模式 这一节介绍特殊场景下的一致性问题和解决方案。 迁移开关的设计 在大多数企业里，新项目和老项目一般会共存，大家都在努力的下掉老项目，但是由于种种原因总是下不掉，如果要彻底的下掉老项目，就必须要有非常完善的迁移方案，迁移是一项非常复杂而艰巨的任务，我会在将来的文章中详细探讨迁移方案、流程和技术，这里我们只对迁移中使用的开关进行描述。 迁移过程必须使用开关，开关一般都会基于多个维度来设计，例如：全局的、用户的、角色的、商户的、产品的等等，如果迁移过程中遇到问题，我们需要关闭开关，迁移回老的系统，这需要我们的新系统兼容老的数据，老的系统也兼容新的数据，从某种意义上来讲，迁移比实现新系统更加困难。 曾经看过很多简单的开关设计，有的开关设计在应用层次，通过一个curl语句调用，没有权限控制，这样的开关在服务池的每个节点都是不同步的、不一致的；还有的系统把开关配置放在中心化的配置系统、数据库或者缓存等，处理的每个请求都通过统一的开关来判断是否迁移等等，这样的开关有一个致命的缺点，服务请求在处理过程中，开关可能会变化，各个节点之间开关可能不同步、不一致，导致重复的请求可能走到新的逻辑又走了老的逻辑，如果新的逻辑和老的逻辑没有保证幂等性，这个请求就被重复处理了，如果是金融行业的应用，可能会导致资金损失，电商系统可能会导致发货并退款等问题。 这里面我们推荐使用订单开关，不管我们在什么维度上设计了开关，接收到服务请求后，我们在请求创建的关联实体（例如：订单）上标记开关，以后的任何处理流程，包括同步的和异步的处理流程，都通过订单上的开关来判断，而不是通过全局的或者基于配置的开关，这样在订单创建的时候，开关已经确定，不再变更，一旦一份数据不再发生变化，那么它永远是线程安全的，并且不会有不一致的问题。 这个模式在生产中使用比较频繁，建议每个企业都把这个模式作为设计评审的一项，如果不检查这一项，很多开发童鞋都会偷懒，直接在配置中或者数据库中做个开关就上线了。 4 总结 本文从一致性问题的实践出发，从大规模高并发服务化系统的实践经验中进行总结，列举导致不一致的具体问题，围绕着具体问题，总结出解决不一致的方法，并且抽象成模式，供大家在开发服务化系统的过程中参考。 另外，由于篇幅有限，还有一些关于分布式一致性的技术无法在一篇文章中与大家分享，包括：paxos算法、raft算法、zab算法、nwr算法、一致性哈希等，我会在后续文章中详细介绍。 来源：中生代技术 原文链接

咕咚APP——综合运动社交平台     咕咚APP致力于打造运动社交综合型平台，目前咕咚APP所涵盖人群包括：跑步、健走、骑行、游泳、滑雪、篮球、足球等多个领域，并为其提供相应功能进行承载。   咕咚APP有稳定的GPS轨迹记录及全面的数据存储，满足运动人群对于个体/群组的社交需求。咕咚APP已经拥有近5000万注册用户，日活人数450万+人，致力于为平台上千万运动爱好者，打造专属的运动功能、社交功能、以及独特的O2O功能。     互联网OLTP模型     缓存(ECS(redis&&twemproxy)+SLB)     队列     经历的阶段： ◆ Redis：单线程，扩展性不强，不支持ack。 ◆ RabbitMQ：集群方案常出问题，并且无法获取error log，出问题后很难定位。 ◆ 阿里云MQ方案：无单点,无瓶颈，可自由扩展，支持重试机制。     数据库(RDS MySQL)     1. 托管的数据库服务。 2. 全方位的基础监控，权限控制。 3. 高可用性，无感知自动切换主备。 4. 弹性升级配置。 5. 相关配套中间件功能强大，比如DRDS,DTS。   海量数据存储方案(PreSharding+DRDS)     对象数据存储(OSS咕咚路线详情数据)   OSS的优势表现在以下几点：   1. 海量扩展性。 2. 高可用性 (可用性不低于99.9% ; 持久性10个9)。 3. 安全性(提供白名单，防盗链，主子账号功能)。 4. 成本低。 5. 团队的快速响应(咕咚提出的对OSS监控的需求，开发到上线非常迅速)。   OSS适合在图片、音视频、日志、数据库备份集&& binlog等场景中应用。那么，咕咚从OSS获得了哪些便利？主要有以下三个方面：   1. 从RDS迁移到OSS成本降低了90%以上。 2. 天然多重副本，不用再考虑灾难备份。 3. 分布式设计，不用再考虑扩展性。   归档数据(OAS)   1. 价格非常便宜，支持断点续传。 2. 单个文件最大支持40TB。 3. 适合用来存储归档数据。   互联网OLAP模型     移动端日志采集     1. 通用的SDK，来代替原有的埋点API，更加稳定。 2. 多维的报表数据。 3. 相关crash信息。 4. 日志数据可统一推到ODPS做进一步的分析处理。     数据仓库(ODPS)   1. 托管的数据仓库方案。 2. 分布式列式数据库模型，强大的计算能力，高压缩比。 3. 支持sql，MapReduce。 4. 无缝抽取分布式RDS数据，集中化数据处理。         本文根据咕咚运动运维负责人李锐在6月29日举办的2016云栖大会·成都峰会上的演讲整理而成。