处理Datomic中存储的乱序消息？ [英] Dealing with out-of-order messages stored in Datomic?
问题描述
背景
在分布式系统中，消息可能以乱序的方式到达。例如，如果在时间T1发送消息A，在时间T2发送消息B，则有可能在A之前接收到B。例如，如果A是消息，例如 CustomerRegistered，而B是 CustomerUnregistered，则这很重要。
In distributed systems messages can arrive in an out of order fashion. For example if message A is sent at time T1 and message B is sent at T2 there is a chance that B is received before A. This matters for example if A is a message such as "CustomerRegistered" and B is "CustomerUnregistered".
在其他数据库中，如果收到数据库中不存在的客户的CustomerUnregistered，我通常会写一个墓碑。然后，当接收到CustomerRegistered消息时，我可以检查该墓碑是否存在（根据使用情况，可能只是忽略此消息）。我当然也可以使用Datomic做类似的事情，但是我希望Datomic可以帮助我，这样我就不需要这样做。
In other databases I'd typically write a tombstone if CustomerUnregistered is received for a customer that is not present in the database. I can then check if this tombstone exists when the CustomerRegistered message is received (and perhaps simply ignore this message depending on use case). I could of course do something similar with Datomic as well but I hope that maybe Datomic can help me so that I don't need to do this.
一个潜在的解决方案我我想到的是：
One potential solution I'm thinking of is this:
您能否撤消不存在的客户实体（CustomerUnregistered），稍后在收到CustomerRegistered时，将客户实体写在撤回之前的历史记录？如果：db / txInstant 可以设置为消息中定义的时间戳，那将是一件很整洁的事情。
Can you perhaps retract a non-existing customer entity (CustomerUnregistered) and later when CustomerRegistered is received the customer entity is written at a time in history before the retraction? It would be neat (I think) if the :db/txInstant could be set to a timestamp defined in the message.
问题
在Datomic中，如何以一种惯用的方式处理这种情况？
How would one deal with this scenario in Datomic in an idiomatic way?
推荐答案
作为一般原则，请勿让您的应用程序代码操纵：db / txInstant 。 ：db / txInstant 表示您学习事实的时间，而不是事实发生的时间。
As a general principle, do not let your application code manipulate :db/txInstant. :db/txInstant represents the time at which you learned a fact, not the time at which it happened.
也许您应该将注销视为添加有关客户的Datom（例如，通过即时键入的：customer / unregistered 属性），而不是撤消注册该客户的Datom（这意味着：忘记该客户的存在）。
Maybe you should consider un-registration as adding a Datom about a customer (e.g via an instant-typed :customer/unregistered attribute) instead of retracting the Datoms of that customer (which means: "forget that this customer existed").
但是，如果确实要撤回客户的需求，我会使用一条记录来防止发生客户注册交易（我会通过交易功能强制执行）。
However, if retracting the datoms of customer is really the way you want to do things, I'd use a record which prevents the customer registration transaction to take place (which I'd enforce via a transaction function).
这篇关于处理Datomic中存储的乱序消息？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
