算起来接触erlang 快四个月来，从零开始看书写erlang代码、修改RabbitMQ、业务开发、系统调优，总算是有点入门了。
最难受的是边学边修改RabbitMQ，难受只是暂时的，憋过去就海阔天空，最后提交修改2000+行代码。
说到坑都是自己技术不过关造成，erlang 设计与一般语言很大不同，虽然简单但还是有不少需要注意点；erlang 是一门非常成熟语言，OTP 也特别稳定，不过要想用好，很不容易。
列举遇到的注意点：
1. 学习资料少
书：《programing erlang》erlang 作者写的，通俗简单 嗯 真的很简单。。看一遍就够写得都差不多
官方文档： 不够详细？凑合看吧，好歹有
博客推荐：（建议有空将他们博客通读一遍，助你绕过前人走过的弯路）
http://www.cnblogs.com/zhengsyao/ （强推）
http://blog.yufeng.info/
http://www.cnblogs.com/me-sa/
http://wqtn22.iteye.com/
2. error_logger
这是个坑货， 而且默认crashlog 用这玩意儿记，一旦进程批量crash，因为内部receive-match 写磁盘方式，越来越慢。
可以选用lager，不过lager 在message_queue_len 超过指定值(50)后采用同步方式，内部依然是receive-match 写磁盘 方式写磁盘，
建议实现自己的lager_backend，通过cast 到独立 gen_server2 写磁盘，或者cast 到网络写到日志服务器上去
3. gen_server receive-match 问题
避免在热点gen_server 中使用receive-match 方式，或者都使用如rabbitmq 中的gen_server2，一定要防止在message_queue_len可能
比较大的进程中做recieve-match，error_logger就存在这个问题。
4. 热点进程
erlang 是公平调度，热点进程在负载稍高时，就会没机会得到处理，注意设置priority high
5. 单进程处理瓶颈
erlang 中因为进程无法共享数据，往往使用单个gen_server 完成共享逻辑，但erlang CPU计算是很低效的，往往但进程无法完成业务处理。
这个时候需要拆分到多个进程处理，如:server_1, server_2 .... 。
6. ETS
4、5 另一个解决方案是使用ETS，ETS 可以作为全局表，所有进程都可以读写，不存在热点进程，而且减少了进程消息交互成本，效率要高很多。
但是，ETS 是表结构，能够适合的场景很少，能用那就尽量多使用吧。
7. rpc:call
成本较大：一次调用有3次网络往返
服务端单进程：服务端有rex 进程处理，容易产生瓶颈，测试最多处理 10w/s 消息
如有必要尽量多使用 Pid ! Msg - receive 方式
8. gen_server:call timeout
timeout 是给call 方返还的，而实际处理一定会被处理，而且reply 也会在timeout 后发回message_queue，要注意。。
9. Pid ! Msg
Pid 不存在时，消息丢失， gen_cast 也一样；就算is_process_alive 判断也会存在竞态，所有是无法判断是否send sucess ，只能reply 确认
10. 依赖supervisor
erlang 设计模式，一般不怎么处理异常，非常态错误依赖supervisor 重启。 但如果gen_server 存在数据，重启瞬间 就会丢失数据。