参考资料：
1、Databus架构分析与初步实践（for mysql）（上篇）：https://sq.163yun.com/blog/article/173552201158811648
2、Databus架构分析与初步实践（for mysql）（下篇）：https://sq.163yun.com/blog/article/173554725500456960
1. 简介
Databus是一个低延迟、可靠的、支持事务的、保持一致性的数据变更抓取系统。由LinkedIn于2013年开源。Databus通过挖掘数据库日志的方式，将数据库变更实时、可靠的从数据库拉取出来，业务可以通过定制化client实时获取变更并进行其他业务逻辑。
Databus有以下特点：
- 数据源和消费者之间的隔离。
- 数据传输能保证顺序性和至少一次交付的高可用性。
- 从变化流的任意时间点进行消费，包括通过bootstrap获取所有数据。
- 分区消费
- 源一致性保存，消费不成功会一直消费直到消费成功
2. 功能&特性
- 来源独立：Databus支持多种数据来源的变更抓取，包括Oracle和MySQL。
- 可扩展、高度可用：Databus能扩展到支持数千消费者和事务数据来源，同时保持高度可用性。
- 事务按序提交：Databus能保持来源数据库中的事务完整性，并按照事务分组和来源的提交顺寻交付变更事件。
- 低延迟、支持多种订阅机制：数据源变更完成后，Databus能在毫秒级内将事务提交给消费者。同时，消费者使用Databus中的服务器端过滤功能，可以只获取自己需要的特定数据。
- 无限回溯：对消费者支持无限回溯能力，例如当消费者需要产生数据的完整拷贝时，它不会对数据库产生任何额外负担。当消费者的数据大大落后于来源数据库时，也可以使用该功能。
3. 使用场景举例
BUSSINESS1 和 BUSSINESS2 是两个不同的业务逻辑，他们的变更需要同时写入到 DB 和 CACHE ，那么当他们同时修改同一个数据的时候是否能保证数据的一致性呢？可以发现如果按照下图标明的顺序进行操作并不能保证数据的一致性！
还有一个问题是变更完DB之后，更新CACHE失败怎么办？如果忽略的话，会造成后续读取到CACHE中旧的数据，如果重试的话，业务代码会写得更加复杂。针对这些场景，如果没有一个强一致协议是很难解决掉的。如果要业务逻辑去实现这些晦涩的一致性协议，却又是不现实的。
现在，有了Databus，上面提到的这些一致性问题就都没有了，并且那些冗长的双写逻辑也可以去掉了，如下图所示:
4. 系统整体架构与主要组件
4.1 系统整体架构
