發件箱模式雖然聽上去可能很簡單，但是在平時開發中可能會忽略掉。如果還不能理解，我們可以將它類比到生活的場景，寄信人只需要寫好信件，放入收件箱，之后就不用管了。送信的人會來收件箱取走信件，根據信件里需要送到的地址，將信件送至目的地。這樣做的好處就是，寄信人寫好信之后，就不需要等待收信人有空的時候才能寄信，只需要往發件箱里丟就好了。
?前言
微服務架構如今非常的流行，這個架構下可能經常會遇到“雙寫”的場景。雙寫是指您的應用程序需要在兩個不同的系統中更改數據的情況，比如它需要將數據存儲在數據庫中并向消息隊列發送事件。您需要保證這兩個操作都會成功。如果兩個操作之一失敗，您的系統可能會變得不一致。那針對這樣的情況有什么好的方法或者設計保證呢？本文就和大家分享一個“發件箱模式”, 可以很好的避免此類問題。
下訂單的例子
假設我們有一個 OrderService 類，它在創建新訂單時被調用，此時它應該將訂單實體保存在數據庫中并向交付微服務發送一個事件，以便交付部門可以開始計劃交付。
你的代碼可能是下面這樣子的：
@Service
public record OrderService(
IDeliveryMessageQueueService deliveryMessageQueueService,
IOrderRepository orderRepository,
TransactionTemplate transactionTemplate) implements IOrderService {
@Override
public void create(int id, String description) {
String message = buildMessage(id, description);
transactionTemplate.executeWithoutResult(transactionStatus -> {
// 保存訂單
orderRepository.save(id, description);
});
// 發送消息
deliveryMessageQueueService.send(message);
}
private String buildMessage(int id, String description) {
// ...
}
}
可以看到我們在事務中將訂單保存在數據庫中，然后我們使用消息隊列將事件發送到交付服務。這是雙寫的一個場景。
這么寫，會遇到什么問題呢？
首先，如果我們保存了訂單但是發送消息失敗了怎么辦？送貨服務永遠不會收到消息。
那你可能想到把保存訂單和發消息放到同一個事務中不就可以了嗎，就是是將 deliveryMessageQueueService#send? 移動到與 orderRepository#save相同的事務中，如下圖：
transactionTemplate.executeWithoutResult(transactionStatus -> {
// 保存訂單
orderRepository.save(id, description);
// 發送消息
deliveryMessageQueueService.send(message);
});實際上，在數據庫事務內部建立 TCP 連接是一種糟糕的做法，我們不應該這樣做。
有沒有更好的方法呢？
我們可以訂單表所在的同一數據庫中有一個表“發件箱”（在最簡單的情況下，它可以有一個列“消息”和當前時間戳）。保存訂單時，在同一個事務中，我們在“發件箱”表中保存了一條消息。消息一發送，我們就可以將其從發件箱表中刪除，代碼如下：
@Service
public record OrderService(
IDeliveryMessageQueueService deliveryMessageQueueService,
IOrderRepository orderRepository,
IOutboxRepository outboxRepository,
TransactionTemplate transactionTemplate) implements IOrderService {
@Override
public void create(int id, String description) {
UUID outboxId = UUID.randomUUID();
String message = buildMessage(id, description);
transactionTemplate.executeWithoutResult(transactionStatus -> {
// 保存訂單
orderRepository.save(id, description);
// 保存到發件箱
outboxRepository.save(new OutboxEntity(outboxId, message));
});
deliveryMessageQueueService.send(message);
// 刪除
outboxRepository.delete(outboxId);
}
private String buildMessage(int id, String description) {
// ...
}
}
可以看到，我們在一次事務中將訂單和發件箱實體保存在我們的數據庫中。然后我們發送一條消息，如果成功，我們刪除這條消息。
如果 deliveryMessageQueueService#send? 失敗會怎樣？（例如，您的應用程序被終止或消息隊列或數據庫不可用）。在這種情況下，outboxRepository#delete 將不會運行，我們必須重試發送消息。
它可以使用將在后臺運行的計劃任務來完成，該任務將嘗試發送在表發件箱中顯示超過 X 秒（例如 10 秒）的消息，如下面的代碼。
@Service
public record OutboxRetryTask(IOutboxRepository outboxRepository,
IDeliveryMessageQueueService deliveryMessageQueueService) {
@Scheduled(fixedDelayString = "10000")
public void retry() {
List<OutboxEntity> outboxEntities = outboxRepository.findAllBefore(Instant.now().minusSeconds(60));
for (OutboxEntity outbox : outboxEntities) {
deliveryMessageQueueService.send(outbox.message());
outboxRepository.delete(outbox.id());
}
}
}
在這里你可以看到，我們每 10 秒運行一個任務，并發送之前沒有發送過的消息。如果消息成功發送到消息隊列，但發件箱實體沒有從數據庫中刪除（例如因為數據庫問題），那么下次該后臺任務將嘗試再次將此消息發送到消息隊列。但這也意味著我們消息的消費者必須做好冪等處理，因為可能會多次接收相同的消息。
發件箱模式
通過上面的例子，我們可以抽象出“發件箱模式”。
- 在數據庫里面額外增加一個outbox表用于存儲需要發送的event
- 把直接發送event的步驟換成先把event存儲到數據庫outbox表
- 程序啟動一個 job 不斷去抓取 outbox 表里面的記錄，通過推送線程完成不同業務的推送
- 最后刪除發送成功的記錄
- 提醒消息消費端要做好冪等處理
總結
發件箱模式雖然聽上去可能很簡單，但是在平時開發中可能會忽略掉。如果還不能理解，我們可以將它類比到生活的場景，寄信人只需要寫好信件，放入收件箱，之后就不用管了。送信的人會來收件箱取走信件，根據信件里需要送到的地址，將信件送至目的地。這樣做的好處就是，寄信人寫好信之后，就不需要等待收信人有空的時候才能寄信，只需要往發件箱里丟就好了。
