Databus&canal对比
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项目更成熟，当然学习成本也更大 |
