RocketMQ
MQ
MQ（Message Queue）是一种跨进程的通信机制，用于传递消息。通俗的说，就是一个先进先出的数据结构。
应用场景一：异步解耦
异步解耦是消息队列的主要特点，主要目的是减少相应时间和解耦。主要的使用场景就是将比较耗时而且不需要即时（同步）返回结果的操作作为消息放入消息队列。同时，由于使用了消息队列MQ，只要保证消息格式不变，消息的发送方和接收方不需要彼此联系，也不需要对方的影响，即解耦合。
应用场景二：流量削峰
流量削峰也是消息队列的常用场景，一般在秒杀或团队抢购（高并发）活动中使用广泛。在秒杀或团队抢购活动中，由于用户请求量较大，导致流量暴增，秒杀的应用在处理如此大量的访问流量后，下游的通知系统无法承载海量的调用量，设置导致系统崩溃等发生漏通知的情况。为了解决这些问题，可在应用和下游通知系统之间加入消息队列。
常见MQ产品
ZeroMQ
号称最快的消息队列系统，尤其针对大吞吐量的需求场景，扩展性好，开发比较灵活，采用C语言实现，实际上只是一个socket库的重新封装，如果作为消息队列使用，需要开发大量的代码。ZeroMQ仅提供非持久性的队列，如果down机数据将永久丢失。
RabbitMQ
使用erlang语言开发，性能较好，适合与企业级的开发，但是不利于做二次开发和维护。
ActiveMQ
历史悠久的Apache项目，已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，支持持久化到数据库，对队列书较多的情况支持不好。
RocketMQ
阿里巴巴的MQ中间件，由java语言开发，性能非常好，能够撑住双十一的大流量，而且使用起来很简单。
Kafka
Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。
RocketMQ
RocketMQ整体可以分成4个角色，NameServer、Broker、Producer、Consumer。
Broker（投递员）
是RocketMQ的核心，负责消息的接受、存储、投递功能。
NameServer（邮局）
是消息队列的协调者，Broker向他注册路由信息，同时Consumer和Producer向其获取路由信息。
Producer（寄件人）
消息的生产者，需要从NameServer获取Broker信息，然后与Broker建立连接，项Broker发送消息。
Consumer（收件人）
消息的消费者，需要从NameServer获取Broker信息，然后与Broker建立连接，从Broker接受消息。
Topic（地区）
用来区分不同类型的消息，发送和接受消息前都需要先创建Topic，针对Topic来发送和接受消息。
MessageQueue
为了提高性能和吞吐量，引入了Message Queue，一个Topic可以设置一个或者多个Message Queue，这样消息就可以并行往各个Message Queue发送消息，消费者也可以并行的从多个Message Queue读取消息。
RocketMQ消息类型
可靠同步发送
同步消息发送是指消息发送方发出数据后，会在收到接收方发回响应之后才发下一个数据包的通讯方式，此种方式应用场景非常广泛，例如重要邮件通知，报名短信通知，营销短信系统等。
可靠异步发送
异步发送是指发送方发出数据后，不等接收方发回响应，接着发送下一个数据包的通讯方式，发送方通过回调接口接受服务器的响应，并对响应结果进行处理。异步发送一般用于链路耗时较长，对RT响应时间较为敏感的业务场景，例如用户视频上传后通知系统转码服务，转码完成后通知推送转码结果等。
单向发送
单向发送是指发送方只负责发送消息，不等待服务器回应且没有回调函数触发，即只发送请求不等待应答。适用于某些耗时非常短，但对可靠性要求并不高的场景，例如日志收集。
RocketMQ事务消息
RocketMQ提供了事务消息，通过事务消息就能达到分布式事务的最终一致性。
半事务消息
暂不能投递的消息，发送方已经成功的将消息发送到了RocketMQ服务端，但是服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半事务消息。
消息回查
由于网络闪断、生产者应用重启等原因，导致某事务消息的二次确认丢失，RocketMQ服务端通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（Commit或是Rollback），该询问过程即消息回查。