中间件学习之RabbitMQ-1.认识消息队列MQ

思维导图链接

常见中间件学习笔记

参考尚硅谷RabbitMQ视频教程笔记
参考Java 面试突击第 1 季视频笔记

1.认识消息队列MQ 总览

1. 认识MQ 常见问题

题1：什么是消息队列

消息队列的定义

• MQ(message queue)，本质是个队列， FIFO 先入先出，存放的内容是message ，
• 还是一种跨进程的通信机制，用于上下游传递消息。
  • 在互联网架构中， MQ 是一种非常常见的上下游“逻辑解耦+物理解耦” 的消息通信服务。
  • 使用了 MQ 之后，消息发送上游只需要依赖 MQ，不用依赖其他服务

消息队列两种模式

1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）

• 消息生产者生产消息发送到Queue中， 然后消息消费者从Queue中取出并且消费消息。

• 消息被消费以后， queue 中不再有存储，所以消息消费者不可能消费到已经被消费的消息。

• Queue 支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

  

2）发布/订阅模式（一对多，消费者消费数据之后不会清除消息）

• 消息生产者（发布）将消息发布到 topic 中，

• 同时有多个消息消费者（订阅）消费该消息。

• 和点对点方式不同，发布到 topic 的消息会被所有订阅者消费。

  

题2：为什么要使用消息队列？

• 因为消息队列有 3 个核心场景：解耦，削峰，异步。

1.解耦：

1）要解决的的问题：

• 调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。
  • 但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给他异步化解耦，也是可以的，你就需要去考虑具体项目里，是不是可以运用这个 MQ 去进行系统的解耦。

2）MQ解耦提供的解决方案好处：

• 修改一个模块对其他模块影响很小。
• 通过使用消息队列，一个模块只需要向消息队列中发送消息，其它模块可以选择性地从消息队列中订阅消息从而完成调用。
  • 那么新增模块或者修改模块就对其他模块影响较小，这样系统的可扩展性无疑更好一些。
  • 利用消息队列实现事件驱动结构。
• 消息队列使利用发布-订阅模式工作，
  • 消息发送者（生产者）发布消息，一个或多个消息接受者（消费者）订阅消息。
  • 消息发送者（生产者）和消息接受者（消费者）之间没有直接耦合，
  • 消息发送者将消息发送至分布式消息队列即结束对消息的处理，
  • 消息接受者从分布式消息队列获取该消息后进行后续处理，并不需要知道该消息从何而来。
  • 对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计。

3）MQ解耦可能会出现的问题及解决建议：

• 为了避免消息队列服务器宕机造成消息丢失，
  • 会将成功发送到消息队列的消息存储在消息生产者服务器上，
  • 等消息真正被消费者服务器处理后才删除消息。
  • 在消息队列服务器宕机后，生产者服务器会选择分布式消息队列服务器集群中的其他服务器发布消息。

2.异步：

1）要解决的的问题：

• 用户的请求数据如果直接写入数据库再返回，在高并发的情况下数据库压力剧增，使得响应速度变慢。
• 例如A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系
  统写库，自己本地写库要 3ms， BCD 三个系统分别写库要 300ms、 450ms、 200ms。最终请求总延时
  是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了

2）MQ异步提供的解决方案好处：

• 异步将写入订单到数据库， 异步减库存。
  • 即主线程只负责将数据写入消息队列，然后就返回给前端，入库操作是异步进行
  • 并且发送消息到队列和减库存操作相比，前者速度更快，可以很快返回正在秒杀的结果给前台，给用户带来良好体验。
• 使用消息队列之后，
  • 用户的请求数据发送给消息队列之后立即 返回，
  • 再由消息队列的消费者进程从消息队列中获取数据， 异步写入数据库。
  • 由于消息队列服务器处理速度快于数据库（消息队列也比数据库有更好的伸缩性），因此响应速度得到大幅改善。

3.削峰：

1）要解决的的问题：

• 每天 0 点到 11 点， A 系统风平浪静，每秒并发请求数量就 100 个。结果每次一到 11 点~1 点，
  每秒并发请求数量突然会暴增到 1 万条。但是系统最大的处理能力就只能是每秒钟处理 1000 个请求
  啊。。。尴尬了，系统会死。

2）MQ削峰提供的解决方案好处

• 能够避免高并发情况下直接给 mysql 服务器带来巨大压力。
• 消息队列具有很好的削峰作用的功能——即通过异步处理，
  • 将短时间高并发产生的事务消息存储在消息队列中进行阻塞，从而削平高峰期的并发事务。
  • 等待阻塞比服务器崩溃要好
• 举例：在电子商务一些秒杀、促销活动中， 合理使用消息队列可以有效抵御促销活动刚开始大量订单涌入对系统的冲击

3）MQ削峰可能会出现的问题及解决建议：

• 数据同步问题：
  • 用户请求数据写入消息队列之后就立即返回给用户了，但是请求数据在后续的业务校验、写数
    据库等操作中可能失败。
  • 因此使用消息队列进行异步处理之后，需要适当修改业务流程进行配合，
  • 比如用户在提交订单之后，订单**数据写入消息队列，不能立即返回用户订单提交成功，需要在消息**
    队列的订单消费者进程真正处理完该订单之后，甚至出库后，再通过电子邮件或短信通知用户订单
    成功，以免交易纠纷。 这就类似我们平时手机订火车票和电影票。

题3：如何进行消息队列的技术选型？

1. 先解释为何使用消息队列

• 题2解答思路：因为消息队列有 3 个核心场景：解耦，削峰，异步。

2. 阐述消息队列有什么优点和缺点

• 优点上面已经说了，就是在特殊场景下有其对应的好处， 解耦、异步、削峰
• 缺点呢？显而易见的
  • 系统可用性降低：系统引入的外部依赖越多，越容易挂掉，本来你就是 A 系统调用 BCD 三个系统
    的接口就好了，ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来， 万一 MQ 挂了咋整？
    MQ 挂了，整套系统崩溃了，因此需要进行维护处理
  • 系统复杂性提高：硬生生加个 MQ 进来， 你怎么保证消息没有重复消费？怎么处理消息丢失的情况？
    怎么保证消息传递的顺序性，因此需要保证消息没有被重复消费、处理消息丢失的情况、保证消
    息传递的顺序性等等问题！
  • 一致性问题： A 系统处理完了直接返回成功了，人都以为你这个请求就成功了； 但是问题是，要是
    BCD 三个系统那里， BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致
    了。
    所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各
    种额外的技术方案和架构来规避掉，最好之后，你会发现，妈呀，系统复杂度提升了一个数量级，
    也许是复杂了 10 倍。但是关键时刻，用，还是得用的。。。

3.kafka、 ActiveMQ、 RabbitMQ、 RocketMQ 都有什么优点和缺点

4. MQ选取建议

• 1.ActiveMQ，一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以不推荐用这个了；
• 2.RocketMQ，天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。 RoketMQ 在稳定性上可能更值得信赖，这些业务场景在阿里双 11 已经经历了多次考验，如果业务有上述并发场景，建议可以选择 RocketMQ。
• 3.RabbitMQ ，结合 erlang 语言本身的并发优势，性能好时效性微秒级， 社区活跃度也比较高，管理界面用起来十分方便，如果数据量没有那么大，中小型公司优先选择功能比较完备的 RabbitMQ。
• 4.Kafka , 主要特点是基于Pull 的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集传输， 适合产生大量数据的互联网服务的数据收集业务。 如果有日志采集功能，肯定是首选 kafka 了
• 所以中小型公司，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择
• 如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高