一、背景
随着移动互联网的迅猛发展，各大互联网公司的体量、业务呈现指数式增长，在业务的反哺与逼迫下，分布式技术架构随之遍地开花，其中以SOA服务技术架构，微服务技术架构等为主的分布式架构如火如荼地发展。在这种大趋势之下，互联网企业也开始面临着数据采集，数据异构，系统整合等诸多问题，而CORBA、DCOM、RMI等RPC中间件技术也应运而生，但由于采用RPC同步处理技术，在性能、健壮性、可扩展性上都存在着诸多缺点，消息队列以异步处理，非阻塞调用的技术模型悄然登场，并迅速成为分布式架构的宠儿。
二、主流消息队列比较
以下表格摘取自apache rocketmq官方文档
阿里云消息队列上有另外一份对比：https://help.aliyun.com/document_detail/52577.html?spm=a2c4g.11186623.6.540.WVgch7
为何选择RocketMQ
- 消息不丢失【重点】
- 强大的技术团队，健壮的社区力量
- 采用Java编写实现，技术体系上更符合团队抉择
- 架构主轻量，组件无状态，可独立部署
- 高可用性，高吞吐量，性能好
- 经历多年阿里巴巴双十一挑战，不管是从业务复杂度，还是高流量并发都扛下来了，故而实践上毋庸置疑
三、简而言之RocketMQ架构
RocketMQ架构分为四个模块
1、生产者
2、消费者
3、namesrv
4、broker
3.1、namesrv
namesrv 是由阿里云RocketMQ中间件开发团队开发的基于服务注册发现功能的无状态组件，支持独立部署。namesrv在整个RocketMQ架构体系中，属于重中之重的组件，乃灵魂级组件，统筹全局，可谓之'一家之主'。上可撩得生产者靓妹，下可驾驭消费者御姐，亦可跟broker徐娘亲近。
那么它又是如何工作的呢？
1、生产者从namesrv中获取可用的broker地址，将消息发送至broker。
2、消费者从namesrv中获取可用的broker地址，从broker中拉去消息。
3、broker定时向naemsrv发送心跳信息，维护可用broker地址。
3.2、broker
broker是由阿里云RocketMQ中间件开发团队开发的基于高性能和低延迟的文件存储的无状态组件，支持独立部署。broker在整个RocketMQ架构体系中，同样是不可或缺的组件，乃核心级组件，可谓之‘持家之女’。负责存储所有的消息相关文件（包括消息文件，日志文件等等）。
3.3、生产者，消费者
生产者，消费者是我们再实际编码过程中直接接触到的，也是RocketMQ直接暴露给编码人员的API接口。生产者是勤勤恳恳的小码农，消费者是奢侈的败家女。
四、集群
4.1、namesrv 集群部署
RocketMQ如何做集群部署来提供系统的吞吐量，以及高可用性？从整体的架构上便可一眼看出，服务注册与发现组件namesrv可以独立部署，且namesrv与namesrv之间并无直接或间接的关联，双方不存在心跳检测，所以namesrv的之间不存在主备切换过程，如果其中一台namesrv宕机后，生产者消费者会直接从另一台namesrv中请求数据。但也正因为namesrv之间不存在心跳检测，主备切换，所以无法支持动态扩容，当机器宕机需要重新部署基于新的ip地址的namesrv需要更新生产者/消费者直连的namesrv地址。