查看“Databus & canal 对比”的源代码



{| class="wikitable"
|-
! 对比项 !!   !! Databus !! canal !! 结论
|-
| 支持的数据库 ||   || mysql, oracle || mysql(据说内部版本支持oracle) || Databus目前支持的数据源更多
|-
| 业务开发 ||  || 业务只需要实现事件处理接口 || 事件处理外，需要处理ack/rollback，反序列化异常等 || Databus开发接口用户友好度更高
|-
| 服务模型 || relay || relay可以同时服务多个client || 一个server instance只能服务一个client（受限于server端保存拉取位点） || Databus服务模式更灵活
|-
|   || client || client可以拉取多个relay的变更，访问的relay可以指定拉取某些表某些分片的变更 || client只能从一个server拉取变更，而且只能是拉取全量的变更 || Databus服务模式更灵活
|-
| 可扩展性 ||  || 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项目更成熟，当然学习成本也更大

|}