linkedin开源中间件：Databus。一个低延迟的分布式数据库同步系统

大家好，我是程序员牛肉。

最近又发现了一个比较好玩的东西。先说场景吧：假设我们有一个电商平台，用户在平台上进行购物，订单数据存储在MySQL数据库中。

为了提高数据的可用性和可靠性，我们需要将这些订单数据实时同步到一个下游的NoSQL数据库（例如MongoDB）中，以便进行快速查询和分析。

这种同步数据库的场景其实也就那几个解决方案。最简单，最容易想到的就是同步双写。

同步双写：

稍微有点技术追求的可能会想到通过做异步来减少执行用时：

异步双写：

这两种方案各有各的缺点。同步双写性能太差了。而且存在大量的硬编码，并不符合我们优雅的编码风格。异步双写的话会存在延迟的问题，而且MQ还会有丢失消息的可能性。

因此我们的目光不能只放到代码层面了。我们看一看MySQL有什么搞头吧。

此时一个天才发现原来Mysql里面有一个叫做BinLog的日志。这个日志记录了对于MySQL数据库进行所有更改的事件，包括插入，更新，删除等操作。

既然这个BinLog日志记录了Mysql所有的变更记录，我们能不能搞一个中间件来监听MySQL中的BinLog日志。然后解析这些BinLog日志来提交给下游数据库进行数据变更呢？

当你想到了这一步，其实你也就领悟了我们今天要分享的databus的设计思路。

[ Databus是一个实时的低延时数据抓取系统。它将数据库作为唯一真实数据来源，并将变更从事务或提交日志中提取出来，然后通知相关的衍生数据库或缓存。Databus传输层端到端的延迟是微秒级别的，这意味着每台服务器每秒可以处理数千次数据吞吐变更事件,同时还支持无限回溯能力和丰富的变更订阅功能。]

https://github.com/linkedin/databus 对应的GitHub地址

看一眼这个中间件的架构图吧：

这个中间件基于 Binlog 订阅的方式实现，模拟一个 MySQL Slave 订阅 Binlog 日志，从而实现 CDC（Change Data Capture），将已提交的更改发送到下游，包括 INSERT、DELETE、UPDATE。

让我们来详细介绍一下这些模块中的作用：

• SourceDatabus：数据源。
• Relays：基于MySQL主从传输协议，他会伪装成为一个SLAVE节点来接收主节点的binLog日志，将这些binLog日志打包成为数据变化事件之后，之后将数据变化事件发送给client端。需要注意它是全内存存储，或者可以通过mmap同步到文件系统中。
• BootStrap Service：一个特殊的client端，功能和Relay相似。从realy来接收新的数据变化事件，监听来自Databus客户端的请求并为了引导和追溯返回一个超长的回溯的数据变化事件
• Schema Registry：将数据库binLog日志解析成为databus的数据结构。
• Application：数据库变更消费逻辑，当获取变更的时候，从relay中拉取变更事件。当挂掉了之后，就需要从bootstrap server中获取挂掉之后的所有数据变化（可以理解为一个快照）。

我们在架构图中可以看到有的Application是从Relays中拉取变更进行消费，有的是从BootStrap Service中获取变更进行消费。这二者有什么区别呢？

我们可以认为：从Realys中获取的变更要比从BootStrap Service中获得的变更粒度要小得多。Realys中的变更是一个个变更事件，而BootStrap Service中的变更是一个个变更事件组成的一个快照。

那为什么databus要提供这两种格式的变更事件呢？

数据获取时机不同

• 实时变更处理需要实时处理数据变更的消费者应用程序会从 In - Mem Log Stores (Relays) 获取变更。因为 In - Mem Log Stores 存储了最新捕获到的数据库变更，消费者应用程序可以从这里及时获取到最新的变更数据，实现对数据的实时处理和响应，适用于对数据实时性要求较高的场景，如实时监控系统、金融交易系统等。
• 初始化或故障恢复在消费者应用程序首次启动或系统发生故障后进行恢复时，会从 Bootstrap Service 获取变更。此时消费者应用程序需要一个完整的初始数据状态来开始处理，Bootstrap Service 从 Snapshot Stores 读取相应的快照数据提供给消费者应用程序，使其能够从一个已知的正确状态开始，避免数据处理的混乱和错误。

