消息队列选型和使用

1.消息队列的常用使用场景

解耦，异步，消峰

1.2 解耦

1.2.1耦合情况下的系统

当系统没有使用消息队列进行解耦时。

系统调用图

当A系统产生数据时候，需要调用这三个系统给他们发送数据。
[图片上传中...(image.png-7ae0ee-1667719710998-0)]

系统增加图

当过段时间E系统也需要A系统的数据，这样A系统就要修改代码继续调用E系统的数据，

image.png

• 当过段时间D系统又不需要A系统的数据，这样A系统有需要修改代码来，取消A系统的调用接口。
• 当A系统进行调用的时候，如果调用接口出现报错情况，还需要A系统进行各自的特殊处理。

1.3 解耦

解耦

通过A系统发送数据给MQ，B、C、D、系统通过自行订阅A中的数据进行响应的操作即可，A不需要关注它的消息是被谁消费的，也不需要去考虑那个系统出现消费错误的情况下的另一些操作，它只需要关心发送数据进入MQ即可。这里使用的消息队列的中Pub\Sub模式

2.异步

2.1 同步情况

image.png

当A系统同步调用B、C、D、系统进行处理的时候，A系统的总调用时长为下面B、C、D系统加起来的总的时长。

2.2 异步的情况

image.png

通过给三个队列中发送三条消息，之后直接返回，这样A接口的调用时长仅仅是A系统Sql执行时长，和插入三个队列消息的时长

3.消峰

3.1 项目未进行消峰操作的情况。

未进行消峰的操作

当一个时间端大量的请求涌入，当每秒的QPS到达了5000的峰值，每秒钟有5000个sql文件进行执行，这个时候会出现mysql宕机的情况，使服务器崩溃，当过了这个峰值后，就会回到正常情况。

3.2项目进行了消峰处理

消除峰值

当请求进来的时候直接全部进入mq中，让请求积压在mq中，再让A系统每秒获取他最大访问的请求进行处理，实现了消峰的操作。

2.使用mq后系统的缺点。

• 系统的可用性降低

  
  
  image.png

当系统中mq挂掉后，系统就会宕机，使得系统挂掉

• 系统的复杂性增加

image.png

1. mq出现故障，导致系统挂掉
2. mq发送了两条相同的数据，导致下面的系统消费后产生了两天一样的数据
3. mq消费的服务挂掉了，导致消息进行了积压，没有服务进行消费导致服务挂掉
   4.插入mq中的数据顺序出现了错误，导致数据顺序改变，从而使消费的系统数据出现错乱的情况。
   5.系统一致性问题，本事使系统A、系统B，系统C、都执行成功才能返回个成功，但是系统AB都执行成功了，而系统C执行失败了，导致给用户返回的是成功，而系统的后台逻辑发生错误的情况。

4.市面上的MQ对比

6.面试题分析

• 如何保证消息队列的高可用性

rabbitmq保证高可用性的情况

• rabbitmq的三种模式:1.单机、2.集群、3.镜像集群模式

• 单机模式

  
  

• 普通集群模式

  
  
  
  

  当启动了三台rabbitmq之后，当再中间的服务中创建了一个队列，当前的这个服务就会有rabbitmq的元数据和数据，而其他的服务只有他的元数据(当前队列的一些信息，包括队列在哪里放着);
  当一个消费之链接了右边的机器获取队列数据的时候，右边的机器就会与中间的机器进行通信，拉取中间queue中的数据返回给当前消费者
  缺点:如果中间的机器出现了宕机的情况，当前队列中的数据就会丢失。

镜像集群模式

镜像集群模式

当写入一个数据的时候，每个机器都会同步当前数据的元数据和数据进行存储。
当任何一个结点宕机了，其他的结点也会包含当前结点的其他完整信息，当其他结点宕机了，当前的消费者也会到其他的结点进行消费处理。
因为不是分布式的，当一个数据特别大，大到一个服务存储不下的时候，这时候因为要同步，其他的结点也会因为同步不下，造成不可用。

kafafa高可用性情况分析:

image.png

kafaka分布式情况解析:
1.对每个机器都有一个partition，当插入三条数据的时候，三条数据会插入到不同的partiion中，

高可用图

当每次写入的时候leader会把数据同步到follower上去
假设某一台机器出现了宕机，上面的leader就没有了，但此时follower还存在，此时kafka会自动感知的leader的死亡，会将其他的follower给选举出来作为leader。

• 如何保证消息不被重复消费呢(如何保证消息消费时的幂等性)?

  
  
  如何保证消息不被重复消费图

当消费者获取到数据153后，当消费已经完成，而未提交到kafka中，消费者就挂机了，当再一次链接后，kafka认为当前的当前数据153还为被消费，从而再次发送153的数据给消费者造成了数据二次消费的情况。

• 幂等性的解释

就是一个数据，或者一个请求，给你重复的来了多次，你得确保对应的数据不会改变的，不能出错

消息重复消费情况解决，对消费的数据进行存储，消费前先去查询当前的数据是否已经被消费过，如果消费过了就抛弃，如果没有消费过，再进行消费操作，从而解决幂等性的问题
还用一种解决方案:基于mysql中的唯一键处理，当数据插入的时候，也添加数据的id，当这条id已经存在的话插入就会报错。从而解决当前问题，重复的问题。
如何保证消费的幂等性，需要结合一些业务场景的情况进行处理。

• 如何保证消息的可靠性传输(如何处理丢失数据的情况)

出现数据丢失的场景:rabbitmq：

出现数据丢失的场景

生产者丢失数据情况

• 第一种方案实施

  
  
  image.png

• 第二种方案实施

  
  
  confirm模式

rabbitmq丢失数据情况方案:

image.png

消费者丢数据情况处理

image.png

image.png

4.kafka数据丢了情况分析

消费者丢失数据

4.1kafka自己把数据搞丢了的情况

kafka丢数据情况解析

4.2 kafka生产者出现丢数据情况分析

生产者出现丢数据情况分析

5.如何保证数据的顺序性?

情况图

rabbitmq出现当前顺序性不同情况:

rabbitmq顺序性

rabbitmq顺序性解决方案

image.png

kafka出现数据不一致问题处理

kafka顺序性问题

kafka顺序问题