• Debezium 是一个很好的工具，用于捕获数据库上发生的行级更改并将这些更改流式传输到我们选择的代理。我们的目标是监听 PostgreSQL 更改并通过 Debezium 服务器将它们流式传输到 Redis 流。通常将 Debizum 与 Kafka 一起使用，在我们的例子
  • 在本文中，您将学习如何在 Spring Boot 应用程序中将 Kafka 事务与 Spring Kafka 项目一起使用。为了运行 Kafka 集群，我们将使用 icon
  • 微服务架构促进了去中心化的数据管理实践，其中每个服务都将其数据保密并仅通过定义良好的 API 接口将其公开。尽管这是为了更大的利益，但开发人员发现实现跨越多个服务边界的查询具有挑战性。 一个微服务经常联系几个依赖服务来完成一个读取请求。例如， ShippingService 查询 Custo icon
  • 只有几个模式让我觉得很舒服：“如果你想构建成熟的系统，你应该一直使用它”。其中之一是发件箱模式。为什么？因为它保证了你的业务流程和沟通不会卡在中间。正如我在发件箱中解释的，收件箱模式和交付保证解释了：发件箱模式确保消息至少成功发送（例如发送到队列）一次。使用这种模式，我们不是 icon
  • 如果您参与实时分析，就不能再忽视“更改数据捕获(简称#CDC)”。一些最流行和最先进的架构现在建立在基于 CDC 的解决方案之上。让我们探索是什么让 CDC 如此受欢迎，看看它将如何影响您的商业模式和项目。 虽然云提供了许多好处，例如存储和 icon
  • 我为我们的金融科技软件设计了事件驱动的架构。它由三个部分组成。第一部分有一个同步过程，第二部分和第三部分有异步操作。响应回复客户端后，将Kafka（消息代理）的最终结果发送到第二部分和第三部分。在第二部分中，我可不将结果返回给客户端。但是，将数据从第一部分发送到第二部 icon
  • 俗话说计算机科学只有两件难的事：缓存失效和命名。好吧，事实证明第一个实际上已经解决了。了解如何在靠近用户的分布式缓存中保持数据的读取视图，始终与您的主数据存储更改数据捕获保持同步。你将学到如何： * 为基于 Debezium、Apache Kafka 和 Infini icon
  • 让我们更深入地讨论在 Postgres 之上潜在的基于轮询的实现。 假设我们将使用的表结构： icon
  • 使用 Apache Pinot、Kafka 和 Debezium 构建可扩展的分析基础架构以提供低延迟的面向用户的分析这篇文章将是一篇很长的文章。所以让我总结一下重要的事情。 什么是面向用户的分析？ 面向用户的分析的商业价值是什么 为什么很难实现面向用 icon
  • 对用于将事务数据库的近实时副本创建到分析数据库中的新高效机制的需求正在增长。主要原因是 传统事务数据库副本不适用于分析工作负载 (OLAP)。 它们无法针对长时间运行的分析 (OLAP) 查询进行扩展。 跨数据库连接也不容易并且通常跨越多个事务域边界。 icon
  • 此示例演示如何使用变更数据捕获以安全可靠的方式实现Saga 模式，以实现跨多个微服务的分布式事务。基于#发件箱模式， icon
  • 首先了解业务逻辑可以建模为事件驱动的状态机： 状态机——状态机是一种数学抽象，用于设计基于行为模型的算法。状态机读取一组输入并根据这些输入更改为不同的状态。 状态— 状态是对等待执行转换的系统状态的描述。 转换——转换是从一种状态到另一种状态的变化。转换是在满 icon
  • 在源数据库和派生数据库之间保持强数据一致性对于基于CDC的流数据管道至关重要。目标数据库必须反映对源数据库所做的最新更改，因为数据更改速度很快。像Apache Pinot这样的实时OLAP数据库利用其upsert功能来提供可靠的端到端数据一致性。Upsert确保摄取的数据集始终准确并 icon
  • 假设我们有一个将其状态存储在数据库中的程序，我们希望其他程序在发生变化时做一些事情。例如，我们可能想在银行余额下降到某个阈值以下时发送电子邮件通知。这是应用程序使用Kafka等消息队列的一个非常常见的原因。不幸的是，当组件发生故障时，这种实现并不工作。我怀疑有很多真实的应用会 icon
  • 微服务/模块之间最常用的通信方式之一是通过事件进行异步通信。实施可靠的消息传递有时可能具有挑战性。在今天的文章中，我将向您介绍如何实现发件箱模式以保证事件的传递和可靠的消息传递。 发件箱模式（事务性发件箱或存储转发事件发布者）是解决方案。< icon
  • 作者：雷波, icon
  • 数据库存储引擎会在事务提交后立即将更改写入磁盘吗？让我们来探讨一下： WAL(Write Ahead Log：预写日志): 存储引擎用来提供原子性A和持久性D（ACID ）的一种日志。出于性能原因， icon