[000-01-022].第01节：什么是MQ

我的后端学习大纲

RabbitMQ学习大纲

---

1.什么是MQ

• 1.MQ本质是个队列，遵循FIFO先入先出原则，在队列中存放的是message
• 2.MQ是跨进程的一种通信机制，用于上下游的消息传递。消息发送上游只需要依赖MQ，不需要依赖其他服务

---

2.MQ应用场景

2.1.流量消峰

• 1.流量消峰就是指的在流量高峰，当订单超过1万/s的时候，如果没有MQ来进行消息队列的缓冲，那么就会使得订单系统宕机，影响业务。所以使用MQ后，可以把1秒内的订单分散成一段时间来处理。这会使得用户在下单一段时间后才可以查到下单是否成功。
  
• 2.流量消峰在秒杀系统中应用有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况
  

---

2.2.应用解耦

a.举例1解释：

• 1.在系统中，如果用户创建订单后，还要调用库存系统，物流系统，支付系统，那么任何一个子系统出现了故障，都会造成系统异常。
• 2.当使用消息队列后：系统间调用的问题会减少很多，比如物流系统因为发生故障，需要几分钟来修复。在这几分钟的时间里，物流系统要处理的内存被缓存在消息队列中，用户的下单操作可以正常完成。
• 3.当物流系统恢复后，继续处理订单信息即可，其中用户感受不到物流系统的故障，提升系统的可用性。
  

b.举例2解释：

• 1.使用消息队列可以实现独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束，如下未未使用MQ时的情况：
  
• 2.使用MQ后的情况：
  

---

2.3.异步处理

a.举例1解释：

• 1.有的服务间调用是异步的，例如 A 调用 B，B 需要花费很长时间执行，但是 A 需要知道 B 什么时候可以执行完；
• 2.上述这种情况，在以前一般有两种方式，A 过一段时间去调用 B 的查询 api 查询。或者 A 提供一个 callback api， B 执行完之后调用 api 通知 A 服务。这两种方式都不是很优雅；
• 3.我们使用消息总线，可以很方便解决这个问题，A 调用 B 服务后，只需要监听 B 处理完成的消息，当 B 处理完成后，会发送一条消息给 MQ，MQ 会将此消息转发给 A 服务。这样 A 服务既不用循环调用 B 的查询 api，也不用提供callback api。同样 B 服务也不用做这些操作。A 服务还能及时的得到异步处理成功的消息。
  

b.举例2解释：

• 1.允许用户把一个消息放入队列，但并不立即处理它，然后在需要的时候再去处理它们
  

---

3.MQ的分类

3.1.RabbitMQ

a.简介

• 2007 年发布，是一个在 AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

b.优点:

• 1.由于 erlang 语言的高并发特性，性能较好；吞吐量到万级，MQ 功能比较完备,健壮、稳定、易用、跨平台、支持多种语言 如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，`支持 AJAX
• 2.文档齐全；
  • 开源提供的管理界面非常棒，用起来很好用,社区活跃度高；更新频率相当高

c.缺点：

• 商业版需要收费,学习成本较高

---

3.2.Kafka

a.简介 ：

• .Kafka是一个数据的杀手锏，在大数据领域内的消息传输，则绕不开 Kafka，是一款大数据而生的消息中间件，以其百万级 TPS 的吞吐量而出名，在数据采集、传输、存储的过程中有着重要作用。

b.优点:

• 性能卓越，单机写入 TPS 约在百万条/秒，最大的优点，就是`吞吐量高``
• 时效性 ms 级可用性非常高，kafka 是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用,消费者采用 Pull （推送）方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且`仅被消费一次；
• 有优秀的第三方Kafka Web 管理界面 Kafka-Manager；在日志领域成熟，被多家公司和多个开源项目使用；
• 功能支持：功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用；

c.缺点：

• Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高（一般指的CPU）现象，队列越多，load 越高，发送消息响应时间变长
• 使用短轮询方式，实时性取决于轮询间隔时间，消费失败不支持重试，可能会导致消息丢失；
• 支持消息顺序，但是一台代理宕机后，就会产生消息乱序，社区更新较慢；

---

3.3.ActiveMQ

a.优点：

- 1.单机吞吐量万级，时效性 ms 级，可用性高，`基于主从架构实现高可用性`，较低的概率丢失数据

b.缺点:

- 1.官方社区现在对 ActiveMQ 5.x 维护越来越少，`高吞吐量场景较少使用`。

---

3.4.RocketMQ

a.简介：

• RocketMQ 是阿里巴巴的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进。
• 被阿里巴巴广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog 分发等场景。

b.优点:

• 单机吞吐量十万级,可用性非常高，分布式架构,消息可以做到 0 丢失,MQ 功能较为完善，还是分布式的，扩展性好,支持 10 亿级别的消息堆积，不会因为堆积导致性能下降,源码是 java 我们可以自己阅读源码，定制自己公司的 MQ

c.缺点：

• 支持的客户端语言不多，目前是 java 及 c++，其中 c++不成熟；
• 社区活跃度一般,没有在 MQ核心中去实现 JMS 等接口,有些系统要迁移需要修改大量代码。

---

4.MQ的选择

4.1.Kafka

• Kafka 主要特点是基于 Pull 的模式来处理消息消费，追求高吞吐量，
• Kafka 一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。
• 大型公司建议可以选用，如果有日志采集功能，肯定是首选 kafka 了。

4.2.RocketMQ

• 1.天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。RoketMQ
• 2.在稳定性上可能更值得信赖，这些场景在阿里双 11 已经经历了多次考验，所以当业务上有并发场景，可以选择使RocketMQ。

4.3.RabbitMQ

• 结合 Erlang 语言本身的并发优势，性能好时效性微秒级，社区活跃度也比较高，管理界面用起来十分方便，如果你的数据量没有那么大，中小型公司优先选择功能比较完备的

---

2.2.消息队列的两种模式

a.点对点模式：

• 1.消费者主动拉取数据，消息收到后清除消息
• 2.一个生产者对应一个消费者、一个topic、 会删除数据
  

b2.发布订阅模式：

• 1.可以有多个topic主题（浏览、点赞、收藏、评论等）
• 2.消费者消费数据之后，不删除数据
• 3.每个消费者相互独立，都可以消费到数据
• 4.多个生产者 、多个消费者、消费者相互独立 、多个topic、不会删除数据
  

---