分布式事务教程

本案例源码是如何使用Spring Boot 和Kafka Streams实现基于SAGA 模式的分布式事务。有三个微服务： 订单服务--它向Kafka主题发送订单事件，并协调分布式事务的过程 支付服务--它根据订单价格在客户账户上执行本地事务 库存服务

一个支持多种语言的分布式事务框架，支持saga、tcc、xa、2-phase message、outbox patterns#发件箱 第一个致力于微服务分布式事务解决方案的开源 Golang 项目。 支持多种模式：Saga、XA、TCC、OutBox。 支持多

程序员从无到有构建代码，应该注重组合思维，做出来的东西需要能够相互组合在一起；而架构师是从上而下的视角，因为不参与具体细节构建，但为了落地，应该具有多维度多维度视角，从程序员到架构师思维转变很重要。 下面这篇文章谈了架构师的多维度视角：

如何组合多个存储引擎合并组成分布式事务？Mysql、Redis、Mongo都是非常火爆的存储，各有各的优势。在实际应用中，同时使用多个存储是很常见的，保证跨多个存储的数据一致性成为一种需求。本文给出了一个跨多个存储引擎实现分布式事务的示例：Mysql、Redis 和 Mong

一旦你学会用业务眼光去看，就不会有任何需要用多线程同步锁实现的竞赛条件了。比方说，以下是需求。 1. 如果订单已经发货了，不要让用户取消订单。 2. 如果订单已经被取消，不要让用户运送订单。 这里的竞赛条件是当我们有两个用户在看同一个订单，这个订单既

想象一下，在一个山谷里有一座城市。在山谷的两边，有一支由将军指挥的军队。左边的山上站着爱丽丝将军和她的军队。右边的山头上，站着鲍勃将军和他的军队。爱丽丝和鲍勃想占领这座城市，但双方都没有足够大的军队来单独完成这一任务。爱丽丝和鲍勃必须同时进攻城市，才有机会占领它。 <

Redpanda 是对 Kafka 的 C++ 重写，提供与 Kafka API 的 100% 兼容性。Redpanda 不需要 Zookeeper 或 JVM，因此在生产中操作起来不太复杂。因此，更广泛的开发人员受众的可访问性。

本文介绍了一个直接支持分布式标识符生成的实现。 1. 分布式系统中的并发标识符生成每个主机都有一个预定义的唯一主机标识符或hostId 。

这是Pat Helland 的论文：Pat Helland 的 CIDR22 论文，Pat的论文总是非凡的、与众不同的。他们

选择事件存储数据库需要大量研究。这可能是一个单独的博客系列的主题（可能在将来），所以我的计划是从不同的角度来解决它。不要试图找到最佳解决方案（因为恕我直言不存在）。相反，尝试找到一个最佳的折衷方案并为改变做好准备。使用Akka Persistence有一个巨大的优势，即持久性只是一个

Pulsar 事务 (txn) 使事件流应用程序能够在一个原子操作中消费、处理和生成消息。开发此功能的原因可以总结如下。 随着流处理的兴起，对具有更强处理保障的流处理应用的需求也随之增长。例如，在金融行业，金融机构使用流处理引擎为用户处理借

在本文中，我将向您展示使用 Spring Transactional 注释的最佳方式。 Spring事务注解从 1.0 版本开始，Spring 就提供了对基于 AOP 的事务管理的支持，允许开发人员以声明方式定义事务边界。不久

Alex Petrov 是 Apple 的一名软件工程师。他写了一本关于 Database Internals 的精彩书籍，深入探讨了分布式数据系统的工作原理。我们将总结他关于数据库管理系统 (DBMS) 背后架构的书中的一小段内容。 概括

在构建任何分布式或非分布式系统时，您最终会处理许多数据ID标识符，从数据库行一直到生产系统版本的ID标识符。决定如何生成标识符有时非常简单；例如，您可能只是将一个自动递增ID的数字作为您的数据库中的主键。 然而，在分布式系统中，让一个数字从

Apache Pulsar 是一个开源的分布式发布-订阅消息系统，与kaffka根本不同的是持久性存储。在 Kafka 中，日志保存在代理上，而 Pulsar 使用Apache BookKeeper，这似乎是一个真正的优势，尤其是在扩展方面。BookKeeper 的另一个诱人特性是分层存储。

我们并不是说事件溯源总是一个糟糕的选择。这是一个真正强大的概念。但是，您应该警惕它可能给您的项目增加的复杂性。我们的看法是你不应该用它来解决所有类型的问题，而应该将它应用到选定的业务领域（它可能对所有类型的技术和技巧都是通用的）。Kafka Streams 可能对我们来说更加陡峭的学