分布式事务教程

ULID 是 UUID 的替代品。它是可排序的并且基于时间戳+随机种子。有多种语言的实现可用。 Shopify从UUID切换到ULID，INSERT提升50%，以下是他们经验： 分布式系统使用不可靠的网络

下图来自于Redhat的

所有成功的数据驱动组织都有一个共同点；他们有一个高质量和高效的数据创建过程。数据创建通常是数据团队成功与失败之间的区别。 数据创建的架构模式在数据创建中，有三种类型的架构模式：事件溯源EventSourcing变更

长期以来，事务数据库一直是应用程序设计中最关键的组成部分。为什么？因为稳定的数据库通常是混乱的分布式世界中正确性的最终实施点。没有他们，我们就会多付钱和少收钱。我们会失去试图从机场回家的乘客，我们会丢失购物车中的物品。我们的在线帐户会丢失、复制或损坏，并变得无法操作。 

在 web 应用程序中，除了更新数据库之外，请求处理通常具有次要效果，例如更新另一个数据源或发送电子邮件。但是很难可靠地控制二次效应发生的时间和条件。 在这篇博文中，我将向您展示如何使用

作为一名软件工程师，我一直想知道事务是如何工作的，以及它们在分布式系统中是如何管理的，所以我用谷歌搜索了一下，发现了很多模式和规范，比如 JTA、2PC、SAGA、事件驱动架构、发件箱等…… 在本文中，我将概述分布式事务，并尝试解释两阶段提交模式。

微服务架构的一个重要设计原则是每个服务数据库模式。这种模式帮助我们保持服务松散耦合，以便它们可以独立开发、部署和扩展。换句话说，域数据被封装在微服务中，如果其他服务需要数据，则它们通过调用 API 来实现。 这一设计原则带来了一个有趣的挑战：在微服

检测重复消息的唯一方法是在生产者端为事件生成一个唯一标识符。只有使用这些标识符，消费者才可能知道它第二次处理同一条消息，而不是具有相同属性的不同消息。 为了防止两次处理同一条消息，常用的方法是将它们存储在指定的表中，通常命名为processed_m

分布式有状态流处理具有挑战性，尤其是在处理故障和恢复方面。在流处理中，最常被问到的问题之一是“我的流处理系统是否保证每条记录都被处理一次且仅一次，即使在处理过程中遇到一些故障？” 通过“ exactly-once（精确一次）”语义，我的意思是每个传

微服务/模块之间最常用的通信方式之一是通过事件进行异步通信。实施可靠的消息传递有时可能具有挑战性。在今天的文章中，我将向您介绍如何实现发件箱模式以保证事件的传递和可靠的消息传递。 发件箱模式（事务性发件箱或存储转发事件发布者）是解决方案。<

在系统中使用事件很棒，但是您如何确定您是否可靠地调度了事件？事件的传输需要可靠地完成，同时保持整个系统的一致性，无论是最终的还是立即的。在典型的设置中，数据库用于存储信息，队列用于在进程和系统之间发送消息。通常，事件在将信息存储在数据中的同一操作中直接分派到队列。这看起来似乎并没有明显的错误

由于我的新电动自行车在商店里而无法再次骑着它去上班（这次是因为电线问题导致自行车无法运行！），我开始考虑如何在我的自行车中创造一些冗余设置，这样我就不会因为简单的维护或供应链问题而一次被困在地铁上数周。如果我在修理当前自行车时要骑另一辆自行车怎么办？这肯定会有帮助，但电动自行车很贵，而且我在

您的应用正在变得越来越好。它有更多的功能，更多的活跃用户，并且每天收集更多的数据。您的数据库现在导致应用程序的其余部分变慢。数据库分片可能是您问题的答案，但许多人不知道它是什么，最重要的是，不知道何时使用它。在本文中，我们将讨论什么是数据库分片、它是如何工作的以及使用它的最佳方式。

如果你想知道Saga模式是否适合你的场景，问问你自己：你的逻辑是否涉及多个步骤，其中一些步骤跨越机器、服务、分片或数据库，对于这些步骤，部分执行是不可取的？ 事实证明，这正是sagas的用武之地。 也许你

在本文中，我想讨论实现 CDC 的几种不同方法，以及一些关键应用程序是什么以及 CDC 如何融入现代数据流架构的大局。 有几种从数据库中提取变更事件的方法，每一种都有自己的优点和缺点。因此，让我们仔细看看每种方法。  

将 ActiveMQ 与 Kafka 进行比较类似于将关系数据库与 NoSQL 进行比较。 ActiveMQ 不像 Kafka 那样适合云。但这并不意味着 ActiveMQ 不再有任何用例。仍然有大量业务用例需要保证信息的交付。