DTS介绍
数据传输（Data Transmission）服务 DTS 是阿里云提供的一种支持 RDBMS（关系型数据库）、NoSQL、OLAP 等多种数据源之间数据交互的数据流服务。它提供了数据迁移、实时数据订阅及数据实时同步等多种数据传输能力。通过数据传输可实现不停服数据迁移、数据异地灾备、异地多活(单元化)、跨境数据同步、实时数据仓库、查询报表分流、缓存更新、异步消息通知等多种业务应用场景，助您构建高安全、可扩展、高可用的数据架构。
- 数据传输服务 DTS（以下简称 DTS）的目标是帮用户简化复杂的数据交互工作，使得用户可以专注于上层的业务开发。
- DTS 支持多种数据源类型，例如：
- DTS 承诺 99.95% 的链路稳定性及 99.999% 的数据可靠性。
- DTS 支持 RAM 主子账号体系，用户可以使用子账号创建并管理 DTS 实例，极大程度提升企业安全性。
使用场景
不停服迁移，系统迁移时业务停服时间降低到分钟级别
很多用户希望系统迁移时，尽可能不影响业务提供服务。然而在系统迁移过程中，如果业务不停服，那么迁移数据就会发生变化，无法保证迁移数据的一致性。为了保证迁移数据一致性，很多第三方迁移工具，要求在数据迁移期间，应用停止服务。整个迁移过程，业务可能需要停服数小时甚至上天，这对业务伤害极大。
为了降低数据库迁移门槛， 数据传输提供不停服迁移解决方案，让数据迁移过程中，业务停服时间降低到分钟级别。
不停服迁移的实现原理详见下图。
不停服迁移的迁移类型需包含结构迁移、全量数据迁移及增量数据迁移三个阶段。当进入增量数据迁移阶段时，目标实例会保持跟源数据库之间的数据实时同步，用户可以在目标数据库进行业务验证，当验证通过后，直接将业务切换到目标数据库，从而实现整个系统迁移。
由此可见，在整个迁移过程中，只有当业务从源实例切换到目标实例期间，会产生业务闪断，其他时间业务均能正常服务。
数据异地灾备，地区故障对服务无影响
由于地区断电、断网等客观原因，产品可用性并不能达到100%。当出现这些故障时，如果用户业务部署在单个地区，那么就会因为地区故障导致服务不可用，且不可用时间完全依赖故障恢复时间。
为了解决地区故障导致的服务不可用，提高服务可用性，可以在构建异地灾备中心。当业务中心发生地区故障时，直接将业务流量切换到灾备中心，立刻恢复服务。数据灾备架构如下图。
如图所示，当业务部署在杭州时，在异地(例如北京)构建灾备中心。灾备中心同业务中心的数据库通过数据传输进行数据实时同步，当业务中心故障时，可以保证数据灾备的数据完整性。
异地多活，保证服务高可用
随着业务的快速发展，对于很多公司来说，构建于单地域的技术体系架构，会面临诸如下面的多种问题：
(1) 由于单地域底层基础设施的有限性限制了业务的可扩展性，例如城市供电能力，网络带宽建设能力等。
(2) 出现城市级别的故障灾害时，无法保证服务的可持续性，服务难以实现高可用。
(3) 用户分布比较广的业务，远距离访问延迟高，严重影响用户体验。
为解决企业遇到的这些问题，用户可以选择构建异地多活架构，在同城/异地构建多个单元(业务中心)。根据业务的某个维度将业务流量切分到各个单元(例如：电商的买家维度)。各个业务单元可以分布在不同的地域，从而有效解决了单地域部署带来的基础设施的扩展限制问题。
各个单元之间的数据层通过DTS的双向同步进行全局同步，保证全局数据一致。当任何一个单元出现故障时，只要将这个单元的流量切到其他单元即可在完成业务的秒级恢复，从而有效保证了服务的可持续性。
异地多活架构的单元可以根据用户分布选择部署区域，业务上可以按照用户所属区域划分单元流量，实现用户就近访问，避免远距离访问，降低访问延迟，提升用户访问体验。
加速全球化业务访问速度，为跨境业务赋能
对于用户分布比较广的业务，例如全球化业务，如果按照传统架构，只在单地区部署服务，那么其他地区的用户需要跨地区远距离访问服务，导致访问延迟大，用户体验差的问题。为了加速全球化业务访问速度，优化访问体验，可以将架构调整如下。
在这个架构中，我们定义了中心和单元的概念，所有地区用户的写请求全部路由回中心。通过数据传输将中心的数据实时同步到各个单元，各个地区的用户的读请求，可以路由到就近的单元，从而避免远距离访问，降低访问延迟，加速全球化访问速度。
云BI，快速搭建定制化BI系统
由于自建BI系统的复杂性，自建BI不能满足越来越高的实时性要求，或是因为阿里云已经提供了非常完善的BI体系，可以在不影响现有架构的情况下快速搭建BI系统等原因，越来越多的用户选择在阿里云上搭建满足自身业务定制化要求的BI系统。
数据传输DTS可以帮助用户将本地自建DB的数据实时同步到阿里云的BI存储系统(例ODPS、ADS或流计算)，然后，用户使用各种计算引擎进行后续的数据分析，同时可以通过可视化工具进行计算结果的实时展示，或通过迁移工具将计算结果同步回本地IDC，具体实现架构如下：
数据实时分析，快速抢占商业先机
数据分析在提高企业洞察力和用户体验方面发挥着举足轻重的作用，且实时数据分析能够让企业更快速、灵活得调整市场策略，适应快速变化的市场方向及消费者体验。为了在不影响线上业务的情况下实现实时数据分析，需要将业务数据实时同步到分析系统中，由此可见，实时获取业务数据必不可少。数据传输提供的数据订阅功能，可以在不影响线上业务的情况下，帮助您获取业务的实时增量数据，通过SDK可将其同步至分析系统中进行实时数据分析。
其中RDS到RDS数据实时同步的更多内容详见使用阿里云数据传输实时同步RDS的数据。
轻量级缓存更新策略，让核心业务更简单可靠
为了提高业务访问速度，提升业务读并发，很多用户都会在业务架构中引入缓存层。业务所有读请求全部路由到缓存层，通过缓存的内存读取机制大大提升业务读取性能。缓存中的数据不能持久化 ，一旦缓存异常退出，那么内存中的数据就会丢失，所以为了保证数据完整，业务的更新数据会落地到持久化存储中，例如DB。
如上所述，业务会遇到缓存跟持久化DB数据同步的问题。数据传输DTS提供的数据订阅功能，可以通过异步订阅DB的增量数据，并更新缓存的数据，实现轻量级的缓存更新策略。这种策略的架构如下。
这种缓存更新策略的优势在于：
- 更新路径短，延迟低缓存失效为异步流程，业务更新DB完成后直接返回，不需要关心缓存失效流程，整个更新路径短，更新延迟低。
- 应用简单可靠应用无需实现复杂双写逻辑，只需启动异步线程监听增量数据，更新缓存数据即可。
- 应用更新无额外性能消耗因为数据订阅是通过解析DB的增量日志来获取增量数据，获取数据的过程对业务、DB性能无损。
业务异步解耦，让核心业务更简单可靠
通过数据订阅，可以将深耦合业务优化为通过实时消息通知实现的异步耦合，让核心业务逻辑更简单可靠。这个应用场景在阿里巴巴内部得到了广泛的应用，目前淘宝订单系统每天有上万个下游业务，通过数据订阅获取订单系统的实时数据更新，触发自身的变更逻辑。
下面举个简单的逻辑，描述下整个应用场景的优势。
例如电商行业，涉及下单系统、卖家库存、物流发货等多个业务逻辑。如果将这些逻辑全部在下单流程中，那么下单流程为：用户下单，系统通知卖家库存，物流发货等下游业务进行逻辑变更，当全部变更完成后，返回下单结果。这种下单逻辑存在如下问题：
- 下单流程长、时间长，用户体验差
- 系统稳定性差，任何一个下游发生故障，直接影响下单系统的可用性
为了提升核心应用用户体验，提高稳定性，可以将核心应用、跟依赖的下游业务异步解耦。让核心应用更稳定可靠。具体调整如下图：
下单系统只要下完单就直接返回，底层通过数据传输实时获取订单系统的变更数据，业务通过SDK订阅这个变更数据，并触发库存、物流等下游业务逻辑。由此，保证下单系统的简单可靠。
读能力横向扩展，快速适应业务发展
对于有大量读请求的应用场景，单个RDS实例可能无法承担全部的读取压力， 甚至可能对主流程业务产生影响。为了实现读取能力的弹性扩展，分担数据库压力，可以使用数据传输服务的实时同步功能构建只读实例，利用这些只读实例承担大量的数据库读取工作负载，从而方便得扩展了应用的吞吐量。
产品架构
系统架构
下图为数据传输服务的系统架构图：
(1) 系统高可用
数据传输服务内部每个模块都有主备架构，保证系统高可用。容灾系统实时检测每个节点的健康状况，一旦发现某个节点异常，会将链路秒级切换到其他节点。
(2) 数据源地址变更
对于数据订阅及同步链路，容灾系统还会监测数据源的连接地址切换等变更操作，一旦发现数据源发生连接地址变更，它会动态适配数据源新的连接方式，在数据源变更的情况下，保证链路的稳定性。
数据迁移基本原理
数据迁移任务提供多种迁移类型：结构对象迁移、全量数据迁移以及增量数据迁移。如果需要实现不停服迁移，那么迁移过程需要经历：
(1) 结构对象迁移
(2) 全量数据迁移
(3) 增量数据迁移
对于异构数据库之间的迁移，进行结构迁移时，DTS会从源库读取结构定义语法后，会根据目标数据库的语法定义，组装成目标数据库的语法定义格式，然后导入到目标实例中。
全量数据迁移过程持续较久，在这过程中，源实例不断有业务写入，为保证迁移数据的一致性，在全量数据迁移之前会启动增量数据拉取模块，增量数据拉取模块会拉取源实例的增量更新数据，并解析、封装、存储在本地存储中。
当全量数据迁移完成后，DTS会启动增量数据回放模块，增量数据回放模块会从增量拉取模块中获取增量数据，经过反解析、过滤、封装后同步到目标实例，从而实现源实例、目标实例数据实时同步。
数据订阅基础原理
如上图所示，数据订阅支持实时拉取RDS实例的增量日志，用户可以通过DTS SDK来数据订阅服务端订阅增量日志，根据业务需求，实现数据定制化消费。
DTS服务端的日志拉取模块主要实现从数据源抓取原始数据，并通过解析、过滤、标准格式化等流程，最终将增量数据在本地持久化。
日志抓取模块通过数据库协议连接并实时拉取源实例的增量日志。例如源实例为RDS For MySQL，那么数据抓取模块通过Binlog dump协议连接源实例。
DTS实现了日志拉取模块及下游消费SDK的高可用。
DTS容灾系统一旦检测到日志拉取模块出现异常，就会在健康服务节点上断点重启日志拉取模块，保证日志拉取模块的高可用。
DTS支持在服务端实现下游SDK消费进程的高可用。用户同时对一个数据订阅链路，启动多个下游SDK消费进程,服务端同时只向一个下游消费推送增量数据，当这个消费进程异常后，服务端会从其他健康下游中选择一个消费进程，向这个消费进程推送数据，从而实现下游消费的高可用。
实时同步基础原理
数据传输服务的实时同步功能能够实现任何两个RDS实例之间的增量数据实时同步。2016.8月份后，将陆续支持OLTP->OLAP的数据实时同步。
同步链路的创建过程包括：
(1) 同步初始化， 同步初始化主要将源实例的历史存量数据在目标实例初始化一份。
(2) 增量数据实时同步， 当初始化完成后进入两边增量数据实时同步阶段，在这个阶段，DTS会实现源实例跟目标实例之间数据动态同步过程。
增量数据实时同步过程，DTS的底层实现模块主要包括：
(1) 日志读取模块
日志读取模块从源实例读取原始数据，经过解析、过滤及标准格式化，最终将数据在本地持久化。日志读取模块通过数据库协议连接并读取源实例的增量日志。如果源DB为RDS MySQL，那么数据抓取模块通过Binlog dump协议连接源库。
(2) 日志回放模块
日志回放模块从日志读取模块中请求增量数据，并根据用户配置的同步对象进行数据过滤，然后在保证事务时序性及事务一致性的前提下，将日志记录同步到目标实例。
DTS实现了日志读取模块、日志回放模块的高可用，DTS容灾系统一旦检测到链路异常，就会在健康服务节点上断点重启链路，从而有效保证同步链路的高可用。