一、为什么Erlang天生适合分布式系统
Erlang的设计哲学就是"面向分布式而生"。它轻量级的进程模型、内置的跨节点通信机制，以及著名的"任其崩溃"（Let it crash）哲学，让它成为构建高容错分布式系统的绝佳选择。
举个简单的例子，假设我们有两个节点：node1@host1和node2@host2。在Erlang中建立它们之间的连接只需要一行代码：
% 在node1上执行
net_kernel:connect_node('node2@host2').
% 返回true表示连接成功
这种简洁性背后是Erlang运行时强大的分布式能力。每个Erlang节点都内置了EPMD（Erlang Port Mapper Daemon）服务，自动处理节点发现和端口映射。
二、跨节点通信的三大核心问题
1. 节点连接不稳定
在分布式环境中，网络抖动是常态。Erlang提供了自动重连机制，但需要合理配置心跳检测：
% 设置节点心跳参数
net_kernel:set_net_ticktime(60). % 60秒心跳间隔
2. 消息传递的不可靠性
虽然Erlang的!操作符提供了"尽力而为"的消息传递，但在跨节点场景下可能丢失消息。解决方案是加入确认机制：
% 发送方代码
send_with_ack(Pid, Msg) ->
Pid ! {self(), Msg},
receive
{ack, Ref} -> ok
after 5000 ->
{error, timeout}
end.
% 接收方代码
loop() ->
receive
{From, Msg} ->
% 处理消息...
From ! {ack, make_ref()},
loop()
end.
3. 进程定位难题
跨节点查找进程需要处理节点不可用的情况。global模块提供了解决方案：
% 注册全局进程
global:register_name(my_service, spawn(fun() -> service_loop() end)).
% 查找进程
case global:whereis_name(my_service) of
undefined ->
io:format("Service not found~n");
Pid ->
Pid ! {request, Data}
end.
三、实战中的进阶解决方案
1. 分布式进程监控
单纯使用link/1在跨节点场景不够可靠。我们需要分布式监控树：
% 启动监控进程
start_monitor() ->
spawn(fun() ->
process_flag(trap_exit, true),
{ok, Pid} = rpc:call('node2@host2', my_mod, start_service, []),
link(Pid),
monitor_loop(Pid)
end).
monitor_loop(Pid) ->
receive
{'EXIT', Pid, Reason} ->
io:format("Process ~p died: ~p~n", [Pid, Reason]),
start_monitor(); % 自动重启
_Other ->
monitor_loop(Pid)
end.
2. 分布式锁的实现
在集群中协调资源访问需要分布式锁。以下是基于Redis的RedLock算法实现：
% 获取分布式锁
acquire_lock(Resource, TTL) ->
case redis:q(["SET", Resource, "locked", "NX", "PX", TTL]) of
{ok, <<"OK">>} -> {ok, LockId};
_ -> {error, locked}
end.
% 释放锁
release_lock(Resource, LockId) ->
redis:q(["DEL", Resource]).
四、性能优化与陷阱规避
1. 消息序列化优化
跨节点消息会被序列化为Erlang二进制格式（ETF）。大消息要特别注意：
% 不好的做法：发送大term
big_data = lists:seq(1, 1000000),
remote_pid ! {data, big_data}.
% 优化方案：分批发送
send_large_data(Pid, Data) ->
[Pid ! {chunk, Chunk} || Chunk <- chunks(Data, 1000)].
2. 节点间RPC调用的超时设置
永远不要使用无限制的rpc调用：
% 危险的无超时调用
rpc:call(Node, Module, Function, Args).
% 安全的带超时调用
case rpc:call(Node, Module, Function, Args, 5000) of
{badrpc, Reason} ->
handle_error(Reason);
Result ->
process_result(Result)
end.
五、真实案例：电商库存系统设计
假设我们要实现一个跨地域的库存服务：
-module(inventory).
-export([reserve/2, commit/1, cancel/1]).
% 库存预留
reserve(ItemId, Qty) ->
case get_node_for_item(ItemId) of % 根据商品ID路由到对应节点
{ok, Node} ->
case rpc:call(Node, inventory_store, reserve, [ItemId, Qty]) of
{ok, Ref} -> {ok, Ref};
{error, _} = E -> E
end;
error -> {error, no_node}
end.
% 其他业务逻辑...
这个设计考虑了：
- 数据本地性（商品库存固定存储在特定节点）
- 操作幂等性（预留、提交、取消都可以重试）
- 故障转移（通过get_node_for_item/1实现动态路由）
六、总结与最佳实践
经过这些探索，我们得出以下经验：
- 网络分区一定会发生，设计时要考虑脑裂处理
- 消息传递至少一次，业务逻辑要幂等
- 监控不仅要关注进程状态，还要关注节点间延迟
- 分布式锁要设置合理的TTL，避免死锁
- 测试时要模拟各种网络故障场景
Erlang的分布式能力强大，但"能力越大责任越大"。合理运用这些模式，才能构建出真正可靠的分布式系统。
评论