Microservices QLDB是否与发件箱模式兼容？

我有一个QLDB最有意义的用例。我还认为发件箱模式对于数据可靠性是有意义的。然而，我担心发件箱条目会污染期刊

我的理解是，虽然我可以将“发件箱”表与主数据表分开，但日记账在整个分类账中共享。似乎发件箱模式传统上使用关系数据库，其中不可变日志的概念并不重要

---

随着数据集的增长，这会成为一个问题吗？更重要的是，是否有一种替代模式更适合使用？

因为日记账是提交到分类账的每一笔交易的不可变历史记录，如果将发件箱模式与QLDB一起使用，则分类账将包含通过发件箱表传递的消息的永久历史记录。如果您需要排队等待发送的消息的不可伪造的审核历史记录以及正在发送的消息的记录（“从表中删除”），这将非常有用。然而，如果您不需要这些，那么您将在分类账的整个生命周期中为这些消息支付存储费用，而不会从中获得太多价值

典型的事件驱动方法是使用QLDB的流式处理功能，它将一个Kinesis数据流与您的账本相关联。每次提交事务时，QLDB都会将事务发布到Kinesis数据流。这使您能够从分类账中发生的交易中驱动事件。使用这种方法，您可以将业务数据提交到分类账，而不用担心发件箱表。该文档应包含您在邮件中需要的信息。在提交时，QLDB将文档从事务推送到Kinesis，您可以在其中使用Lambda函数处理它，该函数将消息向前发送

需要注意的一点是，QLDB提供了至少一次向Kinesis交付数据的保证。这意味着您需要识别和处理（或容忍）潜在的重复消息。不过，您应该始终考虑分布式系统中的幂等性

如果您不想为动画付费，也不需要实时方法，那么您可以通过将QLDB导出到S3并对导出文件进行批处理来完成一些事情，但我先从流媒体开始。如果您想了解更多有关出口方法的信息，请与我联系

另见：

---

太棒了！是的，现在我认为流媒体比增加日志大小更好。这也会很好地简化事情。我本来打算用卡夫卡的，但我想运动是相对便宜的。实时性是必要的，但是批处理将是一个未来的问题（单事务和批处理事务）。