Как поддержка Erlang * прозрачного * распределения участников влияет на дизайн приложения?

Question

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

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

Я почти уверен, что Erlang не обещает прозрачно решать эти классы проблем, поэтому мой вопрос, как разработчики Erlang справляются с этим? Вы проектируете свое приложение так, как будто все участники находятся в одном и том же пространстве процессов, и затем решаете проблемы распространения только тогда, когда наступает время их фактического распространения?

Если это так, является ли эта прозрачная дистрибуция в Erlang действительно действительно связанной с проводным протоколом, используемым для удаленного обмена сообщениями, а не прозрачной в том смысле, что истинное распределенное приложение все еще требует тщательный дизайн на уровне приложений?

Answer 1

Вы правы, что erlang по сути своей не решает проблемы упорядочения / причинности или консенсуса. Что Erlang делает для вас абстрагироваться, так это разницу между отправкой сообщений на локальные или удаленные узлы.

Я не уверен, что было бы действительно возможно решить эти проблемы с помощью языкового дизайна. Это более правильно принадлежит в рамках. У структуры OTP есть некоторые инструменты, чтобы помочь с этим. Действительно, хотя это несколько зависит от конкретной проблемы, которую вы решаете.

Один из примеров реализации Erlang VectorClock можно найти в distribterl Erlang OTP Supervisor также может предоставить некоторую необходимую инфраструктуру для консенсуса, но есть мнение, что консенсус невозможен в асинхронных распределенных системах передачи сообщений. Обратитесь к указанной вики-странице для получения дополнительной информации об этом.

Answer 2

Эрланг обещает эти вещи (http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf раздел 3.1 (39-40)):

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

и отдых за вами. Если вы хотите знать, почему, смотрите главу 2. Вскоре вы можете отправить сообщение для обработки, если вы знаете его PID, даже если он находится на другом фрагменте HW. Вы не можете быть уверены, что сообщение пришло, если вы не получили ответ с общим секретом. Вы можете быть уверены, что получите сообщение об ошибке при сбое процесса, когда будете следить (или связывать) его. Это базовые элементы, с помощью которых вы можете создавать то, что хотите.

Answer 3

Эрланг, фактически, решает эти проблемы прозрачно. Это может быть сделано, потому что это функциональный язык с неизменяемыми (с одним присваиванием) переменными. Он использует модель Actor для параллелизма и был специально разработан для обеспечения возможности горячей замены кода и одновременного программирования без необходимости беспокоиться о синхронизации .

.

Статья Википедии на самом деле имеет довольно хорошее описание этого. Насколько я понимаю, Ericsson изобрел язык как практический способ программирования массово параллельных телефонных коммутаторов.