MQ全称为Message Queue,是应用之间进行消息通信的一种方式，RocketMQ是阿里的开源框架，我们经常在面试中提到的有kafka，ActiveMQ，RabbitMQ一般面试中会让你给个对比，今天我们简单对比一下 然后说下我对rocketMQ的理解。
(1)中小型软件公司，建议选RabbitMQ.一方面，erlang语言天生具备高并发的特性，而且他的管理界面用起来十分方便。正所谓，成也萧何，败也萧何！他的弊端也在这里，虽然RabbitMQ是开源的，然而国内有几个能定制化开发erlang的程序员呢？所幸，RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug，这点对于中小型公司来说十分重要。不考虑rocketmq和kafka的原因是，一方面中小型软件公司不如互联网公司，数据量没那么大，选消息中间件，应首选功能比较完备的，所以kafka排除。不考虑rocketmq的原因是，rocketmq是阿里出品，如果阿里放弃维护rocketmq，中小型公司一般抽不出人来进行rocketmq的定制化开发，因此不推荐。
(2)大型软件公司，根据具体使用在rocketMq和kafka之间二选一。一方面，大型软件公司，具备足够的资金搭建分布式环境，也具备足够大的数据量。针对rocketMQ,大型软件公司也可以抽出人手对rocketMQ进行定制化开发，毕竟国内有能力改JAVA源码的人，还是相当多的。至于kafka，根据业务场景选择，如果有日志采集功能，肯定是首选kafka了。具体该选哪个，看使用场景。
我们公司当时算是一个中型的p2p公司了，选用的rocketmq,选rocketmq也是有原因的。
1，rocketmq支持事物（常见的转账的例子），这在金融系统中很重要
2，rocketmq，支持消息重发，定时发送能功能，以及消费次数的限制
3，rocketmq，consumer支持消息过滤，减小了不必要的网络传输，通过tag标识过滤消息机制
4，rocketmq，支持消息的重复消费
综上所述我们选择了rocketmq.
rocketmq的架构图方便我们理解挣个rocketmq的运行过程
这个图形刚开始看，如果了解kafka的话，会认为是kafka的副本，只是namerserver这块kafka用的是zookper,也就是namerserver相当于一个注册中心。选择nameserver是轻量级的，并且每个namaserver相互独立，一个宕机不影响可以切换到其他的nameserver上。
nameserver:
1，nameserver为producer和consumer提供topic 路由信息
2，nameserver定时去检测boker 的心跳，10s一次，超过两分钟发现某个master或slave链接不再活跃就关闭链接。
3，接受broker启动的时候注册的路由信息。
producer:
1,producer消息的生产者，发送消息的时候首先从本地获取boker上的topic路由信息，如果，本地没有路由信息则去nameserver查询获取topic的路由信息
2，producer与nameserver建立长链接，没隔30s查询topic路由信息，并对本地路由信息进行更新
3，producer与boker建立长链接，每隔30s向boker发送心跳，group信息会被定时发送到boker的maseter上，通过主从复制，将信息复制到slave上。
consumer:
1,consumer消息的消费者，向nameserver注册
2,consumer定时获取topic的路由信息，每个30s查询一次，与nameser建立长链接
3,consumer与boker建立长链接，每隔30发送心跳给boker.
boker:
Broker是RocketMQ的核心，大部分工作都在Broker中完成，包括接收请求，处理消费，消费持久，消息的HA，以及服务端过滤等都在里面完成.
1,与nameser建立长链接，每隔30s向nameser发送心跳，也就是一个master服务宕机以后顶多三十秒，消息丢失，部分信息没有复制到slave上的可能将不被消费在这30s内，不过消息不会丢失，当服务重启的时候又会被消费
在我们选择rocketmq上我们，我们关心其处理消息的顺序性和事物机制
我们下篇文章了解下rocketmq如何处理消息按照顺序，以及如何保证事物的。
