为什么
在微服务架构中，在服务拆分后，每个服务都会根据自身业务维护独立的数据，服务之间需要进行数据交互，一般会采用 RPC 或 RESTful API 进行通信。
在某些复杂场景下，微服务通常不仅需要更新本地数据存储，而且还需要将发生的数据变更通知其他服务。比如去数据库 join、同步数据到数据仓储，那么如果只是通过常用的进程间通信方式来处理数据，那么性能是非常差的。
数据分发则是为了解决这类问题，通过某种方式将数据源中的数据分发给第三方，数据分发需要遵守一个原则：Single Source of Truth，也就是说分发数据的服务应该是该数据的唯一主人，分发到其它系统的数据应该是只读的，非权威的，不能保证准确性。
常见的数据分发场景
- 同步数据仓库/搜索引擎
- 去数据库 join（通过数据分发冗余，避免跨库join）
- 实现分布式事务
- 数据库拆分的迁移
怎么做
开始之前，我们先举一个简单的例子，假如有一个用户服务(user-service)，当对用户信息进行变更时，需要将变更的信息同步给第三方(order-service)
双写
第一个想到的应该就是直接双写，在 user-service 中对用户数据修改后，立马调用第三方接口进行同步。
首先我们引入了分布式事务来解决了双写的强一致性问题，事实上，数据分发对于一致性的要求并不是非常高，一般来说要求最终一致性即可，现在来看，同步了一个三方，我们还能接受。
随着业务规模的扩张，现在需要对用户的信息进行报表分析，现在需要将用户信息再同步到数据仓库中，于是
随着需要同步的三方服务越来越多，分布式事务引入的技术复杂性也越来越高，对于
userService 服务本身来说耦合性也越来越高，最终就会导致服务的维护性越来越差。
事务性发件箱（Transactional Outbox）
可以看到 双写 是一个不太靠谱的方案。它会带来两个问题
- 引入分布式事务，导致复杂性增高
- 耦合性太高
而且是随着接入的三方的增多，复杂性也会线性增大。
事务性发件箱模式则可以很好的解决这两个问题，它做了两件事
- 将分布式事务转换成本地事务，在
user表所在的数据库中新增一个outbox表，更新用户信息的同时把对用户的变更信息一起插入到outbox表中，可以直接使用本地事务保证原子性。 - 新增一个 Message Relay 线程，定时从
outbox表中拉取未处理的数据，发布到 MQ 中，在三方系统中只需要订阅 topic 即可，这样大大的降低了服务的耦合性
看起来很完美，解决了分布式事务的复杂性和耦合性。但引入了新的技术栈和 Message Relay 节点，没有银弹... 依旧会出现新的需要考虑的问题
- 消费方在消费MQ数据时需要做幂等处理
- 需要保证 Message Relay 的高可用，高可用的同时需要考虑选主问题（一般只需要一个 Message Relay 线程工作）
- 需要对错误消息跟踪处理
虽然引入了新的复杂性，但长远来看是可以接受的。维护成本也比较小，但由于 Message Relay 是从 outbox 中定时拉取数据，然后发布到 MQ，最后订阅方在进行消费，这个数据流还是比较长的，也就意味着使用 事务性发件箱模式 数据的实时性并不高，同时也会有一定的侵入性。
变更数据捕获（Change Data Capture, CDC）
Transactional Outbox 模式的一个硬伤就是实时性较差，主要原因就在于 Message Relay 拉取 Outbox 的频率，如果直接轮询，对数据库就会造成很大的压力，如果定期拉取，实时性就很差。
Change Data Capture 是通过捕获增量数据的方式进行数据的同步，其利用了数据库的事务日志通知的特性，捕获记录的变更记录，从而可以及时的感知到数据的变动，大大的提高了实时性。
CDC 的原理也非常简单，一般数据库，对于变更提交操作，都记录所谓事务日志Transaction Log，也称为提交日志Commit Log，比如 MySQL 支持 binlog，Postgres 支持 Write Ahead log。事务日志可以简单理解为数据库本地的一个文件队列，它记录了按时间顺序发生的对数据库表的变更提交记录。
同样 CDC 也引入了一些新的复杂性
- Transactional log miner 的高可用以及监控告警
- 需要深入理解数据库的事务日志格式和协议
国内用的比较多的 CDC 解决方案是阿里的 Canal，其核心原理就是借助了 MySQL 的主从复制功能，模拟成 MySQL 的 salve 节点，向 MySQL 发送 dump 协议，接收 MySQL 推送的 binlog。
总结
面向业务系统数据库的数据集成场景中，数据分发的场景会越来越多，在保证数据最终一致性的前提下，数据的实时性越来越重要。本文介绍了三种数据分发的方式
双写
适合简单的业务场景，不引入新的技术栈直接通过常规的进程间通信方式进行数据分发。为了解决分布式事务的问题，需要引入分布式事务解决方案，当然也可以使用最简单的补偿方式来避免引入分布式事务的复杂度。
事务性发件箱 Transactional Outbox
适合中小规模的业务场景，虽然引入了新的技术栈带来一些新的问题，但这些问题都有比较成熟的解决方案。对于 Transactional Outbox 模式来说没办法避免的就是两点
- 对服务会较小的侵入性
- 数据的实时性相对较差
所以如果我们能够接受这两个缺点，那么 Transactional Outbox 模式是个不错的选择。
变更数据捕获 Change Data Capture
相较于 Transactional Outbox 来说，虽然有现成的解决方案，但 CDC 的综合复杂性依旧会更高，甚至需要单独的进行维护。CDC 带来的最大好处就是实时性很高，所以 CDC 更适合于大规模且实时性要求更高的业务场景。
