Brighter 与发件箱模式：实现弹性系统的至少一次消息交付

最新推荐文章于 2025-12-28 09:18:17 发布

原创最新推荐文章于 2025-12-28 09:18:17 发布 · 1.4k 阅读

34 ·

CC 4.0 BY-SA版权

文章标签：

#c# #.net #brighter #发件箱模式 #design pattern #设计语言

简介

我将开启一个关于 Brighter 的系列，重点探讨 **发件箱模式**（Outbox Pattern）。
本文将深入解析发件箱模式的工作原理，以及 Brighter 如何通过原生支持实现这一模式。在分布式系统中，当需要将数据库更新与消息发布结合时（尤其是传统两阶段提交协议不可行的场景），该模式是确保事务一致性的重要工具。

背景

在深入探讨发件箱模式之前，先看它解决的问题。

问题 1：数据库更新后的单条消息发布

假设你使用消息网关开发应用，典型的流程可能是：更新数据库实体后发布消息（如 `OrderCreated`）。如果消息代理（如 RabbitMQ）在发布过程中宕机，数据库更新成功但消息丢失，导致系统状态与下游服务不一致。

简单的解决方案可能依赖重试机制，但无法保证原子性。

问题 2：多条消息的原子性需求

随着应用扩展，可能需要在单个事务中发布多条消息（如 `OrderPaid` 和 `InventoryUpdated`）。如果第二条消息发布失败，第一条可能已送达，违反业务对幂等性或原子性的要求。

例如：
1. 更新数据库记录（如 order.Status = "Paid"）。
2. 发布 OrderPaid 和 InventoryUpdated。
3. 如果 InventoryUpdated 在 OrderPaid 成功后失败，下游系统将收到不完整的流程。

此场景凸显了在数据库写入与消息发布之间实现事务性保障的必要性。

发件箱模式的核心价值

发件箱模式通过以下方式确保事务一致性与消息的至少一次交付：

事务性存储：消息与业务数据在同一事务中持久化。
异步消息投递：后台进程（如 Sweeper）从发件箱读取消息并发布到消息代理。
故障恢复：若应用在消息发布前崩溃，消息仍保留在发件箱中，待系统恢复后重试。

![发件箱设计](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qye69dpatwum2jbmra4e.png)

关键优势

1. 事务一致性：消息与数据库更新绑定在同一事务中，无需依赖分布式事务。
2. 容错性：若消息代理失败，消息会被重试直至成功。
3. 解耦架构：应用专注于本地事务，消息投递由异步机制处理。

Brighter 的发件箱模式实现

Brighter 提供了对多种数据库（如 PostgreSQL、MySQL）的发件箱模式原生支持。

Post 方法的内部工作原理

当你调用 Post 方法发送消息时，Brighter 会在底层隐式应用发件箱模式：

1. Deposit 阶段：

Post 方法内部调用 `Deposit`，将消息存储至配置的发件箱提供者（如 InMemory、PostgreSQL），并与数据库操作共享同一事务。
确保事务提交成功后消息才被持久化。

2. ClearOutbox 阶段：

事务完成后，调用 `ClearOutbox` 并传入消息 ID。
该方法将消息发布至消息代理（如 RabbitMQ、Kafka），并在成功投递后从发件箱删除。

默认行为

默认情况下，Brighter 使用内存发件箱。虽然适合测试或无需严格保障的场景，但存在风险：应用崩溃可能导致消息丢失。

配置方法

在 Brighter 中启用发件箱模式的示例代码：

services
    .AddBrigther()
    .UseInMemoryOutbox() // 或 UseExternalOutbox(...) 配置外部存储
    .UseOutboxSweeper(options =>
    {
        options.TimerInterval = 5;      // 轮询间隔（秒）
        options.MinimumMessageAge = 500; // 消息最小年龄（毫秒）
    });

需安装以下 NuGet 包：