应用程序类型和功能不同

• 在线交互类应用像在线交易系统、实时聊天应用等在线交互类应用，为了给用户提供即时的反馈和响应，需要实时获取数据变更，从 In - Mem Log Stores (Relays) 获取变更可以保证数据的及时性，让应用能够快速响应用户的操作和数据变化。
• 数据整合与分析类应用数据仓库、大数据分析平台等数据整合与分析类应用，可能更侧重于在一个相对稳定的数据基础上进行分析和处理。在初始化或定期更新时从 Bootstrap Service 获取数据快照，可以确保数据的完整性和一致性，便于进行复杂的数据分析和处理操作，而不会受到实时变更流的干扰。

粗略的讲，我们可以认为databus一共就两个关键模块。一个是：relay，负责从mysql中拉取变更事件。一个是client，负责从relay拉去变更事件，之后做业务化的逻辑。

因此我们来更加详细的介绍一下relay模块的架构：

Relay模块中的各个小模块的作用为：

• Databus Event Producer(DBEP)：定期从数据库中查询变更，如果检测到变更，它将读取数据库中的所有已更改的行，并将其转换为Avro记录。因为数据库数据类型和Databus数据类型不一致，因此需要 Schema Registry 做转换。
• SCN（System Change Number）：系统改变号，是数据库中非常重要的一个数据结构。SCN用以标识数据库在某个确切时刻提交的版本。在事务提交时，它被赋予一个唯一的标识事务的SCN。
• Event Buffers：按照SCN的顺序存储databus事件，buffer可以是纯内存的，也可以是mmap到文件系统的。每个buffer在内存中还有一个对应的SCN Index和一个MaxSCN reader/writer，SCN Index可以加快查询指定事件的速度。
• Request Processor：通过监听Netty的channel，实现收发client的请求。
• MaxSCN Reader/Writer：用于跟踪DBEP的处理进度；Reader在Databus启动的时候会读取存储的文件上一次DBEP处理的位置，当Databus从DBEP中读取变更存储到Event Buffers时，Writer就会最后一个SCN写入到文件中存储，这样就能保证下次启动可以从正确的位置读取数据库变更。
• JMX（Java Management Extensions）：支持标准的Jetty容器，databus提供了多个Mbean来监控relay
• RESTFul Interface:Realy提供了相关http接口供外部调用，Client与Relay建立http长连接，并从Relay拉取Event。

Client端的架构：

• Relay Puller：负责从relay拉取数据，具体工作有挑选relay，请求source，请求Register，校验schema，设置dispatcher等。
• Dispatcher：从event buffers中读取事件，调用消费逻辑的回调，主要职责有： 1.判断回调是否正确，回调失败后会进行重试，重试次数超限后抛出异常 2.监控错误和超时 3.持久化checkpoint
• Checkpoint persistence Provider：checkpoint是消费者消费变更记录点的位置，负责将checkpoint持久化到本地，保证下次启动后可以从正常的位置pull event。
• Event Callback：调用消费者自定义业务逻辑代码。
• Bootstrap Puller：负责从Bootstrap servers拉取数据，功能类似Relay Puller。

最后贴一篇我最近一直在看的关于这些内容的文章，来自linkedin的Jay Kerps大佬的《The Log: What every software engineer should know about real-time data's unifying abstraction》，高强度的读这些英文内容对我来讲还是有点吃力的，但它确实是一篇好文章。

https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying 对应的文章

今天关于databus的内容就介绍到这里了，这篇文章主要介绍一下databus的基础架构部分。这个中间件的具引用的话还是较简单的，大家在网上基本能找到运用实例，因此这篇就不多做介绍了。