CDC 和基于事件的通信是两种截然不同的内容，在一定程度上看起来相似，因此存在混淆。小心 – 混淆另一个可能会导致非常困难的体系结构情况。
这些东西是什么？
更改数据捕获 （CDC） 通常暗示用于捕获系统数据发生的所有更改的机制。对此类系统的需求不难想象 – 对敏感信息的审核、跨多个数据库实例或数据中心的数据复制、将更改从事务数据库移动到数据湖/OLAP 存储。中的事务管理
符合 ACID 的数据库本质上是 CDC。CDC 系统是每个对实体所做的每个更改的记录，以及该更改的元数据（由更改、更改时间等）。
符合 ACID 的数据库本质上是 CDC。CDC 系统是每个对实体所做的每个更改的记录，以及该更改的元数据（由更改、更改时间等）。
您也可以享受：
使用嵌入式 Debezium 和弹簧启动更改数据捕获 （CDC）
我以前在这个博客上写过关于事件的文章，并把它们描述为系统域中发生的事情的公告，并提供有关该事件的相关数据。乍一看，这似乎与CDC相同——系统中发生了一些变化，需要与其他系统沟通——这正是CDC的一部分。
然而，这里有一个关键的区别。事件的定义在比数据更改高得多的抽象级别，因为它们是域的有意义的更改。表示实体的数据可以更改，而不会对数据表示的整体实体产生任何”业务”影响。订单管理系统可能在内部维护，但对外部世界无关，订单可以有多个子状态
另一方面，有一些世界其它国家关心（创建、派遣等），订单管理系统明确向外界公开。对这些状态的更改或来自这些状态将生成事件。
差异可以从系统边界的角度明确说明。当我们设计微服务或执行任何系统分解时，我们试图识别和隔离边界上下文或业务域彼此。这是所有的基础
域驱动设计。
域驱动设计。
CDC 是关于捕获系统边界上下文中的数据更改，通常是在物理模型方面。系统记录对其自身数据的更改。即使我们有一个单独的服务或系统存储这些更改（某种
平台化审核存储），分离是实现细节。实际数据与更改之间存在域建模的连续性，因此两者逻辑上都属于同一边界内。
平台化审核存储），分离是实现细节。实际数据与更改之间存在域建模的连续性，因此两者逻辑上都属于同一边界内。
另一方面，事件是由一个边界上下文发出的域模型级广播，由其他边界上下文使用。这些表示外部系统可以理解和响应的语言中具有语义意义的事件。它们通过相同的消息发布介质，使用类似的框架，也许在某处得到坚持等等都是实现细节。
CQRS怎么样？
如何建立
CQRS风格系统？对于未启动的 CQRS（命令查询责任分离）是一种体系结构样式，其中用于写入（命令）的数据模型和技术不同于用于读取（查询）的数据模型和技术。
CQRS风格系统？对于未启动的 CQRS（命令查询责任分离）是一种体系结构样式，其中用于写入（命令）的数据模型和技术不同于用于读取（查询）的数据模型和技术。
当写入模式存在较大差异且需要支持且要支持的读取模式时，通常使用这种设计。我已经给出了这样一个系统在我的
我认为，由于命令查询模型分离是系统的内部设计，因此两个模型都位于同一边界上下文中，使用 CDC 日志是不合适的。生产者和消费者都处于相同的抽象级别（两者都是数据存储，尽管一个可能是 MySQL，另一个可能是 MySQL
弹性搜索），所以使用DB级别更改日志不是一个坏主意。当然，这只是一种意见。在此处使用事件也不会坏，特别是如果不同的团队管理模型。
弹性搜索），所以使用DB级别更改日志不是一个坏主意。当然，这只是一种意见。在此处使用事件也不会坏，特别是如果不同的团队管理模型。
命令模块应始终发出事件反正，如果没有别的，然后
将进化特征借给整个架构。
将进化特征借给整个架构。
构建 CDC 和事件系统
在现代分布式设置中，更改数据通常通过消息传递介质发布，例如
Kafka，然后可以被其他系统使用，这些系统想要存储此数据。构建 CDC 系统的一种非常流行和高效的方法是使用跟踪数据库的内部日志文件（
MySQL和其他关系 DB 始终具有此项用于事务管理，ElasticSearch 在其较新版本中具有更改流），使用类似
Filebeat，然后通过卡夫卡发布日志。
Kafka，然后可以被其他系统使用，这些系统想要存储此数据。构建 CDC 系统的一种非常流行和高效的方法是使用跟踪数据库的内部日志文件（
MySQL和其他关系 DB 始终具有此项用于事务管理，ElasticSearch 在其较新版本中具有更改流），使用类似
Filebeat，然后通过卡夫卡发布日志。
另一方通常具有
logstash类型插件将数据引入其他系统，这些系统保留此更改日志
logstash类型插件将数据引入其他系统，这些系统保留此更改日志
apache.org/”rel=”无跟随”目标=”_blank”=火花/
Flink样式流式应用程序，这些应用程序使用此数据并将其转换为适合其他用例的窗体。
这显然并不总是可能的，因为并非所有数据库都有将日志文件更改为流。对于这些系统，我们必须求助于向应用程序层本身添加代码以发出更改日志。确保不存在数据被更改但未发出日志的情况是一个很难解决的问题（本质上是一个原子更新问题：如何确保 DB 更新和 Kafka 事件发射都发生或什么都没发生）。在 CDC 系统中，无损性至关重要。
要构建基于事件的系统，我们将在应用程序层具有事件生成逻辑，就像在没有日志文件的数据库的情况下为 CDC 所做的那样。这是我们可以将数据库的语言翻译成域语言的唯一位置。与 CDC 相同，防止发布者中的事件丢失是设计的关键。
然而。有些人提议使用CDC流作为系统的事件流，这是我完全不同意，因为我上述所有的原因。这将将其他系统耦合到我们系统的物理数据模型，我们必须永远保持我们的公共实体与数据库模型相同。这大大降低了域模型的表现力。考虑取消订单。CDC 系统将记录类似
更改日志=”订单号”：”12345″，”更改字段”：”状态”，”旧值”：”在进行中”，”新值”：”已取消”
如果我用我的域语言来表达这一点，什么可以或不能发生在订单，我会理想的东西，如
订单事件 [“订单号”：”12345″，”事件类型”：”订单已取消”*
但是，如果我们将传输语言与 CDC 语言进行物理耦合，这种抽象是不可能的
尤其是在使用逻辑模型和物理模型时，我们应该小心将实现细节与正在实现的细节隔离开来。
仔细看看我们要发布的记录的发布者和消费者——如果它们都是在”数据存储”级别定义的，我们可能正在谈论 CDC。如果更多的业务结构（边界上下文）如订单，快递，发票等，我们很可能在事件维尔。
Comments are closed.