一、为什么需要容量规划？
想象一下你开了一家网红奶茶店。开业第一天就排起了长队，但你只准备了两台收银机和三个员工。结果顾客等得不耐烦都走了，这就是典型的容量规划失败。在Erlang系统中，道理是一样的。
Erlang作为电信级语言，天生擅长处理高并发。但再好的系统，如果不提前规划容量，遇到业务暴增时照样会挂。比如一个即时通讯系统，平时在线1万人很稳定，突然因为某个热点事件用户量翻了10倍，这时候如果没做好准备，系统就会像春运时的火车站一样崩溃。
二、容量规划的核心指标
做容量规划就像给人体检，需要关注几个关键指标：
首先是并发进程数。Erlang的轻量级进程很强大，但也不是无限的。比如：
%% 测试系统最大进程数
max_processes() ->
{ok, Max} = erlang:system_info(process_limit),
io:format("系统最大进程数限制: ~p~n", [Max]).
%% 典型值一般是262144，但实际可用数要留出安全余量
其次是内存使用。Erlang的垃圾回收是按进程来的，内存监控很重要：
%% 查看进程内存
check_memory() ->
Mem = erlang:memory(),
Total = proplists:get_value(total, Mem),
io:format("当前内存使用: ~p MB~n", [Total/1024/1024]).
最后是消息队列长度。消息积压是Erlang系统常见的瓶颈：
%% 检查消息队列
check_msgq(Pid) ->
{message_queue_len, Len} = erlang:process_info(Pid, message_queue_len),
case Len > 1000 of
true -> io:format("警告:进程~p消息积压~p条~n", [Pid, Len]);
false -> ok
end.
三、预测业务增长的实用方法
预测未来就像天气预报，虽然不可能100%准确，但有方法可以提高命中率。
历史数据法是最靠谱的。假设我们有个在线游戏服务器：
%% 分析历史在线人数
analyze_users() ->
% 假设从数据库读取过去30天的数据
Data = db:query("SELECT hour, avg(users) FROM stats GROUP BY hour"),
% 找出峰值时段
Peak = lists:max([Users || {_, Users} <- Data]),
io:format("历史峰值: ~p 用户/小时~n", [Peak]).
事件预测法也很实用。比如准备双十一：
%% 根据营销活动预测流量
predict_traffic(Event) ->
case Event of
double11 -> normal_traffic() * 10;
new_year -> normal_traffic() * 5;
_ -> normal_traffic()
end.
四、应对增长的技术方案
当预测到业务要增长，我们可以从几个层面做准备。
垂直扩展是最简单的：
%% 动态调整进程池大小
resize_pool(Pool, NewSize) ->
pool:set_max_workers(Pool, NewSize),
io:format("~p 进程池已调整为~p workers~n", [Pool, NewSize]).
%% 注意：要配合内存监控使用
水平扩展更推荐：
%% 动态增加节点
add_node(Node) ->
net_adm:ping(Node),
case lists:member(Node, nodes()) of
true -> io:format("节点 ~p 已加入集群~n", [Node]);
false -> io:format("连接节点 ~p 失败~n", [Node])
end.
流量控制也很重要：
%% 实现简单的限流
rate_limit(Service, MaxRPS) ->
receive
{request, From, Msg} ->
case counter:incr(Service) > MaxRPS of
true -> From ! {error, too_many_requests};
false -> handle_request(Msg)
end
end.
五、真实案例：电商秒杀系统
去年我们帮一个电商平台做秒杀系统，峰值预计是平时的50倍。
首先我们做了压力测试：
%% 模拟用户请求
simulate_users(N) ->
[spawn(fun() ->
timer:sleep(rand:uniform(1000)),
request_item()
end) || _ <- lists:seq(1, N)].
%% 发现当N>50000时响应时间明显上升
然后设计了分级处理方案：
%% 分级处理请求
handle_seckill(Request) ->
case Request of
{pre_order, _} -> handle_in_pre_order_pool(Request);
{pay, _} -> handle_in_payment_pool(Request);
_ -> handle_in_default_pool(Request)
end.
%% 不同业务使用不同资源池
最终系统平稳度过了流量洪峰，期间最高并发达到12万。
六、常见陷阱与解决方案
在容量规划的路上，我们踩过不少坑。
内存泄漏是最隐蔽的：
%% 有问题的代码
leaky_process() ->
receive
{store, Data} ->
leaky_process(Data)
end.
%% 正确的写法应该定期清理
safe_process() ->
receive
{store, Data} ->
clean_old_data(),
safe_process(Data)
after 5000 ->
clean_old_data(),
safe_process()
end.
进程阻塞也很危险：
%% 同步调用可能阻塞
dangerous_call() ->
some_server ! {request, self()},
receive
Reply -> Reply
end.
%% 改进为带超时
safe_call() ->
some_server ! {request, self()},
receive
Reply -> Reply
after 1000 ->
{error, timeout}
end.
七、监控与自动伸缩
好的容量规划不是一劳永逸的，需要持续监控。
我们开发了一个智能调控系统：
%% 自动伸缩逻辑
auto_scale() ->
case overload_detected() of
true ->
add_node(new_node()),
auto_scale();
false ->
case idle_detected() of
true ->
remove_node(),
auto_scale();
false ->
timer:sleep(5000),
auto_scale()
end
end.
%% 每5秒检查一次系统负载
配合报警机制：
%% 阈值报警
check_alarms() ->
[begin
case get_metric(M) > threshold(M) of
true -> alert_sms(M);
false -> ok
end
end || M <- [cpu, memory, processes]].
八、总结与最佳实践
经过多个项目的锤炼，我们总结了几个黄金法则：
- 容量规划要趁早，别等系统挂了才想起
- 监控比预测更重要，实时数据最可靠
- 水平扩展优于垂直扩展
- 留足缓冲空间，建议至少30%
- 定期做压力测试，就像消防演习
最后记住，Erlang虽然强大，但也不是银弹。合理的架构设计加上科学的容量规划，才能打造真正坚如磐石的系统。
评论