Подтвердить что ты не робот

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

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

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

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

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

4b9b3361

Ответ 1

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

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

На одном примере реализации Erlang VectorClock смотрите distributerl Erlang OTP Supervisors также могут предоставить некоторую необходимую инфраструктуру для достижения консенсуса, но есть некоторые мысли, что Консенсус является невозможным в асинхронных передачах сообщений через распределенные системы. Для получения дополнительной информации см. Вашу страницу с ссылкой на wiki.

Ответ 2

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

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

Ответ 3

Erlang promises те вещи (http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf раздел 3.1 (39-40)):

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

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