Mnesia 事件的排序
我们正在开发一个应用程序，其中分布式系统中不同节点上的多个进程订阅 mnesia 事件。该表是从节点之一上的单个进程写入的。
然而，我们是否能够确保按照与表上操作相同的顺序接收事件，这就出现了不确定性。
例如：
mnesia:delete(tab1, SomeRec),
mnesia:write(tab1, SomeOtherRec)
如果我们有时在写入事件之后收到删除事件，我们的设计将不起作用，我们将不得不创建其他类型的通知机制。
另外，对不同表（来自同一进程）的操作怎么样？
mnesia:write(tab1, SomeRec),
mnesia:write(tab2, SomeOtherRec)
我们能否确保始终先从 tab1 获取事件，然后再从 tab2 获取事件？在所有进程和所有节点上？
We’re developing an application where multiple processes on different nodes in a distributed system subscribe to mnesia events. The table is written to from one single process on one of the nodes.
However uncertainty has arose about if we can be sure to receive the events in the same order as operations on the table.
E.g:
mnesia:delete(tab1, SomeRec),
mnesia:write(tab1, SomeOtherRec)
If we sometimes get the delete event after the write event our design would not work and we would have to create some other kind of notification mechanism.
Also, how about operations on different tables (from the same process)?
mnesia:write(tab1, SomeRec),
mnesia:write(tab2, SomeOtherRec)
Can we be sure to always get the event from tab1 before the one from tab2? On all processes and all nodes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于 Erlang 整体而言，从进程 A 到进程 B 的消息发送保证始终按顺序进行。
但是，对于两个以上进程之间的消息，您不能保证从
A发送到B的消息会先于从C发送到B的消息到达。B，即使A的消息首先全局发送。调度程序、网络延迟或网络问题（特别是如果A和C不在同一节点上）可能是为什么很难提供此类保证的好例子。如果您的所有事件都是从同一进程发送的，那么排序就可以肯定了。否则，你就不能相信事件的顺序。
至于mnesia事件，它们都在
mnesia_subscr.erl中管理，它是一个单独的gen_server，负责转发节点的所有事件，无论表如何。因此，这应该遵守A到B原则并保证有序事件。For Erlang as a whole, the sending of messages from a process
Ato a processBis guaranteed to always be in order.However, for messages between more than two processes, you can not guarantee that messages sent from
AtoBwill arrive before messages sent fromCtoB, even ifA's messages were globally sent first. The scheduler, network latency or network problems (especially ifAandCaren't on the same node) might be good examples of why such guarantees are hard to give.If all your events are sent from the same process, ordering can be a sure thing. Otherwise, you can't trust the events' order.
As for mnesia events, They're all managed in
mnesia_subscr.erl, which is a single gen_server taking charge of forwarding all events for a node, no matter the table. This should thus adhere to theAtoBprinciple and guarantee ordered events.我不知道 mnesia 是否会默认执行您想要的操作，但假设它不会，那么您可能需要开始考虑使用分布式共识算法，例如 Paxos？有一个以 lib_paxos 形式实现的实现，它是一个 GPL 许可的开源库。
不用说，这会影响您的性能，但会确保一致性。
I don't know whether mnesia will do what you want by default, but assuming that it doesn't then perhaps you need to start looking at the use of distributed consensus algorithms such as Paxos? There is an implementation in the form of lib_paxos, a GPL licensed open source library.
Needless to say, this will impact your performance but ensure consistency.
Paxos 是您正在寻找的解决方案。使接受值的选择是早期接受的提案的最大值。这将创建一个序列，您可以使用它来订购指令。
Paxos is the solution you are looking for. Make the selection of accepted values is a Max of earlier accepted proposals. This will create a sequence you can use to order your instructions.