Erlang进程之错?

前阵子erlang-china关于erlang该不该具有静态特性讨论的如火如荼，期间抛出了一个在erlang开发中迟早会遇到的问题：在一个拥有成千上万并发process的系统中，某些process具有举足轻重的位置，如其记录log信息，提供某个核心查询功能，这样的情况下，无数的进程访问一个进程，导致这个核心进程消息队列异常增大，相应速度下降，timeout接踵而来，最后导致系统当掉。

这样的情况，在其他语言的开发中也会遇到，只是在erlang的世界中，其似乎更加明显，更加值得“批评”。
因为erlang号称是适应“高并发，分布式，大规模系统”，这个小小的应用场景erlang就出了乱子，能不批评么？

Erlang虚拟机调度器中，追求的哲学是每个进程都有均等的拥有资源的能力。

让我们从虚拟机跳到现实社会中来。有一些老大，疯狂的掳夺占有资源，他们认为自己可以利用这些资源做出最有意义的事情。
这样下去可能会导致几个问题：
1）他们真的对了么？
2）小人物没有得到任何资源，难道就要饿死么？
3）老大挂掉了怎么办？资源还能有效的回收么？会不会很麻烦？
这个现实世界的问题，可以简单的映射到erlang的世界，需不需要有特权进程！
现实的世界证明，这个老大是靠不住的，众生皆追求平等自由，所以目标就是让每个人都有各种各样的权力。erlang也是如此。

我曾经跟帖说出三个解决方案：
1，将这个核心进程，复制几份，作为一个整体获取更多的执行机会，更多的io
2，提升进程的优先级别（process_flag(priority, max)），或者降低其他非关键进程的执行机会(yield)
3，将核心进程放入一个独立的node，让它自由的运转

采用了方案1 ，因为其简单，不需要伤筋动骨，不需要系统大的改动，只是封装出一个behaviour,根据scheduler的数目N，拷贝出N个进程，调用的时候，根据当前scheduler id选择对应的进程。
方案1的确是一个简陋的方案，但不是一个值得推崇的方案。

我们应该选择方案3，其符合架构上的拓展（功能分割），可以平滑的走向分布式。采用这种方法，web前端(erlang)的目的就是接受用户请求，可以同时处理上万的连接，这些进程是同类型的均等的。连接需要的处理操作，通过各种服务器节点(erlang)来处理。
这样我们的web server可以有1M个进程，而服务器节点可以只有100个进程，每个部分都充分利用机器性能，不会因为数量问题产生不快。

以后记住当某个进程“吃不消”的时候，首先考虑是你的架构上出问题了么？如果没有，那么就认真的分析分析各部分的处理能力，让最“累”的工作有更多的人分担。
随着系统不断进行，你也更加的熟悉你的系统，这添一砖那加一瓦，让他更好的提供服务。

Erlang进程真的没错，简单才是美.