為什么

在微服務架構(gòu)中党涕，在服務拆分后计技，每個服務都會根據(jù)自身業(yè)務維護獨立的數(shù)據(jù)享钞，服務之間需要進行數(shù)據(jù)交互割岛，一般會采用 RPC 或 RESTful API 進行通信愉适。

在某些復雜場景下，微服務通常不僅需要更新本地數(shù)據(jù)存儲癣漆，而且還需要將發(fā)生的數(shù)據(jù)變更通知其他服務。比如去數(shù)據(jù)庫 join剂买、同步數(shù)據(jù)到數(shù)據(jù)倉儲惠爽，那么如果只是通過常用的進程間通信方式來處理數(shù)據(jù)癌蓖，那么性能是非常差的。

數(shù)據(jù)分發(fā)則是為了解決這類問題婚肆，通過某種方式將數(shù)據(jù)源中的數(shù)據(jù)分發(fā)給第三方租副，數(shù)據(jù)分發(fā)需要遵守一個原則：Single Source of Truth，也就是說分發(fā)數(shù)據(jù)的服務應該是該數(shù)據(jù)的唯一主人较性，分發(fā)到其它系統(tǒng)的數(shù)據(jù)應該是只讀的用僧，非權(quán)威的，不能保證準確性赞咙。

常見的數(shù)據(jù)分發(fā)場景

• 同步數(shù)據(jù)倉庫/搜索引擎
• 去數(shù)據(jù)庫 join（通過數(shù)據(jù)分發(fā)冗余责循，避免跨庫join）
• 實現(xiàn)分布式事務
• 數(shù)據(jù)庫拆分的遷移

怎么做

開始之前，我們先舉一個簡單的例子攀操，假如有一個用戶服務(user-service)院仿，當對用戶信息進行變更時，需要將變更的信息同步給第三方(order-service)

雙寫

第一個想到的應該就是直接雙寫速和，在 user-service 中對用戶數(shù)據(jù)修改后歹垫，立馬調(diào)用第三方接口進行同步。

首先我們引入了分布式事務來解決了雙寫的強一致性問題颠放，事實上排惨，數(shù)據(jù)分發(fā)對于一致性的要求并不是非常高，一般來說要求最終一致性即可碰凶，現(xiàn)在來看若贮，同步了一個三方，我們還能接受痒留。

隨著業(yè)務規(guī)模的擴張谴麦，現(xiàn)在需要對用戶的信息進行報表分析，現(xiàn)在需要將用戶信息再同步到數(shù)據(jù)倉庫中伸头，于是

事務性發(fā)件箱（Transactional Outbox）

可以看到 雙寫 是一個不太靠譜的方案。它會帶來兩個問題

• 引入分布式事務扫步，導致復雜性增高
• 耦合性太高
  而且是隨著接入的三方的增多魔策，復雜性也會線性增大。

事務性發(fā)件箱模式則可以很好的解決這兩個問題河胎，它做了兩件事

1. 將分布式事務轉(zhuǎn)換成本地事務闯袒，在 user 表所在的數(shù)據(jù)庫中新增一個 outbox 表，更新用戶信息的同時把對用戶的變更信息一起插入到 outbox 表中，可以直接使用本地事務保證原子性政敢。
2. 新增一個 Message Relay 線程其徙，定時從 outbox 表中拉取未處理的數(shù)據(jù)，發(fā)布到 MQ 中喷户，在三方系統(tǒng)中只需要訂閱 topic 即可唾那，這樣大大的降低了服務的耦合性

看起來很完美，解決了分布式事務的復雜性和耦合性褪尝。但引入了新的技術(shù)棧和 Message Relay 節(jié)點闹获，沒有銀彈... 依舊會出現(xiàn)新的需要考慮的問題

• 消費方在消費MQ數(shù)據(jù)時需要做冪等處理
• 需要保證 Message Relay 的高可用，高可用的同時需要考慮選主問題（一般只需要一個 Message Relay 線程工作）
• 需要對錯誤消息跟蹤處理

