rabbitmq消息队列连环炮

rabbitmq消息队列连环炮 消息队列 使用消息队列的优缺点?

好处:

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

坏处:

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

Kafka、ActiveMq、RabbitMq、RocketMq区别? 特性ActiveMQRabbitMQRocketMQKafka单机吞吐量万级，比 RocketMQ、Kafka 低一个数量级同 ActiveMQ10 万级，支撑高吞吐10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景topic 数量对吞吐量的影响topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topictopic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，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 都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。