使用Debezium来实现关系数据库管理系统（RDBMS）的事件溯源机制

1 年 ago

宇, 华

1 minute

首先

我們前不久與Star Festival合作進行了一個聯合研討會。
我們將在這篇文章中公開介紹當時的演講內容。

关于资料

问题解决领域

架构

1. 单块石

一个模块中包含了大量逻辑并且依赖于一个数据库的单块连接的架构模式。

2. 模块化的单体

在适当的粒度下，将模块划分，并存在多个模块依赖于同一个数据库的模式。

3. 微服务

每个模块都拥有独立的数据库，并且部署线也完全分离，导致了松耦合的模式。

选择的架构模式

主要领域的架构配置

传说模式

传奇模式的种类

管弦樂編曲模式

在中央集权的指挥者系统的支配下，协调模式的判断确定了要与哪些服务进行连接，并将处理工作分配到各个服务中。

舞蹈编排模式

对此，被称为舞蹈编排的模式而言，不存在中央集权的指挥者，每个服务都知道在处理完之后要与哪个服务协同，通过串联处理，使得处理可以自主执行的结构。

这次引入的Saga模式。

事件源/命令查询责任分离 (CQRS)

我们引入了一种被称为事件溯源/ CQRS的设计模式来保持数据写入/读取的可扩展性。

事件订阅

CQRS（命令查询职责分离）

分散事务VS事务外发

分散交易的陷阱

在实施前述的事件溯源时，我们引入了一种被称为Transactional Outbox模式的设计模式。
通常的异步处理是直接将消息写入消息代理（事件存储）的，但是将数据同时写入业务数据库和事件存储会导致分布式事务和2阶段提交。
如果在向事件存储写入事务成功后，业务数据库的事务失败，
本来应该在该处理中将数据写入业务数据库，但实际上没有写入，而是继续进行下一步的处理。

事务性发件箱

事务性Outbox是一种在业务数据库中创建一个称为”Outbox”的表，并以与业务数据相同的原子提交方式将事件写入的方法。通过这种方式，可以利用关系数据库管理系统的ACID特性，同时确保处理的一致性，以便继续进行下一阶段的处理。

使用Debezium实现事务型出箱模式。

使用Outbox模式实现Saga

时间线模式的存在

关于事件请求历史和事件消费历史的表格。

关于AWS架构

Kafka ConsumerをECS(Fargate)を稼働させることで処理の水平スケーリングが可能

データレイヤー

データベースはRDSで稼働させ、読み込み処理はリードレプリカを利用することで水平スケーリングが可能

摩斯科是莫斯科的缩写。

我使用Apache Kafka的托管服务作为消息代理和使用MSK Connect作为运行Debezium的Kafka Connect的托管服务。

弹性容器服务（Fargate）

我們使用ECS（Fargate）作為啟動Kafka Consumer服務的平台。

RDS：对中国人来说是什么意思？

我们使用了普通的RDS数据库（非Aurora）。

发生障碍时的处理方法

恢复步骤

恢复消费者

在使用过程中，可能会发生意料之外的错误。
在这种情况下，我们将按照上述步骤执行恢复操作。
当Kafka接收到Consumer接收到消息的通知时，无论Consumer能否成功处理，都可以递增话题的偏移量以接收下一条消息，因此即使消费者端处理失败，下一条消息的处理也会继续进行。
因此，如果没有建立具有幂等性的消费者模式，恢复操作将导致已经成功处理的消息被重新接收并重复执行，因此在恢复步骤中需要确保幂等性担保。

今天的总结

Saga的调度模式

为了确保结果生合成，采用了避免分散事务的设计模式。
通过创建协调器层，可以抑制OutBox表的增加。

事件溯源/命令查询责任分离（Event Sourcing/CQRS 模式）

通过将事件写入持久数据存储中，实现事件的稳定的异步处理，使其不会消失。
通过完全分离引用处理和写入处理的责任，在性能优越且灵活的系统中实现高性能。

事务性Outbox模式

事件的记录使用了数据库的本地事务。
通过单一提交，可以将事件记录与其他业务表一起进行，实现了去除2PC。

最后

关于支付服务的交易对方域的架构进行了讨论。
对于需要在交易对方域之外公开的功能，我们进行了微服务化，以避免关系数据库成为单点故障，并减少对外影响的努力。此外，我们还引入了一些现代技术，这些技术在研讨会中没有涉及，但由于本次说明会的主题无关，我们省略了这部分内容。
我们考虑在另一个主题上进行讨论。

首先