大家好，又见面了，我是你们的朋友全栈君。
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项目更成熟，当然学习成本也更大 |
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/167187.html原文链接：https://javaforall.cn
