微服务 消息中间件MQ
- 1. MQ的定义
- 2. MQ的作用
- 3. MQ的特点
- 4. MQ消费方式
- 5. 常用MQ对比分析
1. MQ的定义
MQ就是消息中间件。面向消息的中间件（message-oriented middleware）MOM能够很好的解决以上问题。是指利用高效可靠的消息传递机制与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。
通过提供消息传递和消息排队模型在分布式环境下提供应用解耦，弹性伸缩，冗余存储、流量削峰，异步通信，数据同步等功能。
大致的过程是这样的：发送者把消息发送给消息服务器，消息服务器将消息存放在若干队列/主题topic中，在合适的时候，消息服务器回将消息转发给接受者。
在这个过程中，发送和接收是异步的，也就是发送无需等待，而且发送者和接受者的生命周期也没有必然的关系；尤其在发布pub/订阅sub模式下，也可以完成一对多的通信，即让一个消息有多个接受者。
2. MQ的作用
使用消息中间件就是为了做这三件事，异步，解耦，削峰。
解耦：系统耦合度降低，没有强依赖关系。
异步：不需要同步执行的远程调用可以有效提高响应时间。
削峰：请求达到峰值后，后端service还可以保持固定消费速率消费，不会被压垮。
3. MQ的特点
1.采用异步处理模式
消息发送者可以发送一个消息而无须等待响应。消息发送者将消息发送到一条虚拟的通道（主题或者队列）上；
消息接收者则订阅或者监听该爱通道。一条消息可能最终转发给一个或者多个消息接收者，这些消息接收者都无需对消息发送者做出同步回应。整个过程都是异步的。
案例：
也就是说，一个系统跟另一个系统之间进行通信的时候，假如系统A希望发送一个消息给系统B，让他去处理。但是系统A不关注系统B到底怎么处理或者有没有处理好，所以系统A把消息发送给MQ，然后就不管这条消息的“死活了”，接着系统B从MQ里面消费出来处理即可。至于怎么处理，是否处理完毕，什么时候处理，都是系统B的事儿，与系统A无关。
2.应用系统之间解耦合
发送者和接受者不必了解对方，只需要确认消息。
发送者和接受者不必同时在线。
3.MQ的缺点
两个系统之间不能同步调用，不能实时回复，不能响应某个调用的回复。
4. MQ消费方式
MQ消费方式分为两种：push与pull模式。
push就是推送模式，就是服务端主动推送消息给客户端，这种方式及时性很高，但是可能会产生消费堆积或者资源浪费，因为服务端本身不知道消费者的消费能力，不能根据消费者的消费能力做控制管理。
pull就是拉取模式，需要客户端到服务端拉取数据，这种方式客户端可以根据自己消费能力进行消费，避免消息堆积或者资源浪费，但是客户端监听轮训机制会对服务端造成压力，消息及时性得不到保障。
MQ中间件 | push模式 | pull模式 |
rabbitMQ | 支持 | 支持 |
kafka | — | 支持 |
rocketMQ | 支持 | 支持 |
5. 常用MQ对比分析
目前国内常用MQ消息中间件有ActiveMQ、Kafka、RabbitMQ、RocketMQ。
kafka
1、开发语言： Scala开发
2、性能、吞吐量： 吞吐量所有MQ里最优秀，QPS十万级、性能毫秒级、支持集群部署
3、功能： 功能单一
4、缺点： 丢数据， 因为数据先写入磁盘缓冲区，未直接落盘。机器故障会造成数据丢失
5、应用场景： 适当丢失数据没有关系、吞吐量要求高、不需要太多的高级功能的场景，比如大数据场景。
Kafka自身服务与消息的生产和消费都依赖与Zookeeper，使用Scala语言开发。因为其消息的消费使用客户端Pull方式，消息可以被多个客户端消费，理论上消息会重复。因此比较常用的场景是作为日志传输的消息平台。
RabbitMQ
1、开发语言： Erlang开发
2、性能、吞吐量： 吞吐量比较低，QPS几万级、性能u秒级、主从架构
3、功能： 功能单一
4、缺点： Erlang小众语言开发，吞吐量低，集群扩展麻烦
5、应用场景： 中小公司对并发和吞吐量要求不高的场景。
总的来说，RabbitMQ在数据一致性、稳定性和可靠性方面比较优秀，而且直接或间接的支持多种协议，对多种语言支持良好。但是其性能和吞吐量差强人意，由于Erlang语言本身的限制，二次开发成本较高。
RocketMQ
1、开发语言： java开发
2、性能、吞吐量： 吞吐量高，QPS十万级、性能毫秒级、支持集群部署
3、功能： 支持各种高级功能，比如说延迟消息、事务消息、消息回溯、死信队列、消息积压等等
4、缺点： 官方文档相对简单可能是RocketMQ目前唯一的缺点
5、应用场景： 适当丢失数据没有关系、吞吐量要求高、不需要太多的高级功能的场景，比如大数据场景。
