我有一个分布式平台，允许客户进行购买，购买的商品存储在库存中:
销售应用->PurchaseEvent→库存应用
Sales应用程序将PurchaseEvent引发到消息总线上，该消息总线由Inventory应用程序异步消费。这一切都很好。
有一个功能可以将两个客户合并为一个客户。当这种情况发生时，CustomerMergedEvent被引发，Inventory应用程序使用它来更新它的数据(这样这两个客户的所有库存现在都在一个合并的客户下)。
一切顺利。当使用PurchaseEvents中的性能积压时，挑战就来了。在之后被库存消耗的任何购买CustomerMergedEvent已被使用，将不知道客户合并已经发生。我们甚至不会被提醒这已经发生了。
我们可以这样做，所以每个客户合并的结果在一个新的客户，并有库存应用程序提醒我们，如果它收到的客户的信息，不再存在。但是是否存在解决方案能够在更高层次上解决与事件相关的时间问题呢?
为什么您的库存服务不能存储客户A已被合并到客户B(由CustomerMergedEvent)的事实?然后你所有的购买事件处理器所要做的就是检查之前的客户合并(可能递归地:如果有足够的延迟，a可能合并到B, B可能合并到C，等等)，并使用"有效客户";用于购买。
另一种方法(如果你因为某些原因不能在库存应用程序中记录合并的事实，以通知未来的处理)是模拟一个合并正在进行的时期，并在你足够确定合并前的客户不会再购买事件时宣布该时期结束。如果事件与时间相关联，则水印可能就足够了。或者，如果你的消息总线是分区的，这样所有关于给定客户的事件都在同一个分区中(例如Kafka/Pulsar/Azure Event Hub)，你可以写CustomerMergedEvent表示客户a合并到客户B两次:一次到客户a的分区，一次到客户B的分区(每次用于各自的客户)。