系统如果要应付大规模的请求，一条必经之路就是数据库的分割，单服务器的性能早晚都会成为负载的短板。而数据库分割，通常有Master/Salve或者集群Cluster的方式，这些方式通常都是基于同种类型的数据。对于一个庞大的多类型数据库的系统，在不同的数据库之间（甚至是不同地理位置的机房间）保持数据的同步，需要更复杂的解决方案。LinkedIn良心开源了内部的一个项目Databus，正是解决这个问题的一套实时低延迟数据同步系统。
Databus采用的是数据库日志挖掘的方式，这种方式最大的好处是能最大限度的保持一致性，而且具有最有的性能，但是缺点就是实现起来极为困难。因为Oracle和MySQL这样的数据库有自己特有的私有交易日志格式以及复制冗余解决方案，每次版本升级之后可能都会导致日志挖掘的代码失败，需要持续的保持升级。
当然以LinkedIn的技术实力，他们还是解决了那些问题。Databus的传输层端到端延迟是微秒级的，每台服务器每秒可以处理数千次数据吞吐变更事件，同时还支持无限回溯能力和丰富的变更订阅功能。
Databus具有如下特性：
来源独立：Databus支持多种数据来源的变更抓取，包括Oracle和MySQL。
可扩展、高度可用：Databus能扩展到支持数千消费者和事务数据来源，同时保持高度可用性。
事务按序提交：Databus能保持来源数据库中的事务完整性，并按照事务分组和来源的提交顺寻交付变更事件。
低延迟、支持多种订阅机制：数据源变更完成后，Databus能在微秒级内将事务提交给消费者。同时，消费者使用Databus中的服务器端过滤功能，可以只获取自己需要的特定数据。
无限回溯：这是Databus最具创新性的组件之一，对消费者支持无限回溯能力。当消费者需要产生数据的完整拷贝时（比如新的搜索索引），它不会对主OLTP数据库产生任何额外负担，就可以达成目的。当消费者的数据大大落后于来源数据库时，也可以使用该功能。
Databus由Databus Relays（中继）和Databus Client（客户端）：
Databus Relay中继的功能主要包括：
- 从Databus来源读取变更行，并在内存缓存内将其序列化为Databus变更事件；
- 监听来自Databus客户端（包括Bootstrap Producer）的请求，并传输新的Databus数据变更事件。
Databus客户端的功能主要包括：
- 检查Relay上新的数据变更事件，并执行特定业务逻辑的回调;
- 如果落后Relay太多，向Bootstrap Server发起查询;
- 新Databus客户端会向Bootstrap Server发起bootstrap启动查询，然后切换到向中继发起查询，以完成最新的数据变更事件;
- 单一客户端可以处理整个Databus数据流，或者可以成为消费者集群的一部分，其中每个消费者只处理一部分流数据。
最近一直在研究这个项目，希望能应用在整个系统的架构中，对于重要数据在跨系统中保持自动同步，这样可以大大减少代码层面不同系统中的数据API的调用，简化IT的工作量。
对Databus项目感兴趣的同学，可以去Databus在Github上的页面查看更多信息。
