Заказ мероприятий Mnesia

Мы разрабатываем приложение, в котором несколько процессов на разных узлах распределенной системы подписываются на события мнезии. Таблица записывается из одного процесса на одном из узлов.

Однако возникла неуверенность в том, можем ли мы быть уверены, что получим события в том же порядке, что и операции над таблицей.

E.g:

mnesia:delete(tab1, SomeRec),
mnesia:write(tab1, SomeOtherRec)

Если бы мы иногда получали событие удаления после события записи, наш дизайн не работал бы, и нам пришлось бы создать какой-то другой механизм уведомления.

Кроме того, как насчет операций с разными таблицами (из одного процесса)?

mnesia:write(tab1, SomeRec),
mnesia:write(tab2, SomeOtherRec)

Можем ли мы быть уверены, что всегда получим событие с вкладки 1 перед событием с вкладки 2? На всех процессах и на всех узлах?


events subscribe erlang mnesia
person Lii    schedule 01.12.2010    source источник
comment
Почему-то у меня сложилось впечатление, что вы пытаетесь использовать события мнезии для чего-то, что лучше сделать по-другому. Однако не могу понять, почему. Можете ли вы уточнить, что именно вы хотите сделать с этими табличными событиями?   -  person Peer Stritzinger    schedule 01.12.2010
comment
Это вполне возможно. Но все же было бы интересно разобраться с этим.   -  person Lii    schedule 01.12.2010

Ответы (3)


arrow_upward
1
arrow_downward

Для Эрланга в целом отправка сообщений от процесса A к процессу B гарантированно всегда будет в порядке.

Однако для сообщений между более чем двумя процессами нельзя гарантировать, что сообщения, отправленные от A к B, поступят раньше, чем сообщения, отправленные от C к B, даже если сообщения A были глобально отправлены первыми. Планировщик, сетевая задержка или проблемы с сетью (особенно если A и C не находятся на одном узле) могут быть хорошими примерами того, почему такие гарантии трудно дать.

Если все ваши события отправляются из одного и того же процесса, порядок может быть верным. В противном случае вы не можете доверять порядку событий.

Что касается мнений, все они управляются в mnesia_subscr.erl, который представляет собой единый gen_server, отвечающий за пересылку всех событий для узла, независимо от таблицы. Таким образом, это должно соответствовать принципу A к B и гарантировать упорядоченные события.

person I GIVE TERRIBLE ADVICE    schedule 01.12.2010
comment
Я понимаю, что сообщения между процессами всегда в порядке. Но всегда ли mnesia отправляет сообщения в том порядке, в котором выполняются операции в вызывающем процессе? Например. если таблица заблокирована для записи при вызове mnesia:write, может ли это привести к задержке события и отправке какого-либо другого события первым? - person Lii; 01.12.2010
comment
Это будет зависеть от того, как вы реализуете отправку событий. Это делается внутри транзакции, после ее завершения и т. д.? Насколько я знаю, вы никогда не должны делать вещи с побочными эффектами внутри транзакции, потому что это может быть повторено несколько раз. - person I GIVE TERRIBLE ADVICE; 01.12.2010
comment
@IGTA: Лии говорил о событиях таблицы mnmesia, поэтому вопрос также о том, как они реализованы. Отправляются ли они одним внутренним процессом (на узел?, на таблицу?) - person Peer Stritzinger; 01.12.2010
comment
Ах, извините, я не правильно вас понял. События подписчика управляются в mnesia_subscr.erl, который реализован как gen_server. Так что да, все сообщения поступают из одного и того же процесса для данного узла, независимо от того, какая таблица. Я отредактирую свой ответ, чтобы добавить эту информацию. - person I GIVE TERRIBLE ADVICE; 01.12.2010
comment
Это звучит несколько обнадеживающе. Таким образом, это должно придерживаться ... примерно до тех пор, пока у нас есть проблема, но приятно слышать, что кто-то еще делает такой же анализ. - person Lii; 01.12.2010
comment
Вопрос в следующем: отправляет ли mnesia события на mnesia_subscr gen_server в ожидаемом порядке при любых условиях? - person Lii; 01.12.2010

arrow_upward
0
arrow_downward

Я не знаю, будет ли mnesia делать то, что вы хотите по умолчанию, но если предположить, что это не так, то, возможно, вам нужно начать рассматривать использование алгоритмов распределенного консенсуса, таких как Paxos? Существует реализация в виде lib_paxos, библиотеки с открытым исходным кодом под лицензией GPL.

Излишне говорить, что это повлияет на вашу производительность, но обеспечит согласованность.

person Andrew Matthews    schedule 03.12.2010
comment
К сожалению, это не вариант. Либо mnesia себя ведет, либо мы должны создать свой собственный механизм уведомления. - person Lii; 03.12.2010
comment
да, я (как бы) предполагал, что Paxos — это надежный способ сделать это в распределенной среде... - person Andrew Matthews; 06.12.2010

arrow_upward
0
arrow_downward

Paxos — это решение, которое вы ищете. Сделать выборку принятых значений максимальным из ранее принятых предложений. Это создаст последовательность, которую вы можете использовать для заказа инструкций.

person Jérôme Verstrynge    schedule 02.05.2011