雖然引入了新的復雜性河哑，但長遠來看是可以接受的避诽。維護成本也比較小，但由于 Message Relay 是從 outbox 中定時拉取數(shù)據(jù)灾馒，然后發(fā)布到 MQ茎用，最后訂閱方在進行消費，這個數(shù)據(jù)流還是比較長的睬罗，也就意味著使用 事務性發(fā)件箱模式 數(shù)據(jù)的實時性并不高轨功，同時也會有一定的侵入性。

變更數(shù)據(jù)捕獲（Change Data Capture, CDC）

Transactional Outbox 模式的一個硬傷就是實時性較差容达，主要原因就在于 Message Relay 拉取 Outbox 的頻率古涧，如果直接輪詢，對數(shù)據(jù)庫就會造成很大的壓力花盐，如果定期拉取羡滑，實時性就很差。

Change Data Capture 是通過捕獲增量數(shù)據(jù)的方式進行數(shù)據(jù)的同步算芯，其利用了數(shù)據(jù)庫的事務日志通知的特性柒昏，捕獲記錄的變更記錄，從而可以及時的感知到數(shù)據(jù)的變動熙揍，大大的提高了實時性职祷。

CDC 的原理也非常簡單，一般數(shù)據(jù)庫届囚，對于變更提交操作有梆，都記錄所謂事務日志Transaction Log，也稱為提交日志Commit Log意系，比如 MySQL 支持 binlog泥耀，Postgres 支持 Write Ahead log。事務日志可以簡單理解為數(shù)據(jù)庫本地的一個文件隊列蛔添，它記錄了按時間順序發(fā)生的對數(shù)據(jù)庫表的變更提交記錄痰催。

同樣 CDC 也引入了一些新的復雜性

• Transactional log miner 的高可用以及監(jiān)控告警
• 需要深入理解數(shù)據(jù)庫的事務日志格式和協(xié)議

國內(nèi)用的比較多的 CDC 解決方案是阿里的 Canal兜辞，其核心原理就是借助了 MySQL 的主從復制功能，模擬成 MySQL 的 salve 節(jié)點陨囊，向 MySQL 發(fā)送 dump 協(xié)議弦疮，接收 MySQL 推送的 binlog夹攒。

總結(jié)

面向業(yè)務系統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)集成場景中蜘醋，數(shù)據(jù)分發(fā)的場景會越來越多，在保證數(shù)據(jù)最終一致性的前提下咏尝，數(shù)據(jù)的實時性越來越重要压语。本文介紹了三種數(shù)據(jù)分發(fā)的方式

雙寫
適合簡單的業(yè)務場景，不引入新的技術(shù)棧直接通過常規(guī)的進程間通信方式進行數(shù)據(jù)分發(fā)编检。為了解決分布式事務的問題胎食，需要引入分布式事務解決方案，當然也可以使用最簡單的補償方式來避免引入分布式事務的復雜度允懂。

事務性發(fā)件箱 Transactional Outbox
適合中小規(guī)模的業(yè)務場景厕怜，雖然引入了新的技術(shù)棧帶來一些新的問題，但這些問題都有比較成熟的解決方案蕾总。對于 Transactional Outbox 模式來說沒辦法避免的就是兩點

• 對服務會較小的侵入性
• 數(shù)據(jù)的實時性相對較差
  所以如果我們能夠接受這兩個缺點粥航，那么 Transactional Outbox 模式是個不錯的選擇。

變更數(shù)據(jù)捕獲 Change Data Capture
相較于 Transactional Outbox 來說生百，雖然有現(xiàn)成的解決方案递雀，但 CDC 的綜合復雜性依舊會更高，甚至需要單獨的進行維護蚀浆。CDC 帶來的最大好處就是實時性很高缀程，所以 CDC 更適合于大規(guī)模且實時性要求更高的業(yè)務場景。