消息队列的学习 （一）

消息队列的学习 （一）

MQ有哪些？如何选型？

常见的：RabbitMQ，ActiveMQ，Kafka，RocketMQ

RabbitMQ 中小型公司，erlang语言天生具备高并发，开源易维护;

RocketMQ 大公司，依赖于阿里，可能需要专人定制化开发；

Kafka 大公司，若需要日志采集功能，首选kafka；

1、MQ常用的使用场景

异步：

场景说明：用户注册后，需要发送注册邮件和注册短信流程：

处理模式：引入中间件MQ，将消息写入消息队列，非必要的业务逻辑（注册邮件和注册短信）异步方式运行，加速响应速度（用户注册成功即可给用户响应）

解耦:

场景说明：分布式系统中的订单系统和库存系统，用户下单后，需要调用库存系统接口来通知库存系统，若库存系统故障，则下单失败；

处理模式：引入消息队列，用户下单后，订单系统完成持久化处理，将消息写入消息队列，用户端返回下单成功，库存系统想消息队列订阅下单的消息，获取并进行库存操作；

流量削峰：

场景说明：电商系统秒杀，并发量大，所有的请求都堆积到数据库，造成数据库异常

处理模式：在应用前端加入消息队列，将用户请求写入消息队列，若加入消息队列长度超过最大值则直接抛弃用户请求或跳转错误页面（人太多了，请稍后重试）------业务系统慢慢的按照数据库能处理的并发量，从消息队列中拉取消息处理；

2、 使用消息队列会有什么缺点？

系统可用性降低-----若消息队列挂了，系统不可用；

系统复杂性增加-----消息一致性、如何保证消息不被重复消费，如何保证消息可靠传输

3、 如何保证消息队列高可用？

消息队列的集群模式

4、 如何保证消息不被重复消费？

正常情况下，消费者在消费消息时候，消息完毕后，会发送一个确认信息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除；

若网络传输等故障，确认消息美哟u传送到消息队列，导致队列不知道自己已经消费过该消息了，再次将该消息分发给其他的消费者；

如何解决？这个问题针对业务场景来答分一下几点

1)、比如，你拿到这个消息做数据库的insert操作

那就容易了，给这个消息做一个唯一主键，那么就算出现重复消费的情况，就会导致主键冲突，比卖你数据库出现脏数据。

2)、再比如，你拿到这个消息做redis的set操作

那就容易了，不用解决。因为你无论set几次结果都是一样的，set操作本来就算幂等操作。

3)、如果上面两种情况还不行

准备一个第三方介质，来做消费记录，以redis为例，给消息分配一个全局id，只要消费过该消息，将以Key-Value形式写入redis。那消费这开始消费前，先去redis中查询有没有消费记录即可。

5、如何保证消息可靠传输？

分生产者丢数据，消费队列丢数据，消费者丢数据

生产者丢数据：RabbitMQ提供transaction（发送异常回滚）和confirm模式来确保生产者不丢消息，缺点是影响吞吐量；

消费队列丢数据：开启持久化磁盘配置，消息持久化完成后，在给生产者发送确认信号，若生产者收不到确认信号，会自动重发；

dubbo分布式系统，如果一个接口调用失败了，通常是什么原因：

• 1. 服务提供者未启动服务
  2. 服务提供者未对该调用系统开放接口
  3. 服务消费者未注册进dubb控制中心
  4. 提供者服务本身的端口，被linux防火墙闲着远程访问了
  5. 服务消费者，调错版本服务了

  消息发送出去，丢失了或失败了咋办，其它系统接收失败怎么办？

  MQ有消息重发机制，每条消息发送会有MQ表记录(会记录失败原因)，状态如果是发送失败后会重发，超过一定次数才会停止，如果自动重发也失败，还可以通过手动触发调度。还可以通过监控平台看生产者和消费者的消费次数来看接收和发送情况。

  并且主数据提供了消息反馈的接口，其他系统接收失败的话会调用接口返回失败原因。通过原因去定位问题。

如何测试MQ的性能？

准备100w数据，关闭消费者，注入到MQ，在控制台上查看时间；

然后关闭生产者，打开消费者，开始消费数据，在控制台上查看时间；

单线程，为开启消息持久化和消费者ack

100w数据，100M，tps 8k/s

参考文章：
https://blog.youkuaiyun.com/whoamiyang/article/details/54954780
https://mp.weixin.qq.com/s/4SvYWm48DbNdF_ugGbd8EA