Databus和canal都能夠提供實時從數據庫獲取變更，並提供給下游的實時消費流的功能。
本文針對兩個系統實現和應用上的不同點，做了一個簡單的對比：
| 對比項 |
|
Databus |
canal |
結論 |
|---|---|---|---|---|
| 支持的數據庫 |
|
mysql, oracle |
mysql(據說內部版本支持oracle) |
Databus目前支持的數據源更多 |
| 業務開發 |
|
業務只需要實現事件處理接口 |
事件處理外，需要處理ack/rollback， 反序列化異常等 |
Databus開發接口用戶友好度更高 |
| 服務模型 |
relay |
relay可以同時服務多個client |
一個server instance只能服務一個client （受限於server端保存拉取位點） |
Databus服務模式更靈活 |
|
|
client |
client可以拉取多個relay的變更， 訪問的relay可以指定拉取某些表某些分片的變更 |
client只能從一個server拉取變更， 而且只能是拉取全量的變更 |
|
| 可擴展性 |
|
client可以線性擴展，處理能力也能線性擴展 （Databus可識別pk，自動做數據分片） |
client無法擴展 |
Databus擴展性更好 |
| 可用性 |
client ha |
client支持cluster模式，每個client處理一部分數據， 某個client掛掉，其他client自動接管對應分片數據 |
主備client模式，主client消費， 如果主client掛掉，備client可自動接管 |
Databus實時熱備方案更成熟 |
|
|
relay/server ha |
多個relay可連接到同一個數據庫， client可以配置多個relay，relay故障啟動切換 |
主備relay模式，relay通過zk進行failover |
canal主備模式對數據庫影響更小 |
|
|
故障對上游 數據庫的影響 |
client故障，bootstrap會繼續拉取變更， client恢復后直接從bootstrap拉取歷史變更 |
client故障會阻塞server拉取變更， client恢復會導致server瞬時從數據庫拉取大量變更 |
Databus本身的故障對數據庫影響幾乎為0 |
| 系統狀態監控 |
|
程序通過http接口將運行狀態暴露給外部 |
暫無 |
Databus程序可監控性更好 |
| 開發語言 |
|
java，核心代碼16w，測試代碼6w |
java，4.2w核心代碼，6k測試代碼 |
Databus項目更成熟，當然學習成本也更大 |