第三方数据取不了 分布式最佳实践：数据分发

为什么

在微服务架构中，在服务拆分后，每个服务都会根据自身业务维护独立的数据，服务之间需要进行数据交互，一般会采用 RPC 或 API 进行通信。

在某些复杂场景下，微服务通常不仅需要更新本地数据存储，而且还需要将发生的数据变更通知其他服务。比如去数据库 join、同步数据到数据仓储，那么如果只是通过常用的进程间通信方式来处理数据，那么性能是非常差的。

数据分发则是为了解决这类问题，通过某种方式将数据源中的数据分发给第三方，数据分发需要遵守一个原则： of Truth，也就是说分发数据的服务应该是该数据的唯一主人，分发到其它系统的数据应该是只读的，非权威的，不能保证准确性。

常见的数据分发场景

怎么做

开始之前，我们先举一个简单的例子，假如有一个用户服务(user-)，当对用户信息进行变更时，需要将变更的信息同步给第三方(order-)

双写

第一个想到的应该就是直接双写，在user-中对用户数据修改后，立马调用第三方接口进行同步。

首先我们引入了分布式事务来解决了双写的强一致性问题，事实上，数据分发对于一致性的要求并不是非常高，一般来说要求最终一致性即可，现在来看，同步了一个三方，我们还能接受。

随着业务规模的扩张，现在需要对用户的信息进行报表分析，现在需要将用户信息再同步到数据仓库中，于是

随着需要同步的三方服务越来越多，分布式事务引入的技术复杂性也越来越高，对于服务本身来说耦合性也越来越高，最终就会导致服务的维护性越来越差。

事务性发件箱（ ）

可以看到双写是一个不太靠谱的方案。它会带来两个问题

事务性发件箱模式则可以很好的解决这两个问题，它做了两件事

将分布式事务转换成本地事务，在user表所在的数据库中新增一个表，更新用户信息的同时把对用户的变更信息一起插入到表中，可以直接使用本地事务保证原子性。新增一个 Relay 线程，定时从表中拉取未处理的数据，发布到 MQ 中，在三方系统中只需要订阅 topic 即可，这样大大的降低了服务的耦合性

看起来很完美，解决了分布式事务的复杂性和耦合性。但引入了新的技术栈和 Relay 节点，没有银弹... 依旧会出现新的需要考虑的问题

虽然引入了新的复杂性，但长远来看是可以接受的。维护成本也比较小，但由于 Relay 是从 中定时拉取数据，然后发布到 MQ，最后订阅方在进行消费，这个数据流还是比较长的，也就意味着使用 事务性发件箱模式 数据的实时性并不高，同时也会有一定的侵入性。

变更数据捕获（ Data , CDC）

模式的一个硬伤就是实时性较差，主要原因就在于 Relay 拉取 的频率，如果直接轮询，对数据库就会造成很大的压力，如果定期拉取，实时性就很差。

Data 是通过捕获增量数据的方式进行数据的同步，其利用了数据库的事务日志通知的特性，捕获**的变更**，从而可以及时的感知到数据的变动，大大的提高了实时性。

CDC 的原理也非常简单，一般数据库，对于变更提交操作，都**所谓事务日志 Log，也称为提交日志 Log，比如 MySQL 支持 ， 支持 Write Ahead log。事务日志可以简单理解为数据库本地的一个文件队列，它**了按时间顺序发生的对数据库表的变更提交**。

同样 CDC 也引入了一些新的复杂性

国内用的比较多的 CDC 解决方案是阿里的Canal，其核心原理就是借助了 MySQL 的主从复制功能，模拟成 MySQL 的 salve 节点，向 MySQL 发送 dump 协议，接收 MySQL 推送的 。

总结

面向业务系统数据库的数据集成场景中，数据分发的场景会越来越多，在保证数据最终一致性的前提下，数据的实时性越来越重要。本文介绍了三种数据分发的方式

双写适合简单的业务场景，不引入新的技术栈直接通过常规的进程间通信方式进行数据分发。为了解决分布式事务的问题，需要引入分布式事务解决方案，当然也可以使用最简单的补偿方式来避免引入分布式事务的复杂度。

事务性发件箱 适合中小规模的业务场景，虽然引入了新的技术栈带来一些新的问题，但这些问题都有比较成熟的解决方案。对于 模式来说没办法避免的就是两点

变更数据捕获 Data 相较于 来说，虽然有现成的解决方案，但 CDC 的综合复杂性依旧会更高，甚至需要单独的进行维护。CDC 带来的最大好处就是实时性很高，所以 CDC 更适合于大规模且实时性要求更高的业务场景。