00:00
前面我们说了发送端的消息确认机制,我们主要呢,两个回调confirm call bank和return call bank,那接下来我们就来说我们消费端,那现在来从队列里边来消费消息的时候,我们也可以来引入我们的确认机制,这个确认机制呢,主要就是我们的ACK机制,我们的消息确认机制,这个ACK机制是什么?就是呢,我们消息一旦我们消费者我们的consumer从队列里边只要获取来了消息,他呢就会给服务器自动回复,诶,我们已经确认收货了,就跟我们收快递一样,我们确认收货了,你的这个消息确认交付给我们了,那接下来我们的服务器就会将此消息来进行删除,当然这个模式呢,它是自动确认的,所以我们现在来打开我们这一块来看一下,那将以前的收消息我们拿过来,把这一块的收消息,我们现在全部拿来,把这一块的收消息来打开,那我们。
01:01
只要一启动服务器,它呢就会来监听我们这个队列,队列里边呢,就会来接收我们的这个消息,而且只要接收到消息,它是自动确认的,所以呢,我们现在来看到,我们只要收到消息,默认一收到消息,队列里边就会删除这些消息,我现在来确认一下,队列里边呢,现在有50个消息,那如果我们现在来启动我们这个服务,将这些消息都来接收,那我们这些消息呢,就会从队列里边删除,先来看第一个现象。好,我们现在呢,服务启动成功,然后我们在这一块呢,全部在这来消费消息,诶接收到消息接收了很多,然后我们来看我们这一块的效果,50个消息呢,全部被处理完成,只要消息被处理完,我们这一块呢就会移除,而且呢,我们说处理完了以后,它会自动的ack,相当于自动的回复,所以我们接下来来先来说我们的这一个场景,我们的消息,我们消费端确认,首先消费端确认呢,默认是自动确认模式,默认是自动确认的,确认的只要消息接收到,只要消息接收到,然后呢,我们这个服务端,服务端就会移除,就会移除这个消息,这个消息,而且它是怎么移除的,是由于我们这个客户端它会自动确认,客户端会自动确认,但是呢,这种模式有没有什么问题?我们来比如来举一个例子。我们现在如果是自。
02:30
确认模式下,好,我们现在来就来监听我们的这个消息,我们给这儿来打一个断点,当这个消息收到以后呢,我们接下来就来接,我们现在就来发送上几个消息,我们还是来发送上十个消息,我们既然打断点呢,我现在以debug模式把它打开。然后呢,我们来准备来发上十个消息,们这个队列里边现在没有任何消息,它是空的,我们接下来调用我们的这个方法来发送上十个消息来看一下,好,那们现在呢,我们order启动成功,我们现在来发消息,但我们一旦一发消息,那肯定呢消息就结束成功了,来点一个发送消息,那消息发送成功,我们这一块呢,就接收接收到我们来第一个消息,哈哈,零,而且呢,我们来看我们的监控台,我监控台我来刷新,我们发现呢,监控台里边呢消息有五个,而且呢啊AC也就说没有回复的是五个消息,然后我们来接收到的第一个消息,我们只要第一个消息在这儿处理完成,我们一来放行,我们发现呢,接下来我们一放行以后,我们这一块我来刷新,我们这儿呢,就有一个消息被删除了,先剩了四个消息,因为有一个消息呢,已经被全部处理完了。
03:46
所以呢,他删除了,那接下来我们继续来处理,我处理到这儿,我们来模拟我们这个消息呢,没有被成功处理,如果我们这个成功处理,我们可要执执行一些动作什么的,我们现在没被成功处理,或者呢,我们这个客户端直接宕机,好,我们把这个消息停掉,我们直接将这个客户端停掉,走们现在只处理了一个消息,我们客户端就宕机了,我们停掉了,停掉了以后呢,我们来看我们的这一块,Re MQ re MQ,我再来刷新,接下来我们就会发现一个非常大的问题,那就是我们这一块消息全部变成了零个,零个那就是我们没有消息了,那其实上我们只收了一个消息,处理完以后我们宕机了,那宕机以后呢,我们客户端把这些消息全部就删除了,删除的原因那就是我们说的自动A机制,那么这个方法呢,只要一运行我们这个通道里边收的消息,通道一打开,消息一进来,那就是自动确认了。所以我们现在出现的一个问。
04:47
题就是丢消息,我们现在的这个问题,我们刚才模拟出来了,就是我们收到了一个消息,我们收到一个消息,一个消息,其实我们这个自动收消息,我们相当于收到很多消息,但是呢,只有一个处理成功,收到很多消息,但现在呢,都自动回复了,自动。
05:08
回复给我们这个服务器AC了,现在我们已经收获了,但是呢,只有一个消息,只有一个我们消息处理成功,处理成功,然后呢,宕机了,所以呢,我们就会发生了,我们发生消息丢失,消息丢失,消息丢失的原因,那就是我们在这一块正处理一半,我们整个消息呢全部宕机,那宕机以后呢,我们剩下的那些消息,由于我们已经是确认了的,自动确认了的,所以呢,我们服务器就给他们手动删除了,所以我们接下来就需要保证我们这个消息不丢失,那我们就需要手动确认,我们可以手动确认,怎么手动确认,那就是我们消息只要我们处理一个,我们给他确认一个,处理一个给他确认一个,我们没确认的消息,你都不能进行删除,所以我们想要手动确认这些事情呢?我们也做的很简单,我们只需要在配置里边来填上一。
06:08
的配置叫SP,有一个叫rabbit listener,咱们这个监听器里边有一个叫simple acknowledge mode,所以呢,我们现在来设置一个它简单的这个knowledge mode,那简单的这个回复模式,它有一个这个mode,这个模式呢,默认是auto自动回复,就是我们这个消息,只要我们消费端CONSUMER1连上,我们这个队列所有消息一抵达,这全部都自动回复了,并不是说你消息成功处理了,还是失败处理了,只要你一连上全就抵达你了,那我们就相当于自动回复了,而我们这个自动回复呢,会有问题,我们只要有哪些消息没处理,或者处理一半这些消息都会丢失,所以我们可以给他进入手工模式,那么一进入手工模式以后啊,我们现在来给他进入我们的这个手工模式,那我们这一块的设置就是我们这个手动,手动我们称为叫AC消息,AC的全称叫。
07:08
Knowledge它的翻译过来就是确认收货,手动确认收货,那我们怎么手动确认收货来到我们这一块,我们在这儿来接收消息的时候,我们发现呢,我们这儿还有一个东西叫通道,我们首先开启手动确认模式,一旦我们开启手动确认模式,只要我们不确认的消息,它呢都不算我们这个成功处理好,我们给这打上断点,那现在呢,先来以debug模式来启动,我们现在呢是开启了手动确认模式,我们看还有没有以前的这些问题,门前消息发来,我们处理上一两个,一中断,其他消息呢都丢失,那么现在来看一下我的这个功能。那现在消息发过来,来看还会不会出现我们这个问题,那么现在来先来测试发消息,首先这个队列里边来刷新好,没有任何一条消息,然后呢,来给它发送上我们这几条消息,来点一个send MQ。
08:08
走,那消息发送成功,我们队列里边我来刷新一下看效果好,我们现在队列里边呢,总量有五个on a啊A就是没有回复服务器,我们收到的这个消息,现在数目呢有五个,那有五个,接下来我们来收到第一个消息,哈哈零走,我们收到第一个消息,假设我们这个处理完,接下来我们再来到这个方法放行,那接下来呢,来到哈哈二,我们再在这儿处理,但是呢,我们开启了手动确认模式,我们没给他确认,我们来看我们这一块,我来刷新,只要我们没确认的,那全部都在,嗯,A这我们无论处理了多少消息,我们假设呢都没确认,那现在第三个消息我突然宕机,走,我现在呢,突然消息宕机了,我们整个这个consumer宕机了,来看我们这一块来刷新,诶我发现呢,我们这一块呢,消息不丢失了,由on ack变成了ready,所以呢,我们这个消息相当。
09:08
还在队列里边存着,因为数量呢有五个,那么下一次启动起来,一消费呢,它还会有的,所以我们接下来再来启动,如果我们再来启动这个服务,我们这一块呢,还能收到这些消息,因为这些消息呢,上一次没有被成功处理,没有成功的回复服务器,我们收货了,我们确认收货了,所以服务器呢,默认只要你没签收,那默认都是未签收状态啊AC,那未签收状态你的这个consumer中断了,那所有未签收的消息全部呢都回到ready状态,我们准备再来重新发送,好,那现在呢,这个consumer我们现在重新又启动起来了,我们断联呢又停到这儿,现在我们来看我们的这些消息,只要我们这个CONSUMER1启动起来,所有的消息呢,一次性全交给我们的consumer,然后我们consumer拿到消息挨个来进行处理,确认收货,所以我们现在五个消息呢,全部交给他,这五个呢,都是on a没有签收状态,我们呢。
10:08
那只要服务端没签收,我们哪怕中断我们这个消息一个没处理中断我们这些消息呢,全部都会进入ready状态,来看一下我们现在的效果,好,我们全部进入了ready状态没问题,所以呢,我们的消息只要是手动确认模式下,我们不确认消息呢,就不丢,好我们先来到这一块手动确供认模式下,我们在这儿来备注一下手动确认模式,只要我们没说签收货物,只要我们没有明确说,明确告诉MQ我们这个货物已经被签收,货物被签收,货物被签收相当于我们没有给他AC,没有ACAC,那么这个消息就一直是on ack的,就是一直是这个状态,这个状态就是说呢,没有被签收状态一直是这个状态,那一旦是这个状态,即。
11:08
是服务器宕机,即使我们这个consumer宕机,比如我们现在呢,是consumer宕机,即使我们这个consumer宕机,那我们这个消息呢,也不会丢失,消息不会丢失,不会丢失会重置为会重新变为我们这个ready状态,Ready呢就是我们来准备给下一次继续来发送,变为ready,然后呢,下一次有新的客户端,有新的咱们这个consumer连接进来,我们就发给他,Consumer链接进来就发给他,所以呢,我们首先使用手动模式,我们能保证我们消费者货物不丢。好,我们这个消费者,咱们这个手动确认模式,那这个手动确认模式,那怎么才算我把这个货签收了,那如何签收,如何签收,签收我们这个货物,我们来到的这个消息,想要签收呢,也很简单,我们在这儿来监听消息,在这个消息的监听这个通道里边,假设我们这个消息处理完了,我们在通道里边它有一个方法叫basic AC开我发现呢,这块呢,有一个方法就叫AC,叫我确认收货,AC我们确认交付,所以呢,AC里边会传入我们这两个参数,第一个叫delivery tank,第二个叫multiple delivery tank,那就是我们当前消息的这个相当于派发的这个标签,它是一个数字,然后呢,Multiple multiple代表是不是我们批量确认我们这个数字呢,它有一个比较大的特点,我们先来看一下我们这个数字,我们想要确认收货,收了哪个货,我们这个。
12:49
字从哪来数字呢?其实从这来,我们每接收到的一个message,这个消息,这个消息里边呢,这个消息属性里边就封装了它的这个deliver tank,来看一下这有一个deliver tank,这个deliver tnk呢,它是一个数字,而这个数字的最大特点它是一个自增的,自增的而且是通道内自增的,就是我们当前这个通道,通道内自增的我们一个消息过来它就是一,第二个过来就是二,相当于是按照顺序自增的内容。
13:20
内按顺序按顺序自增的,所以我们给它打印一下来给大家看一下,那打印一下我们的这个看一看。Deliver tank的内容就在这,我们现在重新来启动我们的这个order,走,我们现在来重新启动,我们也不以debug模式了,只要我们启动上来收到消息,我们就会在这儿打印,只要我们给服务器没有回复A状态,那么这些消息呢,全部是on a的,先来看一下我们的效果走,好我们现在呢,给服务器没有任何回复,那们现在直接来收消息,收到以后我们来看效果,好,我们在这来打印,打印我们的deliver tank,我们是12345这五个消息呢,相当于都拿到了,但是我们给服务器没回复,只要没回复全部都是on AK状态,那接下来我们如果真的把这个消息处理成功了,我们就可以来进行回复这个消息的这个标签,它是按照我们自尊顺序来的,想要回复呢,调用这个basic AC开这个东西就是签收货物,相当于我们来签收了这个消息,那如何来签收,那这一块呢,就需要传。
14:30
来第一个deliver tank,我们把这个tank呢已经拿到了,然后接下来呢,是一个multiple multiple是否批量签收模式来写一个force false呢,代表我只签收我当前这个货物,那么现在做一个消息给他确认一个,做一个确认一个,咱们签收货物,我们现在就是挨个确认非批量模式,这个multiple们签收货物,非批量签收模式,批量模式,因为这个消费者只要一连进来,所有的消息都会交给这个通道里边,然后呢,我们非批量模式,由于它有异常,你就可以来刷看吃一下看尺,因为我们这个告诉服务端,我们这个货物签收了,肯定相当于要给服务端来发送消息,所以网络呢可能会中断,所以我们这一块呢,肯定会有异常,一能出现这个异常,那就是你这个网络中断了,网络中断了,我们这个channel通道断了,我们这个签收状态我们发不出去了,所以这是我们说的货物签收。那接下来如果我们有。
15:30
有了签收将会是什么样的效果?好,我在这儿打一个断点来进入签收模式以后我来进入debug模式,现在呢,我们原来里边呢有五个货物,我们这五个货物呢,现在都没有签收,我们之前还在我们的消息队列里边,它也没有丢失,那现在呢,开启了手动的签收模式,就是手动AC模式,然后呢,接下来每一个货物进来,我们要进行处理,每一个消息进行来处理的时候,我们都可以来给它进行手动的签收,好,大家注意,我现在来处理第一个消息,波林,哈哈林,那现在呢是来第一个消息,第一个消息我们来给他放行,走走走。
16:12
我们一直给它放行到我们的这一块签收来放行到这,然后呢,我们签收了第一个消息,走假设呢,我们第一个消息签收了,接下来我们再来放行,我们接下来来到第二个消息走走走,然后呢我们再来放行,我们假设呢第二个消息也签收了,但是呢,第二个消息刚签收完,我们这个服务器宕机了,走,那们这个服务器已宕机,我们这个客户端consumer宕机了,来看我们的re MQ什么状态,诶我们发现re MQ里边是三个未签收,总量呢剩了三个了,所有已经签收了的货物,我们来重新刷新一下,所有已经签收了的货物呢,就相当于删除了,但是我们没签收的货物我们来刷新,那这个货物呢,应该是还在的状态,但是我们这一块呢,它还是显示我们这个零条数据,这个数据的原因是什么,我们在这儿打印一下来给大家看一下,如果我们这个签收了,我们就在这儿打印签收,签收了货物,好,这是我们的这个消息,我就。
17:12
就把它比喻成我们的货物,那签收了几号的货物在这儿来打印一下,来重新来debug,来看一下我们这个数据,这是为什么走debug,那就应该是我们没签收了的人,那呢,他就应该还在我们的消息队列里边,不应该从消息队列里边删除,只有我们手工签收了的这些货物,我们才可以从消息队列里边删除。好来看一下我们的效果,现在我们已重debug,重新来启动我们这个服务,来发一下消息,好来稍等我们这个服务好这一块呢,启动成功,来发上几个消息走。我们现在发了五个消息,我们先来看一下消息队列,消息队列我来刷新,现在呢确定有五个消息,而且这五个消息呢,都是嗯,Ack模式,然后接下来我们来一个一个来测试走,那现在呢,Debug收到的第一个消息,哈哈,零,我们来放行,然后呢,我们第一个货物签收了,我们在这儿来打印签收了第一个走,我们签收了货物一好,我们再来放行,然后呢,这是我们第二个消息,我们在这儿来打印签收了货物二走,然后呢,我们接下来假设来到第三个消息,我们给中断了,来到我们这一块,我们把这个服务器我们来模拟宕机走,好,然后我们来看控制台,我们发现呢,虽然我们自己在这儿模拟宕机了,但是呢,他把剩下的这个方法给运行完了,在这打印了,签收了货物二,签收了货物三,签收了货物四,签收了货物五,所以他相当于是自己在这儿给运行完了,那为了模拟我们真正的没签收状态。
18:51
那么就在这来做一个判断,If,如果我们这个deliver tag,那这个发送的这个tag,我们对二求余,如果等等零能整除的话么,就给你签收,否则就不签收好,这一块呢就是签收好,否则else,那么就是不做任何事情,好,我们没有签收货物,没有签收货物好,那我们现在来重新来启动走,那是由于我们刚才中断的问题,中断它还把我们这个方法运行完了,但实际上应该是我们说的效果,我们稍等一下,那现在呢,直接让他以run模式来运行好,我们来让它运行,现在还是来发消息,那发来的消息有些签收,有些没签收,那没签收了的人,我们来看一下我们最终的效果。
19:38
好,我们现在来重新来发送消息,走,我们来发送好消息发过来,来到我们这个rabbit MQ里边,然后看我们的控制台打印,我们控制台呢,现在签收了没有签收一,然后呢没有签收,签收了二没有签收三没有签收,我们这个五相当于有几个消息没签收,所以我们会看到只要NA这一个消息呢,一直在是有三个消息没签收,然后我们接下来中断了这个服务,这个服务呢宕机了,他呢没有成功签收,然后我们就会看到我们这些消息呢来刷新,他们呢重新变为ready状态,我们还是可用状态,所以呢,这就是我们说的手动签收模式,我们使用basic ack可以来进行签收。
20:27
同样的,我们还可以有签收,就有拒绝模式,就像我们收货一样,我们签了,我们还有拒绝退货,那怎么退货呢?我们就在这儿,在channel里边有basic AC开,这是收货,收货来说一下退货,这个货呢,不满意了,或者呢,我打开我发现我自己处理不了了,我让你退回去让别人处理,哎,我们这儿还有一个退货,那这个退货我们可以调用channel里边的这个方法叫basic,有A,那就有no a不恢复,那这个no a它是退货,包括我们channel里边这个有一个basic。
21:07
Reject这个东西也是退货,它两个都是一样的,那唯一的区别在这在basic n a里边,它有三个参数,CTRLC。CTRLC,那在这来看一下这三个参数,而basic reject拒绝相当于我们拒签了,我们的这个里边呢,它有两个参数,我们来复制过来。然后我们会看到上边的方法比下边的方法多了一个参数,就是是否可以批量拒绝来,我们把这个拒收,我们就以上边的为例,那现在呢,拒收货物,拒收货物,拒收哪个货物,我们把它的这个标签拿过来,然后呢,还有一个布尔,布尔呢是否批量拒收,我们现在都默认为force,如果是处,那我们这个货物以前的所有货全部被拒,然后接下来还有一个瑞Q,这个瑞Q翻译过来叫重新入队,这个队列重新入队,然后我们现在给你拒收了,拒收以后这个货要不要重新发回MQ,让MQ重新放到队列里边,如果我们写为true,那这个货就会重新入队,如果我们写为force,这个货就被丢弃了,想要快递员给我们送到货,我们说这个货拒收了,你把它扔了吧,也别发回去,也别给我退款了,你就直接扔了。所以呢,这。
22:29
啊force那就是退货,退货我么这个force那就是拒收模式,瑞困如果是force那就是丢弃,那么直接丢器,如果Q等于true,那就是呢,发回服务器,发回服务器,然后呢,服务器重新入队,告诉服务器这个货物呢重新入队就行了。那么现在使用这个basic no easy,不A的模式,那现在先来测试,我们让它重新入队,来看一下我们的最终效果走,那现在最终效果呢,我们有三个货,那这三个货呢,我们如果对二求鱼肯定呢,有两个能处理成功,有一个呢处理不了,我们来看一下我们的最终效果,那现在是以run模式来看我们服务端控制台的这一块来打印。
23:22
我们到底收到了哪些货?我们拒绝了哪些货,好,我们看签收了我们这个六号货,然后没有签收五号货,但是最终我们在这儿来刷新一下,我们发现呢,这一块全部变为零,变为零的原因是什么原因,在这儿我们发现呢,我们货物是这么来投递的,先投递了一号货,我们没有签收,投递了二号货,我们签收了,我们原本呢有三个货,然后投递了三号货,我们又没有签收,接下来他又投递了四号货,这四号货是什么?来看一下我们没签收的一号货,一号货他这一块呢,叫哈哈零,然后呢,哈哈零相当于又投递过来了,然后投递过来我们重新给他签收了,因为我们这要重新入队,一入队以后呢,队列里边的消息又会发给某文,我们拿到以后呢,又给签收了,我们对二求鱼,那现在这个没钱入消息变成了第一个,我现在又能签收了,所以呢,相当于就是我们这个,我们让他入兑。
24:25
对吧,那他就入队给我们进行签收,如果我们不让他入队,False来看一下,原来打印我们都签到六号货了,好我们签到六号货了,那么现在我们再来做一个测试,那现在让他不入队,那相当于我们的这个消息不给队列里边放,我们没签收到消息,那就直接丢弃,来看一下我们最终的效果,好我们还是让服务端我们这一块启动成功,我们在这儿来发送上五个测试消息,那有些消息呢,它默认签收,有些消息拒了,那拒了的消息也不会入队,相当于我们也不会重新发送,好我们来测试一下刷新。
25:04
我们来看控制台,控制台呢打印了五个货,有些签收了,有些没签,没签的货也不会重新再发给我们,因为他都没有入对,所以我们来看我们监控到这一块队列里边呢,是零个消息,因为我们不签收,而且让他丢弃了,那就零个消息,所以这是我们说的消费端AC模式,相当于我们要手动的签收货物,手动签收货物呢,我们可以给他ack,我们确认签收了我们消息队列呢,就会将我们这个消息移除掉,我们也可以使用NA或者reject,两个的区别就是上一个可以批掉,但是他们呢,拒绝的时候,我们都可以来指定们拒绝的这个货物是否要退回给商家,True呢?那就是退回给商家,重新发回服务器,重新入队,把货呢重新再发出去,Force呢,就是直接扔掉,我们以服务器呢,也不要了,这是我们可以来调节的,是否重新入队没签收,而且呢,默认就是这样的。
26:05
默认我们如果没有开启手动的AC开,默认是自动AC,消费者一收到消息,我们broker就会将消息移除,默认它是自动AC开,我们可以来说一下,然后呢,即使我们这个队列里边没有消费者,这个消费者呢,这个消息都会存储到队列里边,直到消费者上线就会发给消费者,但只要一有消费者,我们这个消息呢,就会被消费者进行消费,但是消费者既然要消费消息,那你呢,就可以来指定你的这个ack,我是来手动签收模式,那只有我签收了我ack的消息,我们的消息队列才会删除,我们不AC的消息,我们的这个消息队列就不会删除,当我们说的是不AC的情况下,还重新入队,而且如果我们由于程序的bug问题,比如我们执行到这,我们程序中断,我们一直没有调用我们的ack。
27:05
方法相当于我们没有AC,我们没有AC,跟我们这个no AC true这是一样的效果,相当于都是我们告诉他我们这个货物呢,我拒签,只不过下边是明显告诉拒签,这个告诉你我没有AC,我没有签收,你联系不到我的人等等等等,所以呢,无论是我们没签收,或者由于程序bug各种问题,我们一直没有调用我们的签收方法,那只要这些没有被签收的消息一直呢,它都会是on ready状态,就是这个on a状态,这些on AK状态的消息都不会被丢弃,即使我们这个客户端宕机,我们这个服务端能感知到我们这个consumer宕机了,它就会把这个消息重新放为ready状态,Ready状态的消息全部都会被重新投递,这就是我们整个的签收模式,跟我们现实生活中投快递都是一模一样的。
28:04
我们想要将队列里边的内容投给消费者,这就是一个完全的投快递模式,我们可以自己手工的签收,所以在我们后来系统开发里边,我们一定会开启我们手工的签收处理模式,这样就保证我们这个消息,每一个消息都是被我们服务正确处理到,而不是我们这个宕机了,你都给我进行消息丢失。所以我们如何进行手工签收,那就使用我们的这个ack就行了,我们只需要在我们的方法里边调用basic AC,只要你成功处理了,那你就AC,那你没有成功处理你就no AC,或者程序bug直接宕机了,Ack不掉,那也是一样的。好,我们把这块呢复制过来,我们来到这一块,我们的整个模式就是如何签收这个,那就是签收货物,签收货物,然后呢,No easy,就是拒签好。
29:01
这一块呢,就是拒签,拒签。这是签收,这是拒签,只要我们业务逻辑执行成功,业务成功完成,成功完成就应该签收,然后呢,业务失败完成业务这个失败。我们就应该拒签,诶,我们处理失败了,你可以交给别人处理,我们就应该拒签,这是我们说的消费端确认消息的ACK模式,主要是来手动AC,那么只需要配置好,那现在是手动的AC模式,如果没有这个配置,那在那写什么都是百搭的,好我们手动AC1定要加上们这个配置,那在这儿也给大家提示一下,消费端确认一定加上这个配置,好手动签收。这是我们说的消费端的ack消息确认机制,那结合我们消费端的消息确认机制和发送端的消息确认机制,就能最终保证我们消息一定发出去,也一定被人接收到,即使没接收到,我还可以给你进行重新发送,最终达到我们消息百分百不丢失。
我来说两句