參考資料：
1、Databus架構分析與初步實踐（for mysql）（上篇）：https://sq.163yun.com/blog/article/173552201158811648
2、Databus架構分析與初步實踐（for mysql）（下篇）：https://sq.163yun.com/blog/article/173554725500456960
1. 簡介
Databus是一個低延遲、可靠的、支持事務的、保持一致性的數據變更抓取系統。由LinkedIn於2013年開源。Databus通過挖掘數據庫日志的方式，將數據庫變更實時、可靠的從數據庫拉取出來，業務可以通過定制化client實時獲取變更並進行其他業務邏輯。
Databus有以下特點：
- 數據源和消費者之間的隔離。
- 數據傳輸能保證順序性和至少一次交付的高可用性。
- 從變化流的任意時間點進行消費，包括通過bootstrap獲取所有數據。
- 分區消費
- 源一致性保存，消費不成功會一直消費直到消費成功
2. 功能&特性
- 來源獨立：Databus支持多種數據來源的變更抓取，包括Oracle和MySQL。
- 可擴展、高度可用：Databus能擴展到支持數千消費者和事務數據來源，同時保持高度可用性。
- 事務按序提交：Databus能保持來源數據庫中的事務完整性，並按照事務分組和來源的提交順尋交付變更事件。
- 低延遲、支持多種訂閱機制：數據源變更完成后，Databus能在毫秒級內將事務提交給消費者。同時，消費者使用Databus中的服務器端過濾功能，可以只獲取自己需要的特定數據。
- 無限回溯：對消費者支持無限回溯能力，例如當消費者需要產生數據的完整拷貝時，它不會對數據庫產生任何額外負擔。當消費者的數據大大落后於來源數據庫時，也可以使用該功能。
3. 使用場景舉例
BUSSINESS1 和 BUSSINESS2 是兩個不同的業務邏輯，他們的變更需要同時寫入到 DB 和 CACHE ，那么當他們同時修改同一個數據的時候是否能保證數據的一致性呢？可以發現如果按照下圖標明的順序進行操作並不能保證數據的一致性！
還有一個問題是變更完DB之后，更新CACHE失敗怎么辦？如果忽略的話，會造成后續讀取到CACHE中舊的數據，如果重試的話，業務代碼會寫得更加復雜。針對這些場景，如果沒有一個強一致協議是很難解決掉的。如果要業務邏輯去實現這些晦澀的一致性協議，卻又是不現實的。
現在，有了Databus，上面提到的這些一致性問題就都沒有了，並且那些冗長的雙寫邏輯也可以去掉了，如下圖所示:
4. 系統整體架構與主要組件
4.1 系統整體架構
