本文主要是介绍分布式Erlang/OTP（学习笔记）（一），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
Erlang分布式基础
假设你在机器A和机器B上各跑着一个Simple Cache应用的实例。要是在机器A的缓存上插人一个键/值对之后，从机器B上也可以访问，那可就好了。显然，要达到这个目的，机器A必须以某种方式将相关信息告知给机器B。传递该信息的方式有很多，有些方式简单，有些方式复杂。但无论采用哪种方式，都涉及分布式，因为你需要进行跨机器通信。
Erlang极大地简化了某些类型的分布式编程，用不了几行代码，你瞬间就可以建立多台机器间的网络通信。这一切都以Erlang的两个基本特性为基础:
复制式进程通信;
位置透明性。
复制式进程间通信
在解决两段并发执行的代码段之间的通信问题时，最常用的模式就是让这两段代码共享某块内存,前提是它们都在同一台机器上运行。该通信模型如图所示。然而它有很多问题，其中之一是当你希望每段代码都运行在独立的机器上时，就必须换用一种完全不同的通信方式。代码中的很大一部分将被迫重写。
这类问题正是Erlang的缔造者们从一开始就要解决的问题。要想在通信透明化的同时构建出容错的系统，要想让一台机器不至于因为相邻机器的崩溃或机器间的网络故障而宕机，就必须抛弃共享。
相反，Erlang的进程间通信采用的是严格的异步消息传递（发送消息后无须等待网络上的确认)，接收方收到数据时实际上获取了数据的一份独立的副本;此后接收方将无法感知发送方对数据所做的任何操作，反之亦然。后续的任何通信都必须借助额外的消息才能进行。无论是运行在同一台机器上的进程还是运行在不同机器上并通过网络互联的进程,这种模型都非常凑效。
.在Erlang中没有共享，只有消息传递，因此分布式还是单机本质上没有什么区别。大部分代码完全不用关心进程最终在何处运行。
然而在进行网络通信时仍然有很多需要注意的问题。在使用本地通信时，只要接收方进程还“活着”消息就一定能送达，而且几乎没有传输延迟。然而一旦涉足网络，就不得不考虑路由过程中的消息延迟以及网络本身的故障了。发送方通常无法辨别接收方到底是崩溃了还是因自身的bug而未能给出应答。出于健壮性考虑，即便是采用本地通信，发送方也应该对这些故障有所准备。但在分布式系统中总会存在多种导致不确定性行为的因素。
位置透明性
我们已经讲过，进程间的通信方式与接收方在本地机器上还是在远程机器上无关。这点在语法层面上仍然成立。以下是发送方向位于同一台机器上的接收方发送消息（本例中是个字符串)的语法:
Pid ! "my message"
然后再来看看怎么将同一条消息发向另一台机器:
Pid ! "my message"
二者一模一样:!（发送）运算符具有位置透明的属性—一接收方在哪台机器上并不重要，指引消息走向的信息统统都隐含在进程标识符之中了。Erlang会确保进程标识符在多机网络上的惟一性。这个属性使你可以无障碍地将程序的部署规模从一台机器扩展到数十台机器;你也可以反其道而行之，将那些原本部署在数十台机器上的程序集成到你的笔记本电脑上进行测试。
初看起来位置透明性好像没什么大不了的,然而你应该认识到，正是它大大释放了我们编程风格的自由度。当跨计算机通信的门槛不再那么陡峭，你终将获得翻越它的力量，并将之看作是习以为常的事情-─除非是出于某些特殊原因，否则你的进程完全可以运行在相互独立的多台机器上，这时你便可以开始设计在以前看来复杂得超乎想象的系统了。
这两个属性一复制式通信和位置透明性——使Erlang分布式编程真正成为了一件令人愉悦的事情。
节点与集群
先前我们故意模糊化了一个概念:我们所讨论的机器到底指的是什么呢?在很多场景下，一套硬件上只会运行一个Erlang VM;但有些时候--尤其是在测试和开发阶段，你需要在一台计算机上运行多个VM实例。按照目前启动erl(或werl)的方式运行起来的VM实例无从知晓也不关心其他实例的存在，因为它们之间并没有建立起网络连接。在单台计算机上运行多个基于Erlang的程序时（例如Yaws Web服务器和CouchDB数据库)，这个模式是适用的。启用了网络功能之后，Erlang VM跑起来会更有意思。我们管这样的VM实例叫作节点。
一旦两个或两个以上的Erlang节点能够想瓦感知，我们就说它们形成了一个集群。(Erlang/OTP的官方文档通常称之为节点网络，我们不打算采用这个叫法，以免与计算机网络相混淆。)默认情况下，Erlang集群是一个全联通网络，如图所示。换言之，集群中的每个节点都能够感知其他所有节点，任意两个节点都可以直接通信。
节点的启动
只要给erl(或werl)加上命令行参数-name或-sname，就可以以分布式模式启动Erlang节点。第一种形式适用于配有DNS的普通网络环境，你需要给出节点的完全限定域名（fullyqualified domain names )。例如:
erl -name simple_cache
第二种形式适用于完全限定域名不可用的情况;在某些生产环境下这种环境也是很常见的。还有的时候,举个例子,同处一个无线局域网内的两台计算机可以互联，但偏偏用DNS就走不通。碰到这些情况时，你就只能用短节点名了:
erl -sname simple_cache
只要所有节点同处一个子网，你就可以使用短节点名。
节点的互联
Erlang集群由两个或两个以上的节点组成。就数量而言，在同一集群内启动几十个节点没什么问题,但要跑上几百个的话就比较悬了。其原因在于维系机器之间的联络是需要一定的通信开销的,而Erlang集群又是一个全联通网络，这样一来这部分开销会随节点数的增加按平方规模增长。
一个节点不会主动搭理其他节点。你必须给它们一个呼朋唤友的理由;然而一旦探测到了别的点，它便会持续追踪它们并与之交换已经和自己建立了连接的其他节点的信息，从而促成全联通网络的形成。例如，假设节点A和z组成了一个集群，c和Dp组成了另一个集群，如果A和D相遇，它们就会互相交换B和c的信息，最终4个节点会共同形成一个更大的网络。
Erlang节点如何定位其他节点并与之建立通信
检查一下系统中运行着的进程，看看其中有没有一个叫做EPMD的进程。
EPMD代表Erlang端口映射守护进程(Erlang Port Mapper Daemon )。你每启动一个节点，它都会检查本地机器上是否运行着EPMD，如果没有，节点就会自行启动EPMD。EPMD会追踪在本地机器上运行的每个节点，并记录分配给它们的端口。当一台机器上的Erlang节点试图与某远程节点通信时，本地的EPMD就会联络远程机器上的EPMD（默认使用TCP/IP，端口为4369)，询问在远程机器上有没有叫相应名字的节点。如果有，远程的EPMD就会回复一个端口号，通过该端口便可直接与远程节点通信。不过EPMD不会自动搜寻其他EPMD—一只有在某个节点主动搜寻其他节点时通信才能建立。
请注意，Erlang默认的分布式模型基于这样一个假设，那就是集群中的所有节点都运行在一个受信网络内。如果这个假设不成立，或者其中的某些机器需要与外界通信，那么你就应该直接在TCP(或UDP、SCTP等)之上配合恰当的应用层协议来实现非受信网络上的通信。此外，你还可以利用SSL、SSH或IPsec等技术建立加密隧道，甚至直接将Erlang的分布式通信层架设在SSL等传输协议之上。
这篇关于分布式Erlang/OTP（学习笔记）（一）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
