精华内容
下载资源
问答
  • mq面试题 千次阅读
    2018-12-14 10:31:29

    作者:SoLucky2017
    来源:CSDN
    原文:https://blog.csdn.net/ssllkkyyaa/article/details/84023586

    目录

    为什么使用消息队列

    MQ缺点

    MQ横向对比

    高可用

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

    丢数据

     rabbitmq丢数据

    kafka丢消息

    保证消息顺序

    消息积压

    kafka积压

    activeMQ积压

    1 概述

    2 消息队列通信图

    3 问题定位与分析

    3.1 消息通知数据为什么会被积压?

    3.2 配置了多个ActiveMQ的消费者为什么数据积压还是无法缓解?

    3.3 去掉synchronized同步锁会产生多线程并发的安全性问题吗?

    3.4 消息会被重复多次消费吗?

    4 阶段一优化方案

    4.1 准备测试数据

    4.2 优化前性能测试

    4.3 优化后性能测试

    4.3.1 取消同步锁

    4.3.2 取消同步锁后的性能测试

    4.3.3 优化ActiveMQ的queuePrefetch 参数

    4.3.4 优化queuePrefetch参数后的性能测试

    4.3.5 结论

    5 阶段二优化方案

    5.1 单队列处理

    5.2 双队列处理

    6 阶段三优化方案

    6.1 MQ组件重选型

    7 总结

     

     

    使用MQ场景之一

    比如我们有个订单系统,订单系统会每次下一个新的订单的时候,就会发送时一条消息到ActiveMQ里面去,后台有个库存系统负责获取了消息然后更新库存。
    为什么使用消息队列

    解耦、异步、削峰

    解耦:现场画个图来说明一下,A系统发送个数据到BCD三个系统,接口调用发送,那如果E系统也要这个数据呢?那如果C系统现在不需要了呢?现在A系统又要发送第二种数据了呢?A系统负责人濒临崩溃中。。。再来点更加崩溃的事儿,A系统要时时刻刻考虑BCDE四个系统如果挂了咋办?我要不要重发?我要不要把消息存起来?头发都白了啊。。。

    面试技巧:你需要去考虑一下你负责的系统中是否有类似的场景,就是一个系统或者一个模块,调用了多个系统或者模块,互相之间的调用很复杂,维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的,如果用MQ给他异步化解耦,也是可以的,你就需要去考虑在你的项目里,是不是可以运用这个MQ去进行系统的解耦。在简历中体现出来这块东西,用MQ作解耦。

    异步:现场画个图来说明一下,A系统接收一个请求,需要在自己本地写库,还需要在BCD三个系统写库,自己本地写库要3ms,BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3 + 300 + 450 + 200 = 953ms,接近1s,用户感觉搞个什么东西,慢死了慢死了。

    同步高延时:

    解耦后性能优化

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

     

    应对高峰

     
    MQ缺点

    系统可用性降低:系统引入的外部依赖越多,越容易挂掉,本来你就是A系统调用BCD三个系统的接口就好了,人ABCD四个系统好好的,没啥问题,你偏加个MQ进来,万一MQ挂了咋整?MQ挂了,整套系统崩溃了,你不就完了么。

     

    系统复杂性提高:硬生生加个MQ进来,你怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺序性?头大头大,问题一大堆,痛苦不已

     

    一致性问题:A系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是BCD三个系统那里,BD两个系统写库成功了,结果C系统写库失败了,咋整?你这数据就不一致了。

     

    所以消息队列实际是一种非常复杂的架构,你引入它有很多好处,但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉,最好之后,你会发现,妈呀,系统复杂度提升了一个数量级,也许是复杂了10倍。但是关键时刻,用,还是得用的。。。

     

     

     
    MQ横向对比

    特性
        

    ActiveMQ
        

    RabbitMQ
        

    RocketMQ
        

    Kafka

    单机吞吐量
        

    万级,吞吐量比RocketMQ和Kafka要低了一个数量级
        

    万级,吞吐量比RocketMQ和Kafka要低了一个数量级
        

    10万级,RocketMQ也是可以支撑高吞吐的一种MQ
        

    10万级别,这是kafka最大的优点,就是吞吐量高。

     

    一般配合大数据类的系统来进行实时数据计算、日志采集等场景

    topic数量对吞吐量的影响
        

     
        

     
        

    topic可以达到几百,几千个的级别,吞吐量会有较小幅度的下降

     

    这是RocketMQ的一大优势,在同等机器下,可以支撑大量的topic
        

    topic从几十个到几百个的时候,吞吐量会大幅度下降

     

    所以在同等机器下,kafka尽量保证topic数量不要过多。如果要支撑大规模topic,需要增加更多的机器资源

    时效性
        

    ms级
        

    微秒级,这是rabbitmq的一大特点,延迟是最低的
        

    ms级
        

    延迟在ms级以内

    可用性
        

    高,基于主从架构实现高可用性
        

    高,基于主从架构实现高可用性
        

    非常高,分布式架构
        

    非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用

    消息可靠性
        

    有较低的概率丢失数据
        

     
        

    经过参数优化配置,可以做到0丢失
        

    经过参数优化配置,消息可以做到0丢失

    功能支持
        

    MQ领域的功能极其完备
        

    基于erlang开发,所以并发能力很强,性能极其好,延时很低
        

    MQ功能较为完善,还是分布式的,扩展性好
        

    功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用,是事实上的标准

    优劣势总结
        

    非常成熟,功能强大,在业内大量的公司以及项目中都有应用

     

    偶尔会有较低概率丢失消息

     

    而且现在社区以及国内应用都越来越少,官方社区现在对ActiveMQ 5.x维护越来越少,几个月才发布一个版本

     

    而且确实主要是基于解耦和异步来用的,较少在大规模吞吐的场景中使用

     
        

    erlang语言开发,性能极其好,延时很低;

     

    吞吐量到万级,MQ功能比较完备

     

    而且开源提供的管理界面非常棒,用起来很好用

     

    社区相对比较活跃,几乎每个月都发布几个版本分

     

    在国内一些互联网公司近几年用rabbitmq也比较多一些

     

    但是问题也是显而易见的,RabbitMQ确实吞吐量会低一些,这是因为他做的实现机制比较重。

     

    而且erlang开发,国内有几个公司有实力做erlang源码级别的研究和定制?如果说你没这个实力的话,确实偶尔会有一些问题,你很难去看懂源码,你公司对这个东西的掌控很弱,基本职能依赖于开源社区的快速维护和修复bug。

     

    而且rabbitmq集群动态扩展会很麻烦,不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码,很难定制和掌控。
        

    接口简单易用,而且毕竟在阿里大规模应用过,有阿里品牌保障

     

    日处理消息上百亿之多,可以做到大规模吞吐,性能也非常好,分布式扩展也很方便,社区维护还可以,可靠性和可用性都是ok的,还可以支撑大规模的topic数量,支持复杂MQ业务场景

     

    而且一个很大的优势在于,阿里出品都是java系的,我们可以自己阅读源码,定制自己公司的MQ,可以掌控

     

    社区活跃度相对较为一般,不过也还可以,文档相对来说简单一些,然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码

     

    还有就是阿里出台的技术,你得做好这个技术万一被抛弃,社区黄掉的风险,那如果你们公司有技术实力我觉得用RocketMQ挺好的
        

    kafka的特点其实很明显,就是仅仅提供较少的核心功能,但是提供超高的吞吐量,ms级的延迟,极高的可用性以及可靠性,而且分布式可以任意扩展

     

    同时kafka最好是支撑较少的topic数量即可,保证其超高吞吐量

     

    而且kafka唯一的一点劣势是有可能消息重复消费,那么对数据准确性会造成极其轻微的影响,在大数据领域中以及日志采集中,这点轻微影响可以忽略

     

    这个特性天然适合大数据实时计算以及日志收集

     
    高可用

    (1)RabbitMQ的高可用性

     

    RabbitMQ是比较有代表性的,因为是基于主从做高可用性的,我们就以他为例子讲解第一种MQ的高可用性怎么实现。

     

    rabbitmq有三种模式:单机模式,普通集群模式,镜像集群模式

     

    1)单机模式

     

    就是demo级别的,一般就是你本地启动了玩玩儿的,没人生产用单机模式

     

    2)普通集群模式

     

    意思就是在多台机器上启动多个rabbitmq实例,每个机器启动一个。但是你创建的queue,只会放在一个rabbtimq实例上,但是每个实例都同步queue的元数据。完了你消费的时候,实际上如果连接到了另外一个实例,那么那个实例会从queue所在实例上拉取数据过来。

     

    这种方式确实很麻烦,也不怎么好,没做到所谓的分布式,就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据,要么固定连接那个queue所在实例消费数据,前者有数据拉取的开销,后者导致单实例性能瓶颈。

     

    而且如果那个放queue的实例宕机了,会导致接下来其他实例就无法从那个实例拉取,如果你开启了消息持久化,让rabbitmq落地存储消息的话,消息不一定会丢,得等这个实例恢复了,然后才可以继续从这个queue拉取数据。

     

    所以这个事儿就比较尴尬了,这就没有什么所谓的高可用性可言了,这方案主要是提高吞吐量的,就是说让集群中多个节点来服务某个queue的读写操作。

     

    3)镜像集群模式

     

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

    这样的话,好处在于,你任何一个机器宕机了,没事儿,别的机器都可以用。坏处在于,第一,这个性能开销也太大了吧,消息同步所有机器,导致网络带宽压力和消耗很重!第二,这么玩儿,就没有扩展性可言了,如果某个queue负载很重,你加机器,新增的机器也包含了这个queue的所有数据,并没有办法线性扩展你的queue

     

    那么怎么开启这个镜像集群模式呢?我这里简单说一下,避免面试人家问你你不知道,其实很简单rabbitmq有很好的管理控制台,就是在后台新增一个策略,这个策略是镜像集群模式的策略,指定的时候可以要求数据同步到所有节点的,也可以要求就同步到指定数量的节点,然后你再次创建queue的时候,应用这个策略,就会自动将数据同步到其他的节点上去了。

     

    (2)kafka的高可用性

     

    kafka一个最基本的架构认识:多个broker组成,每个broker是一个节点;你创建一个topic,这个topic可以划分为多个partition,每个partition可以存在于不同的broker上,每个partition就放一部分数据。

     

    这就是天然的分布式消息队列,就是说一个topic的数据,是分散放在多个机器上的,每个机器就放一部分数据。

     

    实际上rabbitmq之类的,并不是分布式消息队列,他就是传统的消息队列,只不过提供了一些集群、HA的机制而已,因为无论怎么玩儿,rabbitmq一个queue的数据都是放在一个节点里的,镜像集群下,也是每个节点都放这个queue的完整数据。

     

    kafka 0.8以前,是没有HA机制的,就是任何一个broker宕机了,那个broker上的partition就废了,没法写也没法读,没有什么高可用性可言。

     

    kafka 0.8以后,提供了HA机制,就是replica副本机制。每个partition的数据都会同步到吉他机器上,形成自己的多个replica副本。然后所有replica会选举一个leader出来,那么生产和消费都跟这个leader打交道,然后其他replica就是follower。写的时候,leader会负责把数据同步到所有follower上去,读的时候就直接读leader上数据即可。只能读写leader?很简单,要是你可以随意读写每个follower,那么就要care数据一致性的问题,系统复杂度太高,很容易出问题。kafka会均匀的将一个partition的所有replica分布在不同的机器上,这样才可以提高容错性。

     

    这么搞,就有所谓的高可用性了,因为如果某个broker宕机了,没事儿,那个broker上面的partition在其他机器上都有副本的,如果这上面有某个partition的leader,那么此时会重新选举一个新的leader出来,大家继续读写那个新的leader即可。这就有所谓的高可用性了。

     

    写数据的时候,生产者就写leader,然后leader将数据落地写本地磁盘,接着其他follower自己主动从leader来pull数据。一旦所有follower同步好数据了,就会发送ack给leader,leader收到所有follower的ack之后,就会返回写成功的消息给生产者。(当然,这只是其中一种模式,还可以适当调整这个行为)

     

    消费的时候,只会从leader去读,但是只有一个消息已经被所有follower都同步成功返回ack的时候,这个消息才会被消费者读到。

     

    实际上这块机制,讲深了,是可以非常之深入的,但是我还是回到我们这个课程的主题和定位,聚焦面试,至少你听到这里大致明白了kafka是如何保证高可用机制的了,对吧?不至于一无所知,现场还能给面试官画画图。要遇上面试官确实是kafka高手,深挖了问,那你只能说不好意思,太深入的你没研究过。

     

    但是大家一定要明白,这个事情是要权衡的,你现在是要快速突击常见面试题体系,而不是要深入学习kafka,要深入学习kafka,你是没那么多时间的。你只能确保,你之前也许压根儿不知道这块,但是现在你知道了,面试被问到,你大概可以说一说。然后很多其他的候选人,也许还不如你,没看过这个,被问到了压根儿答不出来,相比之下,你还能说点出来,大概就是这个意思了。

     

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

    kafka实际上有个offset的概念,就是每个消息写进去,都有一个offset,代表他的序号,然后consumer消费了数据之后,每隔一段时间,会把自己消费过的消息的offset提交一下,代表我已经消费过了,下次我要是重启啥的,你就让我继续从上次消费到的offset来继续消费吧。

     

    但是凡事总有意外,比如我们之前生产经常遇到的,就是你有时候重启系统,看你怎么重启了,如果碰到点着急的,直接kill进程了,再重启。这会导致consumer有些消息处理了,但是没来得及提交offset,尴尬了。重启之后,少数消息会再次消费一次。

     

    其实重复消费不可怕,可怕的是你没考虑到重复消费之后,怎么保证幂等性。

     

    给你举个例子吧。假设你有个系统,消费一条往数据库里插入一条,要是你一个消息重复两次,你不就插入了两条,这数据不就错了?但是你要是消费到第二次的时候,自己判断一下已经消费过了,直接扔了,不就保留了一条数据?

     

    一条数据重复出现两次,数据库里就只有一条数据,这就保证了系统的幂等性

     

    幂等性,我通俗点说,就一个数据,或者一个请求,给你重复来多次,你得确保对应的数据是不会改变的,不能出错。

     

    那所以第二个问题来了,怎么保证消息队列消费的幂等性?

     

    其实还是得结合业务来思考,我这里给几个思路:

     

    (1)比如你拿个数据要写库,你先根据主键查一下,如果这数据都有了,你就别插入了,update一下好吧

     

    (2)比如你是写redis,那没问题了,反正每次都是set,天然幂等性

     

    (3)比如你不是上面两个场景,那做的稍微复杂一点,你需要让生产者发送每条数据的时候,里面加一个全局唯一的id,类似订单id之类的东西,然后你这里消费到了之后,先根据这个id去比如redis里查一下,之前消费过吗?如果没有消费过,你就处理,然后这个id写redis。如果消费过了,那你就别处理了,保证别重复处理相同的消息即可。

     

    还有比如基于数据库的唯一键来保证重复数据不会重复插入多条,我们之前线上系统就有这个问题,就是拿到数据的时候,每次重启可能会有重复,因为kafka消费者还没来得及提交offset,重复数据拿到了以后我们插入的时候,因为有唯一键约束了,所以重复数据只会插入报错,不会导致数据库中出现脏数据

     

    如何保证MQ的消费是幂等性的,需要结合具体的业务来看
    丢数据

    rabbitmq这种mq,一般来说都是承载公司的核心业务的,数据是绝对不能弄丢的

     

         rabbitmq丢数据

     

    1)生产者弄丢了数据

     

    生产者将数据发送到rabbitmq的时候,可能数据就在半路给搞丢了,因为网络啥的问题,都有可能。

     

    此时可以选择用rabbitmq提供的事务功能,就是生产者发送数据之前开启rabbitmq事务(channel.txSelect),然后发送消息,如果消息没有成功被rabbitmq接收到,那么生产者会收到异常报错,此时就可以回滚事务(channel.txRollback),然后重试发送消息;如果收到了消息,那么可以提交事务(channel.txCommit)。但是问题是,rabbitmq事务机制一搞,基本上吞吐量会下来,因为太耗性能。

     

    所以一般来说,如果你要确保说写rabbitmq的消息别丢,可以开启confirm模式,在生产者那里设置开启confirm模式之后,你每次写的消息都会分配一个唯一的id,然后如果写入了rabbitmq中,rabbitmq会给你回传一个ack消息,告诉你说这个消息ok了。如果rabbitmq没能处理这个消息,会回调你一个nack接口,告诉你这个消息接收失败,你可以重试。而且你可以结合这个机制自己在内存里维护每个消息id的状态,如果超过一定时间还没接收到这个消息的回调,那么你可以重发。

     

    事务机制和cnofirm机制最大的不同在于,事务机制是同步的,你提交一个事务之后会阻塞在那儿,但是confirm机制是异步的,你发送个消息之后就可以发送下一个消息,然后那个消息rabbitmq接收了之后会异步回调你一个接口通知你这个消息接收到了。

     

    所以一般在生产者这块避免数据丢失,都是用confirm机制的。

     

    2)rabbitmq弄丢了数据

     

    就是rabbitmq自己弄丢了数据,这个你必须开启rabbitmq的持久化,就是消息写入之后会持久化到磁盘,哪怕是rabbitmq自己挂了,恢复之后会自动读取之前存储的数据,一般数据不会丢。除非极其罕见的是,rabbitmq还没持久化,自己就挂了,可能导致少量数据会丢失的,但是这个概率较小。

     

    设置持久化有两个步骤,第一个是创建queue的时候将其设置为持久化的,这样就可以保证rabbitmq持久化queue的元数据,但是不会持久化queue里的数据;第二个是发送消息的时候将消息的deliveryMode设置为2,就是将消息设置为持久化的,此时rabbitmq就会将消息持久化到磁盘上去。必须要同时设置这两个持久化才行,rabbitmq哪怕是挂了,再次重启,也会从磁盘上重启恢复queue,恢复这个queue里的数据。

     

    而且持久化可以跟生产者那边的confirm机制配合起来,只有消息被持久化到磁盘之后,才会通知生产者ack了,所以哪怕是在持久化到磁盘之前,rabbitmq挂了,数据丢了,生产者收不到ack,你也是可以自己重发的。

     

    哪怕是你给rabbitmq开启了持久化机制,也有一种可能,就是这个消息写到了rabbitmq中,但是还没来得及持久化到磁盘上,结果不巧,此时rabbitmq挂了,就会导致内存里的一点点数据会丢失。

     

    3)消费端弄丢了数据

     

    rabbitmq如果丢失了数据,主要是因为你消费的时候,刚消费到,还没处理,结果进程挂了,比如重启了,那么就尴尬了,rabbitmq认为你都消费了,这数据就丢了。

     

    这个时候得用rabbitmq提供的ack机制,简单来说,就是你关闭rabbitmq自动ack,可以通过一个api来调用就行,然后每次你自己代码里确保处理完的时候,再程序里ack一把。这样的话,如果你还没处理完,不就没有ack?那rabbitmq就认为你还没处理完,这个时候rabbitmq会把这个消费分配给别的consumer去处理,消息是不会丢的。

     

     

        kafka丢消息

     

    1)消费端弄丢了数据

     

    唯一可能导致消费者弄丢数据的情况,就是说,你那个消费到了这个消息,然后消费者那边自动提交了offset,让kafka以为你已经消费好了这个消息,其实你刚准备处理这个消息,你还没处理,你自己就挂了,此时这条消息就丢咯。

     

    这不是一样么,大家都知道kafka会自动提交offset,那么只要关闭自动提交offset,在处理完之后自己手动提交offset,就可以保证数据不会丢。但是此时确实还是会重复消费,比如你刚处理完,还没提交offset,结果自己挂了,此时肯定会重复消费一次,自己保证幂等性就好了。

     

    生产环境碰到的一个问题,就是说我们的kafka消费者消费到了数据之后是写到一个内存的queue里先缓冲一下,结果有的时候,你刚把消息写入内存queue,然后消费者会自动提交offset。

     

    然后此时我们重启了系统,就会导致内存queue里还没来得及处理的数据就丢失了

     

    2)kafka弄丢了数据

     

    这块比较常见的一个场景,就是kafka某个broker宕机,然后重新选举partiton的leader时。大家想想,要是此时其他的follower刚好还有些数据没有同步,结果此时leader挂了,然后选举某个follower成leader之后,他不就少了一些数据?这就丢了一些数据啊。

     

    生产环境也遇到过,我们也是,之前kafka的leader机器宕机了,将follower切换为leader之后,就会发现说这个数据就丢了

     

    所以此时一般是要求起码设置如下4个参数:

     

    给这个topic设置replication.factor参数:这个值必须大于1,要求每个partition必须有至少2个副本

     

    在kafka服务端设置min.insync.replicas参数:这个值必须大于1,这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系,没掉队,这样才能确保leader挂了还有一个follower吧

     

    在producer端设置acks=all:这个是要求每条数据,必须是写入所有replica之后,才能认为是写成功了

     

    在producer端设置retries=MAX(很大很大很大的一个值,无限次重试的意思):这个是要求一旦写入失败,就无限重试,卡在这里了

     

    我们生产环境就是按照上述要求配置的,这样配置之后,至少在kafka broker端就可以保证在leader所在broker发生故障,进行leader切换时,数据不会丢失

     

    3)生产者会不会弄丢数据

     

    如果按照上述的思路设置了ack=all,一定不会丢,要求是,你的leader接收到消息,所有的follower都同步到了消息之后,才认为本次写成功了。如果没满足这个条件,生产者会自动不断的重试,重试无限次。

    保证消息顺序

    我举个例子,我们以前做过一个mysql binlog同步的系统,压力还是非常大的,日同步数据要达到上亿。mysql -> mysql,常见的一点在于说大数据team,就需要同步一个mysql库过来,对公司的业务系统的数据做各种复杂的操作。

    你在mysql里增删改一条数据,对应出来了增删改3条binlog,接着这三条binlog发送到MQ里面,到消费出来依次执行,起码得保证人家是按照顺序来的吧?不然本来是:增加、修改、删除;你楞是换了顺序给执行成删除、修改、增加,不全错了么。

     

    本来这个数据同步过来,应该最后这个数据被删除了;结果你搞错了这个顺序,最后这个数据保留下来了,数据同步就出错了。

     

    先看看顺序会错乱的俩场景

     

    (1)rabbitmq:一个queue,多个consumer,这不明显乱了

    (2)kafka:一个topic,一个partition,一个consumer,内部多线程,这不也明显乱了

     

    那如何保证消息的顺序性呢?简单简单

    (1)rabbitmq:拆分多个queue,每个queue一个consumer,就是多一些queue而已,确实是麻烦点;或者就一个queue但是对应一个consumer,然后这个consumer内部用内存队列做排队,然后分发给底层不同的worker来处理

    (2)kafka:一个topic,一个partition,一个consumer,内部单线程消费,写N个内存queue,然后N个线程分别消费一个内存queue即可

     

    消息积压
    kafka积压

    一个消费者一秒是1000条,一秒3个消费者是3000条,一分钟是18万条,1000多万条

     

    所以如果你积压了几百万到上千万的数据,即使消费者恢复了,也需要大概1小时的时间才能恢复过来

     

    一般这个时候,只能操作临时紧急扩容了,具体操作步骤和思路如下:

     

    1)先修复consumer的问题,确保其恢复消费速度,然后将现有cnosumer都停掉

    2)新建一个topic,partition是原来的10倍,临时建立好原先10倍或者20倍的queue数量

    3)然后写一个临时的分发数据的consumer程序,这个程序部署上去消费积压的数据,消费之后不做耗时的处理,直接均匀轮询写入临时建立好的10倍数量的queue

    4)接着临时征用10倍的机器来部署consumer,每一批consumer消费一个临时queue的数据

    5)这种做法相当于是临时将queue资源和consumer资源扩大10倍,以正常的10倍速度来消费数据

    6)等快速消费完积压数据之后,得恢复原先部署架构,重新用原先的consumer机器来消费消息

     

    (2)这里我们假设再来第二个坑

     

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

     

    这个情况下,就不是说要增加consumer消费积压的消息,因为实际上没啥积压,而是丢了大量的消息。我们可以采取一个方案,就是批量重导,这个我们之前线上也有类似的场景干过。就是大量积压的时候,我们当时就直接丢弃数据了,然后等过了高峰期以后,比如大家一起喝咖啡熬夜到晚上12点以后,用户都睡觉了。

     

    这个时候我们就开始写程序,将丢失的那批数据,写个临时程序,一点一点的查出来,然后重新灌入mq里面去,把白天丢的数据给他补回来。也只能是这样了。

     

    假设1万个订单积压在mq里面,没有处理,其中1000个订单都丢了,你只能手动写程序把那1000个订单给查出来,手动发到mq里去再补一次

     

    (3)然后我们再来假设第三个坑

     

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

    另外,参见:https://www.jianshu.com/p/4e00dff97f39  消息积压

     

     
    activeMQ积压
    1 概述

    最近生产环境的消息通知队列发生了大量的数据积压问题,从而影响到整个平台商户的交易无法正常进行,最后只能通过临时关闭交易量较大的商户来缓解消息队列积压的问题,经线上数据分析,我们的消息队列在面对交易突发洪峰的情况下无法快速的消费并处理队列中的数据,考虑到后续还会出现各种交易量突发状况,以下为针对消息队列(ActiveMQ)的优化过程。

     
    2 消息队列通信图

    images/ZDmZJZFzGazb7tMxMS3FQG7Yhx56EEWZ.png
    3 问题定位与分析

     
    3.1 消息通知数据为什么会被积压?

    分析:平台中每个交易的发生可能会产生一到多条的消息通知数据,这些通知数据会通过消息队列(ActiveMQ)来中转消费并处理,那么在交易量突发洪峰的情况下会产生大量的消息通知数据,如果消息队列(ActiveMQ)的消费能力被阻塞的话会严重影响到数据的吞吐量,从而积压大量数据无法被快速处理!

     
    3.2 配置了多个ActiveMQ的消费者为什么数据积压还是无法缓解?

    分析:经过分析消息队列的数据消费处理模块的代码,消息的消费处理是通过监听器SessionAwareMessageListener异步回调onMessage方法而接收消息的,但是在回调的方法onMessage上加了synchronized同步锁,问题就在这里,由于整个onMessage方法被锁,导致程序只能通过串行(一次只能消费一条数据)处理数据,而无法通过多线程并发处理数据,从而影响了整个队列的数据消费能力。

    public synchronized void onMessage(Message message, Session session)

    3.3 去掉synchronized同步锁会产生多线程并发的安全性问题吗?

    分析:首先多个消费者并发处理的数据是不同的,而且多个消费者线程并发回调onMessage方法的时候并未使用到共享的变量,全部在各自线程的方法栈中,所以理论上不会出现多线程并发产生的安全性问题。

     
    3.4 消息会被重复多次消费吗?

    分析:

    (1)通过分析ActiveMQ的消费者消息接收处理的源代码发现,一条消息是否已经消费是通过ack确认机制来保证的,如果是通过异步回调的方式接收消息的话,在onMessage回调函数返回之后会立即进行ack确认提交,那么只要保证onMessage函数内部不抛出异常,及需要内部捕获异常,那么消息就不会被重复消息。

    (2)因为我们的系统在接收到消息后会首先存入db中进行持久化,而且每条消息在存入数据库的时候都做了唯一性约束,那么即使有重复的消息也不会被正常处理。

     
    4 阶段一优化方案

     
    4.1 准备测试数据

    启动多个线程分别往MQ消息队列中发送数据,共发送15000个消息,然后启动消费者模块消费消息,设定每个消息处理耗时为10ms,配置ActiveMQ的消费者数量为concurrency = 5-100

     
    4.2 优化前性能测试
     测试次数       是否并发处理        消息数量     

    queuePrefetch
        consumers     耗时
         1              否         15000             1000             15     151s
         2              否         15000             1000             16     151s
         3              否         15000             1000             15     151s

    优化前通过测试数据发现,虽然配置了concurrency = 5-100 (消费者动态伸缩),但是只有15个消费者在忙碌,而且消息都是串行化执行的,15000条消息共需要151s的时间,效率非常差,ps:哈哈,不知道是哪位开发的大神加的同步锁!

    注:queuePrefetch 为MQ的消费者一次从Queue中拉取的数量,默认为1000,consumers为处理消息的消费者数量

     
    4.3 优化后性能测试

     
    4.3.1 取消同步锁

    取消在监听器的回调方法onMessage上的synchronized同步锁

     
    4.3.2 取消同步锁后的性能测试
     测试次数       是否并发处理        消息数量     

    queuePrefetch
        consumers     耗时
         1              是         15000             1000             14      13s
         2              是         15000             1000             15      13s
         3              是         15000             1000             15      13s

    通过以上数据发现取消同步锁,15000条消息只需要13s就可以处理完,相比之前快了近12倍,虽然速度提升了不少,但是发现配置了5-100的消费者,确只有15个消费者在忙碌,其他消费者都没有消息可处理,及造成了数据倾斜,那么接下来就要通过优化queuePrefetch 参数了。

     
    4.3.3 优化ActiveMQ的queuePrefetch 参数

    预获取消息数量是MQ中重要的调优参数之一,为了提高网络的传输效率,ActiveMQ默认给Consumer批量push 1000条消息,可以从ActiveMQ源码中的ActiveMQPrefetchPolicy类的DEFAULT_QUEUE_PREFETCH字段得知,考虑到我们的通知消息的消费处理中涉及到数据库的操作,以及综合网络传输效率,这里将queuePrefetch的值设置为100,具体需配置到ActiveMQ的连接地址后,如:

    tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=100

    4.3.4 优化queuePrefetch参数后的性能测试
     测试次数       是否并发处理        消息数量     

    queuePrefetch
        consumers     耗时
         1              是         15000              100             40      7s
         2              是         15000              100             47      5s
         3              是         15000              100             41      6s

    将ActiveMQ的queuePrefetch参数修改为100,那么发现有近一半的消费者在处理数据,最后15000条消息需要6s中就可以处理完成。

     
    4.3.5 结论

    通过以上两步的优化后的测试结果可以得出,取消同步锁之后队列的消费能力提升了近11倍,在取消同步锁的基础上再优化ActiveMQ批处理参数后性能又提升了近1倍,综合以上两步的优化处理,队列整体的消费能力提高了30多倍。

    images/P6apYdBQDDR8mHN4y5if3JGdrTf5yFDh.png

     
    5 阶段二优化方案

    阶段二的优化方案是在阶段一的基础上进行的优化处理

     
    5.1 单队列处理

    images/KNRAKFBzwpGDAwmJcak3YWeF3W7N8xW6.png

     

    由于我们的消息通知业务属于幂等性操作,会按照设定的通知次数来反复通知处理,直到通知成功为止,我们系统现在的做法是将接收到MQ的消息暂存于延时队列(DelayQueue)中,然后通过多线程轮训取出,然后通过HTTP通知到其他模块处理,如果通知失败,则重新放入同一个延时队列等待下次执行,如上图:消息1通知失败后会重新放入延时队列。

    注:单队列处理的不足

    由于使用了单队列处理,使得可以一次通知成功的消息与通知多次失败的消息混合在了一起,这样在队列中失败通知的消息就会阻塞到后续可以正常通知的消息,最终导致消息整体的一个吞吐量下降
    5.2 双队列处理

    images/5EFSdy2S7dRypxzThmjYr7WDM6SKjiiQ.png

     

    针对5.1单队列的不足,我们可以重新设计,将单队列设计为双队列处理,双队列的核心思想为如果队列1中的消息通知失败,则不再重新放入队列1,而是放入队列2去通知,这样可以起到消息数据分离的作用,及失败通知的数据不再会影响到后续可以成功通知的消息,从而提高队列消息通知的整体性能!

     
    6 阶段三优化方案

     
    6.1 MQ组件重选型

    ActiveMQ是一个老牌的消息队列组件,吞吐量方面表现不是很理想,适合在业务量不大的场景中使用,现在有非常多比较成熟及高性能高吞吐的消息队列组件可供我们选择,如:RabbitMQ、RocketMQ、Kafka,后续可根据实际情况考虑替换掉ActiveMQ组件。

     
    7 总结

    针对消息队列的数据积压问题,我们主要做了三个方面的优化处理,取消同步锁、ActiveMQ参数优化、本地双队列优化,通过这三个方面的优化基本解决了队列数据积压的问题。

    原文:https://my.oschina.net/feinik/blog/1674168

    常见面试题:

    ======>
    重复消费:  1.设置一个主键唯一 2.redis加一个锁(setnx),拿到锁的才执行

    丢消息: ack机制 , 定时任务去补偿

    消费积压:其它中间件:多加消费者 , kafka: 多建分区

    顺序消费: 设置一个顺序id , 按照提交的顺序来消费

    更多相关内容
  • MQ面试题

    千次阅读 2021-07-15 22:32:15
    MQ面试题项目中有哪些地方使用到MQ,为什么使用MQ流量削峰(抗高并发)延迟队列业务解耦 项目中有哪些地方使用到MQ,为什么使用MQ 项目中MQ实现了流量削峰、延迟队列(过时取消)、业务解耦(异步发短信、发消息) ...

    项目中有哪些地方使用到MQ,为什么使用MQ

    项目中MQ实现了流量削峰延迟队列(过时取消)、业务解耦(异步发短信、发消息)

    流量削峰(抗高并发)

    异步进行业务处理,仅发送消息到消息队列减少响应时间

    限流
    在这里插入图片描述

    延迟队列

    因为需求中需要延迟执行某个功能

    比如下订单后如果用户未付款需要延迟对订单进行取消,这时候可以下订单后将订单信息放入延迟队列中,延迟队列的消息过期后加入取消队列(死信队列),消费取消队列中的消息并判断订单是否已付款,如果未付款的话进行取消订单。

    在这里插入图片描述

    业务解耦

    因为需要将时间耗费将长对核心业务不造成影响的非核心业务和核心业务进行解耦
    比如下订单业务下订单后发短信发优惠券等业务应该进行解耦,非核心业务不应该影响核心业务的结果,而且核心业务执行完后可以发送消息到MQ并立即响应结果,不需要非核心业务的响应
    在这里插入图片描述

    MQ与多线程实现异步的区别

    多线程实现异步会消耗cpu资源,当单机配置达到瓶颈时就会影响到核心业务线程,发生cpu竞争问题
    而MQ实现异步是完全解耦的,可以在多个服务器上异步处理不同的业务,因此在分布式开发中经常使用

    MQ如何避免消息堆积

    产生背景:
    生产者投递消息的速率大于消费者消费的速率,消息堆积在MQ服务器中,没有及时被消费,产生消息堆积问题
    解决办法:
    1、提高消费者消费速率(对消费者实现集群)
    2、消费者批量获取消息,减少网络传输次数

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

    幂等性: 就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击而产生了副作用。

    深入理解幂等性

    比如订单付款业务,保证客户端与服务端的交易一致性,避免多次扣款。通过业务逻辑进行处理:

    1、查询订单支付状态
    2、如果判断状态已经支付,直接返回结果
    3、如果判断状态未支付,支付扣款并保存流水并返回支付结果

    问题:保证幂等的方案是分成两步的,第2步依赖第1步的结果,无法保证原子性
    因此高并发情况下可能出现的情况:在第一次请求第2步订单状态还没有修改为已支付状态第二次请求就已经到来查询,就会出现第二次请求查询时状态还是未支付状态,进行了重复支付,破坏了幂等性

    可以通过分布式锁来解决,实现支付时先查询redis中是否存在订单id的key,如果不存在则可以添加订单id的key获取锁并进行查询订单支付状态,进行支付等操作,支付完成后删除redis中订单id的key进行释放锁。
    这样使用redis实现分布式锁,这次订单请求完成前,下次订单请求只能等待获取锁。

    MQ如何保证消息不丢失,如何保证消息的可靠性问题

    解决RabbitMQ消息丢失问题和保证消息可靠性
    在这里插入图片描述

    1、生产者
    开启消息确认机制,并在发送前对消息进行持久化(redis)
    2、MQ
    开启MQ的持久化
    3、消费者
    关闭消息自动确认机制,进行手动确认

    MQ如何保证消息顺序的一致性

    如果三个任务t1,t2,t3要按顺序消费,那就把他们放在一个队列中,然后只用一个消费者单线程的来处理消息。关键点就是一个队列、一个消费者、单线程,确保消息投递到同一个队列,同一个消费者消费,单线程

    MQ保证Mysql与Redis数据一致性问题

    方案1:直接删除redis缓存,让下次查询时直接查询数据库–延迟双删策略

    延迟双删图解

    两次删除缓存都是为了清空缓存防止更新数据库期间出现查询再次进行缓存

    延迟是为了让更新数据库期间的查询完全执行完再进行删除,保证下一次进行查询时是新数据

    缺点:吞吐量低,如果大量进行数据库操作需要重复删除缓存

    方案2:基于canal框架订阅binlog进行同步
    在这里插入图片描述
    canal的工作原理就是把自己伪装成MySQL slave,模拟MySQL slave的交互协议向MySQL Mater发送 dump协议,MySQL mater收到canal发送过来的dump请求,开始推送binary log给canal,然后canal解析binary log,再发送到存储目的地

    canal的好处在于对业务代码没有侵入,因为是基于监听binlog日志去进行同步数据的

    1、canal伪装成mysql从节点订阅mysql主节点的binlog文件
    2、mysql主节点发生变化,推送binlog给canal
    3、canal服务器将binlog文件转化成json对象给mq
    4、消费者消费mq中的json实现异步更新缓存

    展开全文
  • 1mq上–面试题

    2021-01-07 05:35:24
    文章目录1 为什么使用消息队列啊1.1 解耦1.2 异步1.3削峰2 消息队列有什么优点和缺点啊?3 kafka、activemq、rabbitmq、...没有使用mq: A系统发送个数据到BCD三个系统,接口调用发送,那如果E系统也要这个数据呢
  • Java消息中间件MQ面试题(2022最新版)
  • MQ相关面试题

    2022-03-08 20:11:11
    文章目录你们项目中哪些地方有使用到 MQ ? 你们项目中哪些地方有使用到 MQ ? 使用 MQ 异步发送优惠券; 使用 MQ 异步发送通知(短信、邮件); 使用 MQ 异步扣库存 使用MQ异步审核贷款金额 使用MQ异步第三方接口...

    你们项目中哪些地方有使用到 MQ ?
    1. 使用 MQ 异步发送优惠券;
    2. 使用 MQ 异步发送通知(短信、邮件);
    3. 使用 MQ 异步扣库存
    4. 使用MQ异步审核贷款金额
    5. 使用MQ异步第三方接口(中国公民信息网)

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    为什么需要使用 MQ?

    1.异步处理(多线程和 MQ)
    2.实现解耦
    3.流量削峰(MQ 可以实现抗高并发)

    可以按场景简述,录单流程:用户手机端填写录单流程,服务端接收到请求信息后,存储数据库,响应客户录单成功,然后写一条消息到MQ中,具体生成整张保单信息的耗时处理,报单中心模块监听MQ信息进行处理,最后,给客户发送保单成功短信通知。

    解耦:客户端请求到服务端,用户信息写入落库,主线程响应客户端,另起一个子线程发送MQ系统,耗时操作,让具体的业务系统慢慢处理。当采用多线程时,主线程和子线程都在同一个服务器上,当服务器当即后,一些操作就无法完成;当使用MQ时,具体业务耗时逻辑的操作有另一个服务器负责去完成,二者没有关联,当前这宕机后后者无影响。

    流量削峰:

    背景:客户端50个请求到服务端tomcat,而tomcat内部线程容量是有限制的,比如说同时处理只能处理50个任务,当其他任务进行来时,会缓存对队列中,当处理的请求越来越多就会阻塞线程或者内存溢出。

    处理方案:客户端50个请求到服务端tomcat,而tomcat不做具体耗时逻辑处理,信息落库后,直接响应客户端,然后发一条消息到业务系统的MQ中就可以了。
    MQ 与多线程实现异步的区别?

    1.多线程方式实现异步可能会消耗到我们的 CPU资源,可能会影响到我们业务线程执行 会发生 CPU竞争的问题,例如:单核多线程,cpu上下文切换,会出现卡顿现象
    2.MQ 方式实现异步是完全解耦,适合于大型互联网项目;
    3.小的项目可以使用多线程实现异步,大项目建议使用 MQ 实现异步;

    在这里插入图片描述

    MQ 如何避免消息堆积的问题?

    1.提高消费者消费的速率;(对我们的消费者实现集群)
    2.消费者应该批量形式获取消息 减少网络传输的次数;

    说明:同一个组中多个消费者不会重复消费同一条消息。(均摊策略等等)

    理解:

    1.产生背景: 生产者投递消息的速率与我们消费者消费的速率完全不匹配。

    2.生产者投递消息的速率>消费者消费的速率 导致我们消息会堆积在我们 MQ 服务器端中,没有及时的被消费者消费 所以就会产生消息堆积的问题
    3.注意的是:
    rabbitMQ 消费者我们的消息消费如果成功的话 消息会被立即删除。
    kafka 或者 rocketMQ 消息消费如果成功的话,消息是不会立即被删除。

    MQ 宕机了消息是否会丢失呢?

    不会,因为我们消息会持久化在我们硬盘中。

    MQ 如何保证消息不丢失?
    1.MQ 服务器端 消息持久化到硬盘

    2.生产者 消息确认机制 必须确认消息成功刷盘到硬盘中,才能够人为消息投递成功。

    3.消费者 必须确认消息消费成功 。

    rabbitMQ 中:才会将该消息删除。

    rocketMQ 或者 kafka 中:消息消费后会提交 offse偏移量,消息并不会立即删除。

    (消息删除通过日志保留策略配置,过了48小时在进行删除)

    生产者投递消息,MQ 宕机了如何处理?

    1.生产者投递消息会将 msg 消息内容记录下来,后期如果发生生产者投递消息失败;
    2.可以根据该日志记录实现补偿机制;
    3.补偿机制(获取到该 msg 日志消息内容实现重试)

    MQ 如何保证消息顺序一致性问题?

    将消息需要投递到同一个 MQ 服务器,同一个分区模型中存放,最终被同一个消费者消费。
    核心原理:设定相同的消息 key,根据相同的消息 key 计算 hash 存放在同一个分区中。

    产生背景:

    MQ服务器集群或者MQ采用分区模型架构存放消息,每个分区对于一个消息者消费消息。

    解决消息顺序一致性问题:

    核心办法:消息一定要投递到同一个MQ、同一个分区模型,最终被同一个消费者消费。

    根据消息key计算%分区模型总数。

    理解:

    1.大多数的项目是不需要保证 MQ 消息顺序一致性的问题,只有在一些特定的场景可能会需要,比如 MySQL 与 Redis 实现异步同步数据;

    2.所有消息需要投递到同一个 MQ 服务器,同一个分区模型中存放,最终被同一个消费者消费,核心原理:设定相同的消息 key,根据相同的消息 key 计算 hash 存放在同一个分区中。
    如果保证了消息顺序一致性有可能降低我们消费者消费的速率。
    在这里插入图片描述

    为什么保证了消息顺序一致性有可能降低我们消费者消费的速率?解决方案

    在这里插入图片描述

    MQ 如何保证消息幂等问题?

    在这里插入图片描述

    展开全文
  • 消息队列MQ常见面试题

    千次阅读 2022-02-13 16:59:42
    面试官在面试候选人时,如果发现候选人的简历中写了在项目中使用了 MQ 技术(如 Kafka、RabbitMQ、RocketMQ),基本都会抛出一个问题:在使用 MQ 的时候,怎么确保消息 100% 不丢失? 这个问题在实际工作中很常见,...

    面试官在面试候选人时,如果发现候选人的简历中写了在项目中使用了 MQ 技术(如 Kafka、RabbitMQ、RocketMQ),基本都会抛出一个问题:在使用 MQ 的时候,怎么确保消息 100% 不丢失?

    这个问题在实际工作中很常见,既能考察候选者对于 MQ 中间件技术的掌握程度,又能很好地区分候选人的能力水平。

    接下来,我们就从这个问题出发,探讨你应该掌握的基础知识和答题思路,以及延伸的面试考点。

    案例背景:
    以京东系统为例,用户在购买商品时,通常会选择用京豆抵扣一部分的金额,在这个过程中,交易服务和京豆服务通过 MQ 消息队列进行通信。在下单时,交易服务发送“扣减账户 X 100 个京豆”的消息给 MQ 消息队列,而京豆服务则在消费端消费这条命令,实现真正的扣减操作。
    在这里插入图片描述那在这个过程中你会遇到什么问题呢?
    案例分析:
    要知道,在互联网面试中,引入 MQ 消息中间件最直接的目的是:做系统解耦合流量控制,追其根源还是为了解决互联网系统的高可用和高性能问题。

    系统解耦:用 MQ 消息队列,可以隔离系统上下游环境变化带来的不稳定因素,比如京豆服务的系统需求无论如何变化,交易服务不用做任何改变,即使当京豆服务出现故障,主交易流程也可以将京豆服务降级,实现交易服务和京豆服务的解耦,做到了系统的高可用。
    流量控制:遇到秒杀等流量突增的场景,通过 MQ 还可以实现流量的“削峰填谷”的作用,可以根据下游的处理能力自动调节流量。
    不过引入 MQ 虽然实现了系统解耦合流量控制,也会带来其他问题。

    引入 MQ 消息中间件实现系统解耦,会影响系统之间数据传输的一致性。 在分布式系统中,如果两个节点之间存在数据同步,就会带来数据一致性的问题。同理,在这一讲你要解决的就是:消息生产端和消息消费端的消息数据一致性问题(也就是如何确保消息不丢失)。
    而引入 MQ 消息中间件解决流量控制, 会使消费端处理能力不足从而导致消息积压,这也是你要解决的问题。

    所以你能发现,问题与问题之间往往是环环相扣的,面试官会借机考察你解决问题思路的连贯性和知识体系的掌握程度。

    那面对“在使用 MQ 消息队列时,如何确保消息不丢失”这个问题时,你要怎么回答呢?首先,你要分析其中有几个考点,比如:

    如何知道有消息丢失?
    哪些环节可能丢消息?
    如何确保消息不丢失?

    候选人在回答时,要先让面试官知道你的分析思路,然后再提供解决方案:网络中的数据传输不可靠,想要解决如何不丢消息的问题,首先要知道哪些环节可能丢消息,以及我们如何知道消息是否丢失了,最后才是解决方案(而不是上来就直接说自己的解决方案)。就好比“架构设计”“架构”体现了架构师的思考过程,而“设计”才是最后的解决方案,两者缺一不可。
    案例解答:
    我们首先来看消息丢失的环节,一条消息从生产到消费完成这个过程,可以划分三个阶段,分别为消息生产阶段,消息存储阶段和消息消费阶段。
    在这里插入图片描述
    消息生产阶段: 从消息被生产出来,然后提交给 MQ 的过程中,只要能正常收到 MQ Broker 的 ack 确认响应,就表示发送成功,所以只要处理好返回值和异常,这个阶段是不会出现消息丢失的。
    消息存储阶段: 这个阶段一般会直接交给 MQ 消息中间件来保证,但是你要了解它的原理,比如 Broker 会做副本,保证一条消息至少同步两个节点再返回 ack。
    消息消费阶段: 消费端从 Broker 上拉取消息,只要消费端在收到消息后,不立即发送消费确认给 Broker,而是等到执行完业务逻辑后,再发送消费确认,也能保证消息的不丢失。
    方案看似万无一失,每个阶段都能保证消息的不丢失,但在分布式系统中,故障不可避免,作为消息生产端,你并不能保证 MQ 是不是弄丢了你的消息,消费者是否消费了你的消息,所以,本着 Design for Failure 的设计原则,你还是需要一种机制,来 Check 消息是否丢失了。
    紧接着,你还可以向面试官阐述怎么进行消息检测? 总体方案解决思路为:在消息生产端,给每个发出的消息都指定一个全局唯一 ID,或者附加一个连续递增的版本号,然后在消费端做对应的版本校验。

    具体怎么落地实现呢?你可以利用拦截器机制。 在生产端发送消息之前,通过拦截器将消息版本号注入消息中(版本号可以采用连续递增的 ID 生成,也可以通过分布式全局唯一 ID生成)。然后在消费端收到消息后,再通过拦截器检测版本号的连续性或消费状态,这样实现的好处是消息检测的代码不会侵入到业务代码中,可以通过单独的任务来定位丢失的消息,做进一步的排查。

    这里需要你注意:如果同时存在多个消息生产端和消息消费端,通过版本号递增的方式就很难实现了,因为不能保证版本号的唯一性,此时只能通过全局唯一 ID 的方案来进行消息检测,具体的实现原理和版本号递增的方式一致。

    现在,你已经知道了哪些环节(消息存储阶段、消息消费阶段)可能会出问题,并有了如何检测消息丢失的方案,然后就要给出解决防止消息丢失的设计方案。
    回答完“如何确保消息不会丢失?” 之后,面试官通常会追问“怎么解决消息被重复消费的问题? ”
    比如:在消息消费的过程中,如果出现失败的情况,通过补偿的机制发送方会执行重试,重试的过程就有可能产生重复的消息,那么如何解决这个问题?

    这个问题其实可以换一种说法,就是如何解决消费端幂等性问题(幂等性,就是一条命令,任意多次执行所产生的影响均与一次执行的影响相同),只要消费端具备了幂等性,那么重复消费消息的问题也就解决了。

    我们还是来看扣减京豆的例子,将账户 X 的金豆个数扣减 100 个,在这个例子中,我们可以通过改造业务逻辑,让它具备幂等性。
    在这里插入图片描述
    最简单的实现方案,就是在数据库中建一张消息日志表 ,这个表有两个字段:消息 ID 和消息执行状态。这样,我们消费消息的逻辑可以变为:在消息日志表中增加一条消息记录,然后再根据消息记录,异步操作更新用户京豆余额。

    因为我们每次都会在插入之前检查是否消息已存在,所以就不会出现一条消息被执行多次的情况,这样就实现了一个幂等的操作。当然,基于这个思路,不仅可以使用关系型数据库,也可以通过 Redis 来代替数据库实现唯一约束的方案。

    在这里我多说一句,想要解决“消息丢失”和“消息重复消费”的问题,有一个前提条件就是要实现一个全局唯一 ID 生成的技术方案。这也是面试官喜欢考察的问题,你也要掌握。

    在分布式系统中,全局唯一 ID 生成的实现方法有数据库自增主键、UUID、Redis,Twitter-Snowflake 算法,我总结了几种方案的特点,你可以参考下。
    在这里插入图片描述
    我提醒你注意,无论哪种方法,如果你想同时满足简单、高可用和高性能,就要有取舍,所以你要站在实际的业务中,说明你的选型所考虑的平衡点是什么。我个人在业务中比较倾向于选择 Snowflake 算法,在项目中也进行了一定的改造,主要是让算法中的 ID 生成规则更加符合业务特点,以及优化诸如时钟回拨等问题。
    当然,除了“怎么解决消息被重复消费的问题?”之外,面试官还会问到你“消息积压”。
    原因在于消息积压反映的是性能问题,解决消息积压问题,可以说明候选者有能力处理高并发场景下的消费能力问题。
    你在解答这个问题时,依旧要传递给面试官一个这样的思考过程: 如果出现积压,那一定是性能问题,想要解决消息从生产到消费上的性能问题,就首先要知道哪些环节可能出现消息积压,然后在考虑如何解决。

    因为消息发送之后才会出现积压的问题,所以和消息生产端没有关系,又因为绝大部分的消息队列单节点都能达到每秒钟几万的处理能力,相对于业务逻辑来说,性能不会出现在中间件的消息存储上面。毫无疑问,出问题的肯定是消息消费阶段,那么从消费端入手,如何回答呢?
    如果是线上突发问题,要临时扩容,增加消费端的数量,与此同时,降级一些非核心的业务。通过扩容和降级承担流量,这是为了表明你对应急问题的处理能力。

    其次,才是排查解决异常问题,如通过监控,日志等手段分析是否消费端的业务逻辑代码出现了问题,优化消费端的业务处理逻辑。
    最后,如果是消费端的处理能力不足,可以通过水平扩容来提供消费端的并发处理能力,但这里有一个考点需要特别注意, 那就是在扩容消费者的实例数的同时,必须同步扩容主题 Topic 的分区数量,确保消费者的实例数和分区数相等。如果消费者的实例数超过了分区数,由于分区是单线程消费,所以这样的扩容就没有效果。

    比如在 Kafka 中,一个 Topic 可以配置多个 Partition(分区),数据会被写入到多个分区中,但在消费的时候,Kafka 约定一个分区只能被一个消费者消费,Topic 的分区数量决定了消费的能力,所以,可以通过增加分区来提高消费者的处理能力。

    总结:
    至此,我们讲解了 MQ 消息队列的热门问题的解决方案,无论是初中级还是高级研发工程师,本篇文章的内容都是你需要掌握的,你都可以从这几点出发,与面试官进行友好的交流。我来总结一下今天的重点内容。

    如何确保消息不会丢失? 你要知道一条消息从发送到消费的每个阶段,是否存在丢消息,以及如何监控消息是否丢失,最后才是如何解决问题,方案可以基于“ MQ 的可靠消息投递 ”的方式。
    如何保证消息不被重复消费? 在进行消息补偿的时候,一定会存在重复消息的情况,那么如何实现消费端的幂等性就这道题的考点。
    如何处理消息积压问题? 这道题的考点就是如何通过 MQ 实现真正的高性能,回答的思路是,本着解决线上异常为最高优先级,然后通过监控和日志进行排查并优化业务逻辑,最后是扩容消费端和分片的数量。
    在回答问题的时候,你需要特别注意的是,让面试官了解到你的思维过程,这种解决问题的能力是面试官更为看中的,比你直接回答一道面试题更有价值。
    另外,如果你应聘的部门是基础架构部,那么除了要掌握本讲中的常见问题的主线知识以外,还要掌握消息中间件的其他知识体系,如:

    如何选择消息中间件?
    消息中间件中的队列模型与发布订阅模型的区别?
    为什么消息队列能实现高吞吐?
    序列化、传输协议,以及内存管理等问题
    … >
    转自公众号:Java项目分享

    展开全文
  • MQ常见面试题

    2022-05-04 11:33:33
    MQ常见面试题面试题为什么要使用MQ在项目中使用MQ实现了什么功能MQ如何确保消息发送和消息接收如何防止消息丢失如何保证消息不被重复消费(幂等性)如何解决消息堆积问题MQ中的死信队列、延时队列结语 面试题 为什么...
  • MQ-A级面试题.pdf

    2020-06-07 14:47:20
    消息队列(MQ),是一种应bai用程序du对应用程序的通信方法。zhi应用程序通过写和检索dao出入列队的针对应用程序的数据(消息)来通信,而无需专用连接来链接它们。
  • 消息中间件MQ与RabbitMQ面试题(2020最新版)

    万次阅读 多人点赞 2020-03-01 11:11:21
    文章目录为什么使用MQMQ的优点消息队列有什么优缺点?RabbitMQ有什么优缺点?你们公司生产环境用的是什么消息中间件?Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点?MQ 有哪些常见问题?如何解决这些问题?...
  • Rabbit MQ 面试题相关

    千次阅读 2018-08-03 20:48:26
    项目中的MQ: #rabbitmq spring.rabbitmq.host=127.0.0.1 主机 spring.rabbitmq.port=5672 端口 spring.rabbitmq.username=guest 用户名 spring.rabbitmq.password=guest 密码 spring.rabbitmq.virtual-host=/ #\...
  • 几种常见的MQ面试题 相关视频参考(来自动力节点):https://www.bilibili.com/video/BV1Ap4y1D7tU 相关资料下载:http://www.bjpowernode.com/?csdn 为什么使用消息队列? 其实就是问问你消息队列都有哪些使用...
  • 你们项目中哪些地方有使用到MQ2. 为什么需要使用MQ3. MQ 与多线程实现异步的区别4. MQ 如何避免消息堆积的问题5. MQ 宕机了消息是否会丢失呢6. MQ 如何保证消息不丢失7. 生产者投递消息,mq 宕机了如何处理8. MQ ...
  • 1.为什么要引入MQ/RabbitMQ(中间件),直接读写数据库不行吗? 1、在分布式系统下中间件具备异步处理,流量削峰等一系列高级功能; 2、中间件可以实现生产者和消费者之间的解耦。 3、拥有持久化的机制,进程消息,...
  • MQ消息中间件常见面试题

    千次阅读 2021-02-16 21:41:06
    面试官问这个问题的期望之一的回答是,你们公司有什么业务场景,这个业务场景有什么技术挑战,如果不用MQ可能会很麻烦,但是再用了之后带来了很多好处。 消息队列的常见使用场景有很多但是核心的有三个:解耦、异步...
  • MQ常见面试题 1.1、场景\业务 例: 需求:1.下单后,30分钟为支付,取消订单,回滚库存 2.新用户注册成功7天后,发送短信问候 解:使用MQ高级特效—延迟队列(设置多久消费这条消息) P:MQ中并未提供延迟队列功能。...
  • 【BAT必备】rabbitMq面试题【BAT必备】rabbitMq面试题【BAT必备】rabbitMq面试题【BAT必备】rabbitMq面试题【BAT必备】rabbitMq面试题【BAT必备】rabbitMq面试题【BAT必备】rabbitMq面试题【BAT必备】rabbitMq面试题...
  • 面试题 为什么使用消息队列? 消息队列有什么优点和缺点? Kafka、ActiveMQ、RabbitMQ、RocketMQ、Pulsar不同MQ中间件有什么区别及适用场景? ······ MQ,消息队列,消息可以理解为一个业务现场,而队列则是...
  • RabbitMQ面试题以及答案整理【最新版】RabbitMQ高级面试题大全(2021版),发现网上很多RabbitMQ面试题都没有答案,所以花了很长时间搜集,本套RabbitMQ面试题大全 如果不背 RabbitMQ面试题的答案,肯定面试会挂! ...
  • 大量消息在 mq 里积压了几个小时了还没解决 2.mq 中的消息过期失效了 3.mq 都快写满了 12.消息队列的一般存储方式有哪些? 1. 分布式KV存储 2. 文件系统 3. 关系型数据库 DB 小结 1.什么是消息队列? 可以看作是一个...
  • ActiveMQ面试题

    2022-02-16 14:45:30
    1.什么是activemq activeMQ是一种开源的,实现了JMS1.1规范的,面向消息(MOM)的中间件,为应用程序提供高效的、可扩展的、稳定的和安全的企业级消息通信。 2. activemq的作用以及原理 Activemq 的作用就是系统...
  • 最近梳理2021最新 Redis面试题【附答案解析】,包含了 Java基础、并发、JVM、数据库、Spring、SpringMVC、Redis、SpringCloud、设计模式、MQ、Linux、Redis等多个类型。 今天这篇是关于 Redis,总结了 110 道经典...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 15,878
精华内容 6,351
关键字:

mq面试题

友情链接: godot_heightmap_plugin.zip