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项目更成熟,当然学习成本也更大 |