rabbitmq消息队列连环炮

消息队列

使用消息队列的优缺点?

好处:

1. 通过异步处理提高系统性能
2. 削峰/限流
3. 降低系统耦合性

坏处:

1. 系统可用性降低
2. 系统复杂度提高
3. 一致性问题

Kafka、ActiveMq、RabbitMq、RocketMq区别?

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，比 RocketMQ、Kafka 低一个数量级	同 ActiveMQ	10 万级，支撑高吞吐	10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响			topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic	topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
时效性	ms 级	微秒级，这是 RabbitMQ 的一大特点，延迟最低	ms 级	延迟在 ms 级以内
可用性	高，基于主从架构实现高可用	同 ActiveMQ	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据	基本不丢	经过参数优化配置，可以做到 0 丢失	同 RocketMQ
功能支持	MQ 领域的功能极其完备	基于 erlang 开发，并发能力很强，性能极好，延时很低	MQ 功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用

rabbitmq如何保证消息队列的高可用?

rabbitmq是基于主从做高可用的,有三种模式: 单机模式、普通镜像模式、镜像集群模式

单机模式

​ 单机模式就是demo级别的,没人生产环境用单机模式。

普通集群模式

普通集群模式,意思就是在多台机器上启动多个实例。你创建的queue,只会放在一个rabbitmq实例上,但是每个实例都会同步queue的元数据(元数据可以认为是queue的一些配置信息,通过元数据可以找到queue的所在实例)。你消费的时候,实际上如果连接到另外一台实例,那么那个实例会从queue所在实例上拉取数据过来。

这种模式如果存放 queue 的实例宕机了,会导致接下来其他实例无法从那个实例拉取

镜像集群模式

这种模式才是所谓的高可用模式。跟普通集群模式不一样的是,在镜像集群模式下,你创建的queue无论是元数据还是消息都会存放于多个实例中。每次写消息到queue的时候,都会把消息自动同步到各个实例中

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

让每个消息携带一个全局的唯一ID，即可保证消息的幂等性，具体消费过程为：

1. 消费者获取到消息后先根据id去查询redis/db是否存在该消息。
2. 如果不存在，则正常消费，消费完毕后写入redis/db。
3. 如果存在，则证明消息被消费过，直接丢弃。

rabbitmq如何保证消息的可靠性传输

rabbitmq如何解决消息队列的延时失效、积压

这个问题的场景: 比如你消费端出了问题,不消费了(可能数据库宕机了);或者消费的速度极慢。可能消息队列的磁盘都快满了都没人消费。大量数据mq里积压了几个小时

大量消息在mq里积压了几个小时解决方法:

看堆积的消息是否还要使用,如果不使用直接删除即可,要使用如下

方案1️⃣简单修复

修复consumer的问题,让他恢复消费速度,然后等待几个小时消费完毕。

方案2️⃣复杂修复

1）先修复consumer的问题，确保其恢复消费速度，然后将现有consumer都停掉
2）新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量
3）然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue
4）接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据
5）这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据
6）等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息

mq中的消息过期失效了解决方法:

假设你用的是 RabbitMQ是可以设置过期时间的，也就是 TTL。如果消息在 queue 中积压超过一定的时间就会被 RabbitMQ 给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在 mq 里，而是大量的数据会直接搞丢。

这个情况下，就不是说要增加 consumer 消费积压的消息，因为实际上没啥积压，而是丢了大量的消息。我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上 12 点以后，用户都睡觉了。这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入 mq 里面去，把白天丢的数据给他补回来。也只能是这样了。

mq快写满了

如果消息积压在 mq 里，你很长时间都没有处理掉，此时导致 mq 都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。