好想问，为什么 ruby 的社区要建 erlang 的节点？在这里待着的人，有真正从事 erlang 工作的呢，还是工作做 ruby，只是喜欢 erlang，想学学这个 coolcool 的东西？ 我最开始是个 ruby 程序员，后来自学的 erlang，现在找到了个 erlang 的工作在做（IM 方面）。 我很奇怪国内连个 erlang 的根据地都没有，大家交流也是在几个 erlang 大牛的博客中留言而已，以前也有 erlang 的社区网站不过不知道为什么早早就不维护了。 说起来国内的 erlang 大牛肯定是有很多啊，不过愿意出来写博客分享的有两个：淘宝的褚霸还有网名叫坚强 2002 的一个哥们。 基本上他们会分享出自己工作中遇到过的一些问题和解决办法，还有 erlang 的细节和虚拟机内部机制。尤其是后两点，对于了解 erlang 太重要了，因为如果这些东西不知道的话，你很难写出高并发的程序，你会发现，怎么我的代码这么好的服务器就几十万的并发就 cpu90% 了？内存也快满了。。erlang 也没比 java 牛逼多少啊！！！ 唉，真真让我怎么说这些同学呢，其实根源是有些东西不是随便写写就 OK 的。 做 erlang 和以前做 ruby 最大的不同在于，做 ruby 的时候我写代码，写完做测试开个 irb 或者 rails c 验证一下代码确实能运行并得到我想要的结果，这意味着我这次的工作完成了，git add commit merge push。over。 做 erlang 的时候呢？每个功能我做之前就要想好多方案，这些方案都能实现这个功能，然后我要做测试，测试有 2 种，1 种要保证这个方案确实能得出我要的结果，第 2 种就是做性能测试，确保哪个方案是性能最优的。然后才实际编写功能，最后大家一起审查我的代码，没问题了才上传，还要在测试服务器上做压力测试等等，才会上线。 例如我们做消息回执的时候，给客户端发消息，消息会存缓存，等收到客户端的回执的时候，删除缓存，一定时间没收到回执，则存离线。 有 3 种方式存缓存，1.mnesia write。2.mnesia dirty_write. 3.ets. 最终我们选择了 ets。因为首先 mnesia write 的时候是走事物的，他要保证所有节点之间数据同步之后才算执行完成，无形当中产生了瓶颈。mnesia dirty_write 效率很高，但是由于这个回执不需要跨节点，所以也没采用，最后我们用了 ets，读写速度非常快。基本能满足我们的需求。 看到这有些同学可能要说，3 个方案能差多少呢，有时候单进程差距很小，结果在大并发下差距会非常大，当时做测试的数据我忘了，不过在十几万的并发下 mnesia write 的消息全部堆积在了接收其他节点的同步回执上。效率慢的根本无法忍受。 在整个系统过百万的并发下，多小的性能差异都会放大到很难想想的地步。就拿最简单的消息分发来说，我做过测试，一个进程负责接收消息，然后公平的分派给其他的 worker 进程，逻辑不复杂，但是如果这个分发进程用 gen_server 在 10 万的并发下会出现消息堆积的情况，也就是说超出了他的处理能力，只会越来越慢。如果直接 receive 则撑 10W 的并发不成问题。所以很多地方需要放 gen_server 就放弃吧。连 mnesia 的接收同步请求的进程也是直接 receive 的（mnesia_tm）。 扯着扯着就扯远了。希望 erlang 能有大牛带着大家成立个社区，像 ruby 社区这样活跃。 这是我在某个下午干完工作，产生的无聊的思绪，不知道为什么就写到这了。：）