最近项目可能需要用到rabbitmq作为中间件，负责消息转发
消息队列的理解：
异步去发送一些消息，这些消息都会存到一个队列里面，进行顺序处理，
但是对于客户来说，他并不需要等待这个处理过程，他可以去做其他的事情，等到消息队列里面处理到该客户的消息的时候，才会给客户返回相关的回应。
适用场景：
例如，某个网站的登录，需要验证码，当我们给网站服务器发送验证请求时，就会加入该网站的验证的消息队列里面，当然这个队列里面有很多客户的请求，队列会迅速进行处理，各个客户不需要一直在等待，我们可以做其他事情，等消息队列处理到我们的请求时，就会给我们返回手机短信验证码。
rabbitmq适合各种各样的队列处理，消息传送，不需要涉及具体的业务逻辑。
第一次了解rabbitmq是通过4399的游戏框架，市面上流通的游戏服务器底层框架大部分都是如下的组织方式：
（监控树机制+健壮的网络层框架）
简单来说就是一个TCP的广播服务器
看下官方的结构图
这个是网络某人blog的图
顶层是rabbit_sup supervisor，它至少有两个子进程，一个是rabbit_tcp_client_sup，用来监控每个connection的处理进程 rabbit_reader的supervisor;rabbit_tcp_listener_sup是监控tcp_listener和 tcp_acceptor_sup的supervisor，tcp_listener里
启动tcp服务器，监听端口，并且通过tcp_acceptor_sup启动N个tcp_accetpor，tcp_acceptor发起accept请求，等待客户端连接;tcp_acceptor_sup负责监控这些acceptor。这张图已经能给你一个大体的印象。
下面这个是我画的游戏服务器架构图(图忘了放哪，迟点补上)
XXXXXX
分析：
XXXXXX
每一次服务端接受一个新的连接时，都会创建一个rabbit_client_sup的子进程（simple_one_for_one），并依次构建各个子结点（上图中黄色区域）。并最终返回创建的rabbit_reader。
时序图：
1）tcp server的启动过程：
2）一个client连接上来的处理过程
小结：从上面的分析可以看出,rabbitmq的网络层是非常健壮和高效的，通过层层监控，对每个可能出现的风险点都做了考虑，并且利用了prim_net模块做异步IO处理。分层也是很清晰，将业务处理模块隔离到client_sup监控下的子进程，将网络处理细节和
业务逻辑分离。在协议的解析和业务处理上虽然没有采用gen_fsm，但是也实现了一套类似的状态机机制，通过动态替换Callback来模拟状态的变迁，非常巧妙。如果你要实现一个tcp server，强烈推荐从rabbitmq中扣出这个网络层，你只需要实现自己的业
务处理模块即可拥有一个高效、健壮、分层清晰的TCP服务器。
参考blog：
http://blog.chinaunix.net/uid-429659-id-3536524.html
http://jzhihui.iteye.com/blog/1544779