英文:
How to handle time-related events in Event Driven Architecture?
问题
我有一个分布式平台，允许客户进行购买，购买的物品存储在库存中：
销售应用 -> PurchaseEvent -> 库存应用
销售应用将PurchaseEvent发布到消息总线上，由库存应用异步消耗。一切运作良好。
有一个功能使得两个客户可以合并为一个。发生这种情况时，会引发CustomerMergedEvent，并且库存应用会消耗此事件以更新其数据（使得这两个客户的所有库存现在都在一个合并的客户下）。
当一切正常时，一切顺利。挑战在于购买事件的性能积压在被消耗时。在消耗CustomerMergedEvent之后，由库存应用消耗的任何购买都不会知道客户合并已经发生。我们甚至不会收到这种情况发生的警报。
我们可以使每次客户合并都导致新客户的产生，并让库存应用在接收到关于不再存在的客户的信息时通知我们。但是否有解决此事件时间相关问题的更高级别的解决方案？
英文:
I have a distributed platform which allows customers to make purchases, and the items which are purchased are stored in an inventory:
Sales app -> PurchaseEvent -> Inventory app
The Sales app raises the PurchaseEvent onto a message bus, which is asynchronously consumed by the Inventory app. This all works great.
There's one piece of functionality which makes it possible for two customers to be merged into one. When this happens, a CustomerMergedEvent is raised, and the Inventory app consumes this to update its data (so that all inventory for those two customers is now under one merged customer).
All is smooth when everything works fine. The challenge arrives when there is a performance backlog in PurchaseEvents being consumed. Any purchase consumed by Inventory after the CustomerMergedEvent has been consumed, will not know the customer merge has taken place. We'll also not even be alerted to the fact this has happened.
We could make it so every customer merge results in a new customer, and have the Inventory app alert us if it receives information about a customer which no longer exists. But are there solutions which solve this time-related issue with events on a higher level?
答案1
得分: 1
为什么你的库存服务不能存储“Customer A已经合并到Customer B”（通过CustomerMergedEvent）的事实呢？然后，所有购买事件处理器只需检查客户的先前合并（可能是递归的：A可能合并到B，B可能合并到C等等，如果有足够的滞后时间），并为购买使用“有效客户”。
如果由于某种原因无法记录合并的事实以通知未来的处理，另一种方法是建模合并正在进行的时期，并在您足够确信不会再有预合并客户的购买事件时宣布该时期结束。如果事件有与之关联的时间，可以使用水印技术。或者，如果您的消息总线被分区，以便涉及给定客户的所有事件都在同一分区（例如Kafka/Pulsar/Azure Event Hub），则可以编写CustomerMergedEvent，表示客户A合并到客户B两次：一次写入客户A的分区，一次写入客户B的分区（每次都意为它们各自的客户）。
英文:
Why can't your inventory service store the fact that Customer A has been merged into Customer B (by a CustomerMergedEvent)? Then all your purchase event processor has to do is check for a previous merge of the customer (potentially recursively: A could be merged into B which could merge into C and so on if there's enough lag) and use the "effective customer" for the purchase.
An alternative approach (if you can't for some reason record the fact of the merge in the inventory app to inform future processing) is to model a period where a merge is in progress and declare that period over when you're sufficiently sure that no more purchase events for the pre-merge customers will be coming. If the events have a time associated with them, watermarking might be sufficient. Alternatively, if your message bus is partitioned such that all events concerning a given customer are in the same partition (e.g. Kafka/Pulsar/Azure Event Hub), you can write the CustomerMergedEvent denoting that customer A merged into customer B twice: once to customer A's partition and once to customer B's partition (each time intended for their respective customer).
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论