假设我将我的 Employee 实体表示为 Actor 。我有 2 个服务也被建模为 Actor 。他们都通过向它发送消息来操纵它收到的 Employee actor 的状态。现在假设这两个服务正在处理同一个参与者。现在，雇员 actor 完全有可能按以下顺序从两个服务 A 和 B 接收状态更改消息
Employee <- |a1|a2|a3|b1|b2|b3|
这很好。但有时它不是
Employee <- |a1|b1|a2|b2|a3|b3|
也许 a2依赖于 a1 改变的状态，但是b1改变了
类似于数据库，我们有事务，因此我们可以在整个事务生命周期内使用数据的单个快照/版本。
在命令式模型中，我们将锁定整个员工对象并更新其状态，类似于数据库的做法。
那么 Actor 是否有可能接收批量消息，这些消息将作为一个原子消息系列进行处理？还是我的数据建模本身存在缺陷？
最佳答案
由于我不知道 a1-a3 和 b1-b3 实际代表什么，所以我只能假设正确回答问题。在我看来，您的消息粒度太细了。例如，也许 a1-a3 试图在每条消息中只设置一个数据属性。 b1-b3 可能也是如此。
但是，您的消息应该关注的是引起员工的行为，而不是设置个人属性。因此，正如您自己建议的那样，将您的消息设计为行为，其中 a1-a3 将折叠为单个操作请求。这通常称为命令模式，您可以在其中命令/告诉对象/参与者做某事。这样做将导致每条消息的事务边界正确。
请注意，上面我说的是“对象/ Actor ”。您可以/应该在您的对象设计中使用相同的方法，而不仅仅是针对 Actor 。从意图揭示接口(interface)的角度思考并告诉您的域模型您希望它为您做什么，而不是将域对象/参与者视为愚蠢的数据持有者。
这就是我对你的问题的看法。 HTH.
沃恩
关于concurrency - 如何在actor模型中实现MVCC，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42257220/