00:01
接下来我们来说一下rabbit MQ的消息确认机制,什么是消息确认它呢?其实是为了保证我们消息的可靠抵达,那这个可靠抵达来给大家解释一下,在我们这个分布式系统中,比如我们现在有非常多的微服务,微服务呢,连接上我们的消息队列服务器,我们的MQ,然后我们其他的微服务呢,可能还要监听我们这些消息,但是可能会由于我们网络抖动原因,比如我们这个网络突然的闪断,包括呢,我们这个服务器的宕机,MQ的宕机,他的资源耗尽,以及我们无论是发消息的生产者还是收消息的消费者,他们的这个卡顿、宕机等各种问题,都可能导致我们消息的丢失,比如我们这个发送者发消息的时候给弄丢了,我们虽然看起来消息发出去了,MQ网络抖动没接到,或者MQ接到了,他消费消息的时候网络抖动又没拿到等等各种问题。
01:01
所以呢,我们最终在我们分布式系统里边,在一些关键环节,我们都是要一定保证我们消息不丢失,比如我们订单消息发出去,该要扣库存的,该要算积分的,优惠的等等,这些消息千万不能丢一丢,这都是我们经济的问题,所以呢,我们想要保证不丢失,也就是我们说的可靠抵达,无论是我们发消息可靠的抵达到我们的MQ,还是我们收消息MQ的消息可靠抵达到我们的消费端,我们一定要保证消息可靠抵达,包括如果出现错误,我也应该知道哪些消息丢失了,或者怎么着,我们以前呢,想要做这种事情,我们就可以使用一个叫事物消息,比如我们在发消息的时候,我们都知道,我们发消息呢,首先我们一个客户端跟他会建立连接,然后呢,我们会在通道里边来进行发消息,那么可以来设置我们这个通道呢,是事务模式,这样发消息,只有我们整个消息发送过去,MQ消费成功给我们有完。
02:01
等到响应以后,我们这一连串全部做成功,我们才算消息成功,但是我们如果使用事物消息,我们的性能下降的很严重,我们官方文档说性能会下降250倍,那为了保证我们在高并发期间,我们能很快速的来确认我们消息哪些成功,哪些失败,所以我们引入了消息确认机制,那这一块呢,我们完全都可以来参照官方文档,比如我们来参照我们的官方文档,在我们re MQ这个DOS文档里边,专门有一张我们这个server document,我们的服务端文档,它这块里边呢,来往下翻,它有一张叫reliable delivery,也就是我们的可靠投递,那么这个可靠投递来点进来,可靠投递的作用就是说它最终就是为了保证,保证我们这个消息呢,会被经常送达,可靠的送达,即使我们出现了任何错误信息,我们也都能感知到。
03:01
能把它成功送达,所以呢,我们如何来保证可靠送达,那我们现在相当于就是要关注两端,一个是我们发送消息,我们的这个生产者这一端我们的消息发布者,另外一个就是收消息这一端,我们都要保证可靠的能发出去,可靠的可以来收到,那如何来进行保证,我们在下边呢,就来说了,我们可以使用这个机制叫acknowledgement and confors,相当于我们这个消息确认机制,那消息确认机制呢,它就最终可以很高性能的来保证我们的这一块消息可靠抵达,而且想要可靠抵达,其实我们来分析一下,那消息的整个送达流程应该是这样的,首先是我们的生产者,我们生产端我们准备了一个消息,消息呢,先会投递给我们的broker代理,也就是我们装了re MQ的服务器,消息只要投递给我们服务器,服务器收到以后,接下来他肯定得把消息该怎么存怎么存,该投递给哪。
04:01
统递给哪,所以呢,我们这个brokeer收到消息以后将下来,他第一个肯定得把消息交给exchange,然后呢再由exchange送达给我们的Q,所以呢,我们整个发送消息的过程,我们牵扯到两个,第一个是P端到我们B端的过程,我们生产者发送给broke,然后呢,接下来收到以后是我们的一端到Q端的过程,我们的交换机要交给我们整个队列,那在我们整个发送过程中,我们想要可靠抵达,我们要确认每一个消息被成功,所以呢,我们现在就引入了我们发送者的两个确认回调,什么叫确认回调?就是第一个回调时机叫confirm call bank,就是说如果我们P端给brokeer,相当给我们的消息代理,我们的这个服务器只要收到了消息就会回掉,我们的方法叫come call bank。这是我们第一个回调时机,这个时机呢,我们就知道哪些消息抵达服务器了。但这些服务器。
05:06
收到这个消息以后,要。使用exchange交换机最终投递给我们的Q队列,这个队列呢,投递可能也会失败。比如我们指定的路由件有问题了,或者我们这个队列呢,正在使用的时候,被我们一些其他客户端进行删除等各种操作,我们可能呢,都会投递失败,那投递失败呢,我们就会调用这个return call back return call back的触发时机,就是如果我们消息没有投递给队列,我们就会调用我们这个方法。这是一个回调,类似于我们以前写GS代码能发送AJ请求,成功了有success回调,失败了有error回调,那成功以后怎么办?失败以后怎么办?那相当于有两个时机的回调,那这两个时机呢,都是针对于我们发送端publisher,同样的,我们这个消费端只要消息呢安安稳稳的存到了队列里边,接下来就由我们消费端来进行消费了,但消费端进行消费我们又会引入AC机制,将在我们的消息确认机制knowledge,那这个机制呢,就能保证让我们的服务端broke知道哪些消息都被消费者正确的接到了,那如果消费者正确接到我们这个消息呢,就要从队列里边删除,如果没有正确接到,我们可能要把消息呢重新投递等各种操作,所以呢,我们整个可靠抵达分为两端处理,第一个是发送端,它的两种回调确认模式,第二个是消费端。
06:39
它的一个ack机制,那么先来说我们发送端的这两种确认模式。包括我们这个性能下降250倍,包括这一块的所有文档,我们都可以来参照官方文档,比如我们参照我们的publisher,我们这一块呢是我们发布者,发布者这一块呢是如何进行消息确认的,我们可以来看一下,我们来可靠抵达knowledge knowledge里边有一个publish come,相当于我们这个发送者的确认点进来,那么发送者确认呢,下边这一块呢,都说的很清楚,如果我们使用标准的AMQP协议,想要保证我们这个消息isn't lost不丢失,那我们就可以使用这个事物,但这个事物呢,它最终的作用就是让我们整个通道变成一个事物化,然后呢,每一个消息投递期间,它的发布以及提交整个状态呢,都是一个完整的事物,只有事物成功了才算成功,但是我们这个事物在我们这个事例里边,我们这个事物呢,可能将会导致诶decrease就是减少,减少我们吞吐量是一个什么因素呢?250倍,所以呢,官方文档也。
07:45
说的很清楚。如果想要高性能的。可靠投递,那我们就应该引入我们的knowledge,我们消息确认机制,以及我们的publisher com我们的生产端确认机制。那么接下来就先来说我们的这个生产端确认,首先可靠抵达第一个come call bank come call bank的意思就是我们确认回调,这个确认回调我们得知道它的触发时机,他触发时机按照我们这个图就是我们这个生产者把这个消息只要发送给博erer,拿到消息以后,相当于只要他能成功的接收到这个消息,那就是抵达到我们的服务器了。
08:28
所以呢,我这个come call bank,它的这个触发时机是这样子的,就是只要消息被我们broke,我们的消息代理接收到,就会执行我们的come call bank,而且如果是集群模式,我们这个消息呢,就应该被我们整个集群的所有代理都接收到,我们才能调用come call back,但然这个调用类似于我们以前用aja,这是自动回调过来的,所以我们只需要在这里边来感知哪些消息被服务器成功收到了,然后接下来同样的,我们这个被博接收到消息,只能说明我们这个消息呢,在这一步,在这一步抵达到我们这个服务器了,但并不能说明我们消息会被成功的土地保存到我们指定的队列,所以呢,我们上一步的这个毁掉come call bank,它呢,只是表示我们服务器收到了这个消息,而能不能成功的投递到目标的队列里边,要用到我们接下来的这个return call bank。
09:29
Return派的触发时机是我们刚才说的E到Q,这个过程相当于交换机到我们整个队列,只要投递成功了,但才能代表我们消息真正投递成功,但是投递失败了,我们这个return的触发时机是投递失败,就是呢,我们未投递到我们这个Q队列里边的消息,就会触发我们这个,那我们接下来就知道哪些消息真正投递失败了,我们先来看一下我们这个生产端的这个消息确认机制,那先来看第一个come call bank,这个call back呢,我们刚才介绍了,如果我们想要使用,我们必须来做一个设置,首先我们来配置配置文件,我们来开启它的这个发送者确认模式,必须开启这个模式,如果我们是编码,我们就只需要来在它的连接里边设置上我们这个模式开启触就行了,但是spring boot什么都给我们自动配置好了,你们想要用,只需要在配置文件中好来写一个spring,点一个publish,我们这个publish。
10:29
是come,它呢默认是一个first,所以呢,现在可以给他来写一个true,那这一块的作用就是我们开启我们这个发送者确认发送端我们这个确认,那么这个发送端确认我们来开启以后,那如何使发送端能真正确认呢?接下来我们就来得编写一个我们叫come。Call bank come call bank这个我们可以来看一下,我们control n来找一下这个类come call bank,这个come call bank呢,其实是在rabbit templatet,在这个里边的,在这个里边我们只要配置好我们这个。
11:08
确认回调,那哪些消息发送完成了,那就会回调进来,回调进来呢会有几个参数,第一个参数是我们当前这个消息的,我们叫Co relation,就是我们消息的关联标识,其实这个就是我们后来说的每一个消息的唯一ID,然后接下来ack表示我们这个消息有没有被正确的收到,True就是正确收到,False就是我们这个没有被正确收到,还有我们这个course Co就是如果没有被正确收到,那出现了什么异常,那么就是异常的各种原因在这呢都会有提示,咱们想要使用这个confirm call back,那么就必须在我们rabbit tempt里边来,可以看一下control home,在rabbit tempt里边呢,专门会有我们的这个come call back,就是这个,那这个confirm call back呢,我们就可以来自己设置保存进来,我们就可以使用了,所以我们现在呢,为了使用我们这个confirm call back,我们可以来定制我们的。
12:08
Rabbit来定制我们的rabbit。那么rabbit temp既然已经自动放到容器中了,那们接下来把它从容器中我们就自动注入,我们先来自动注入我们的rabbit tempt,然后接下来我们对它来做一个定制操作,怎么定制呢?由于我们这是一个配置类,所以呢我们可以给配置类上随便来写一个方法,我们就叫word,叫unit rabbit table,那来初始化我们rabbit的这个模板,那这个初始化就是我们来对它做一个定制,比如它里边我们可以来set come call back来设置一个确认回调,好,我在这来设置确认回调,那这个确认回调该怎么设置,我点进来它需要传一个confirm call back,这个confirm call back,它是rabbit temp里边的这个接口,接下来直接来创建它一个实现就行了。好,我现在来new,一个叫come call back,这个come call back一定是rabbit table里边的这个come call back。
13:15
好,创建了一个,它相当于我们给它里边设置了一个消息确认回调,但是呢,我们为了让这个方法能生效,来添加上一个注解,叫post construct post construct的意思就是在我们这个conf配置文件,它整个呢,相当于对象创建完构造器construct,这不就是构造器吗?我们这个构造器创建完,对象创建完以后再来调用这个方法,相当于就是我们这个configuration,我们的这个config对象创建完成,对象创建完成以后,哎,我们构造器调用以后,然后呢,执行这个方法,这个方法呢,那就是来。设置我们的rabbit templt,我们先设置了一个come call back,我们确认回调,我们在确认回调里边,我来输出一下this out,我们这个c out呢,我们就叫con,我们的消息确认,消息确认里边接下来第一个参数叫correlation data,这个correlation data们来说一下这个后来是我们这个翻译过来。
14:20
这叫我们这个关联的数据,我们当前消息的当前消息的唯一关联数据,所谓的这个唯一关联数据来点进来correlation data这里面呢,其实主要就是有一个ID,所以每一个消息呢,发送的时候可以给一个唯一ID,我就认为这个是消息的唯一ID,我们发消息的时候可以用UUID来作为唯一ID就行了,包括这个ACKAAC呢,代表我们这个消息是否成功还是失败,消息是否成功收到,然后还有我们这个cos,如果是失败的原因,我们就在这会有,然后我们接下来就来打印一下,来打印第一个correlation data,这个data是什么,我们先来打印一下这个data,好把这个呢打过来,然后呢,接下来还有它的这个ack,我们返回到这个ack,内容是什么,我们来也打印一下。
15:20
好,我们把这个消息呢来打印一下,那接下来我们继续我们的这个cos是什么?好,我们把这个courses我们也来打印一下,走,我们来打印一下我们的cos,好,也就是说我们只要消息我们的MQ,我们的代理收到,那这个方法就会自动回调,那现在配置好了,主要呢,想要用到我们这个发送者确认,发送端确认两步,第一步先来配置它发送端确认,第二步给rabbit他的里边来放一个我们这个确认回调就行了,两步,第一步是它,第二步来。设置我们的确认回调,设置好以后,只要消息发出去,我们服务端收到,就会触发这个确认回调,来重新启动一下我们这个order服务来测试一下,还是一样,我们来调用这个send的MQ发消息的方法们来看,消息成功被收到以后,我们的确认回调会不会执行好,我们在这来进行一个发送,来等待一下我们这个服务启动成功,好们这一块呢,服务启动成功来点进来,我们现在调用它的controltr了,我们来发一个消息send到MQ走,那消息这一块呢,发OK了,们来看,除过我们自己接到这些消息外,我们这些confirm回调也被触发了,这个回调呢,A c true,只要是true,那就代表我们消息被服务端确认收到了,那么这个消息有没有被消费,跟我们这个true false有没有关系?假设呢,没有被消费,我们把这个消息的消费我们去掉,我们来到a service里边,我来不来。
17:00
监听我们这个消息队列,我们把这个消费消息我们来去掉,我们去掉以后呢,我们来看是不是我们还会依然触发,好,我们来重新来启动走,好我们服务启动完成,我们控制台清空,来重新来发送,那现在呢,没有人来监听消息了,我们来直接来发送走,那这个消息发送成功了,包括在我们的MQ里边,这个里边呢,应该会有十个消息,那我们来看一下我们的控制台,我发现呢,控制台ack还是处,所以呢,只要我们这个消息能正确的抵达我们这个服务器,我们的这个回调那就会是触好,所以我们这一块来提示一下,只要消息抵达服务器,只要消息抵达我们的服务器,也就是我们的broker代理抵达我们的代理就AC等于处好,这是我们说的确认回调,但是这是确认回调的第一个时机,就是消息,现在呢,确定已经抵达了我们这个服务器。
18:00
加第二个时机,服务器还要将消息投递给我们这个队列,由交换机最终抵达队列,那只要队列抵达失败,我们还会触发我们这个回调,所以我们接下来再来测试第二个,这是我们第一个我们的确认回调,我们这个服务器收到消息,收到消息,收到消息就回调,就回调呢,我们就是来做这两步,这两步的确认回调,我们这个确认回调主要是这个come call bank,接下来第二个我们消息正确抵达队列,消息正确抵达队列进行回调。那这个进行回调呢,我们想要做这个怎么做还是一样,我们这个呢,现在它的这个时机是交换机把消息抵达给队列,这个队列投递有可能会失败,如们路由件写错了,那肯定就失败了,包括我们在集群模式下,集群模式下我们这个消息想要投递给队列,由于我们这个MQ它是一个镜像集群,相当于每一个节点都跟我们这个主节点数据呢是同步的复制模式,所以我们相当于要投递队列,每一个队列都得投递成功才行,所以我们只要有一个队列投递不成功,那应该也是失败的,所以我们这个时候呢,都可以来触发我们的return call bank,那么来看一下return call bank该怎么设置,那前一个呢,设置了confirm call bank,那想要设置return call bank一样的,那首先呢得设置publish returns,比如说我们发送端的这个确认,那么这个返回确认我们来到这儿,那之前设置了一个我们发送者端。
19:40
确认,也就说只要brokeer收到消息,我们就确认,再来整一个叫publish,我们发现呢,这还有一个叫returns,叫returns呢,默认也是false,来给它给一个处,这个处呢,那就是开启我们这个还是发送端确认,开启我们这个发送端消息正抵达队列确认的咱们这个确认,那这个确认我们来设置好以后,我们接下来再来设置上一项,我们这一项呢,Rabbit permanent mandatory,这个mandatory我们把它给它也设置成处,这个设置处乘处呢比较非常有必要,就是如果我们抵达了这个队列,那就会优先给我们执行这个回调,而且是以异步的模式,所以我们经常会把它设置为处,只要抵达队列,抵达队列,然后呢,以异步模式,以异步方式优先回调,优先咱们这个回调。
20:40
我们这个return确认好,我们叫return康好,所以呢,接下来我们想要做我们这个队列的抵达确认,我们可以来设置这两项,当然下面这一项不设置也行,我把这个复制过来,那么接下来继续,我们之前呢,做了一个服务端,收到消息就回调,接下来我们要做这个,做这个呢,首先配置这两项,第一项是我们的这个publish returns处,第二项是我们的这个mandatorary处,然后接下来第二个我们再在rabbit temp里边再来设置我们的第二处确认毁掉,来我们这个设置我们这个消息抵达队列,消息抵达队列的确认回调。
21:27
好,这个抵达队列的确认回调,我们在这呢也设置一下rabbit tempt点一个,它有一个叫set return call back,所以我们自己来再创建一个return call back点进来,它需要什么我们就来放什么,那么在这里边呢,来new一个return call back,好,还是我们rabbit temp里边的这个接口,Return call back里边它会有这么一个方法叫return的message,我们在这儿来打印,而且注意这个方法的触发时机,你正确的抵达队列了,我们不会回调,如果我们有哪些消息没有送达给指定的队列,我们这个方法才会毁掉。所以呢,只要我们这个消息,我们在这一块的触发时机,这一块的触发时机就是只要消息没有投递给指定的队列就触发,这个类似于失败毁掉。
22:28
好,那我们回调的这几个参数,第一个message message就是代表我们是把哪个消息投递失败了,哪个消息投递失败了,消息的详细内容,哪个投递失败的消息,投递失败的消息。详细信息,那第二个reply code的,那就是我们回复的这个状态码,回复的状态码回复码,然后呢,接下来还有一个叫rely task,我们这个回复的文本内容,哎,这都是我们服务端给我们回复的文本内容。
23:04
文本内容,那接下来还有exchange,那么这个相当于消息是发给哪个交换机的,当时这个消息,这个消息发给哪个交换机,然后呢,最后还有一个我们就是我们的这个ROK,当时这个消息发送的时候指定哪个路由件,当时这个消息用哪个路由件,用哪个路由件,所以我们会发现这个消息呢,投递成功,不会触发,来给大家测试一下。我们这个file message,我们就将失败的消息,这个消息内容呢,我们来给大家打印一下,那就是我们的这个message,然后呢,接下来我们回复的这个码,以及这些内容我们都来打印一下走,还有一个reply code这一块的内容,我们也来打印一下,再加上我们的这个exchange,我们当时发给哪个交换机,我们也来打印一下,以及我们当时发送的时候用的这个RO key路由件是哪个,我们也来纸打印一下走。
24:13
好,我们现在呢,还是不让人去来消费消息,这样控制台呢,就不打印那么乱了,那现在来确认一下,我来重新来启动我们这个服务来发消息,我们看这一块呢,有没有打印我们失败的消息。我们在这来测试一下,好,那先来确认一下我们的这一块消息,现在呢有十个,我们来准备再来发十个消息,来等服务端启动成功,好,我们这个订单服务呢,现在启动成功,们来测试一下我们发送端确认的回调的第二种方式,好,我们来看一下,我来发送上十个消息,走消息呢投递OK,我们来看控制台打印,控制台呢全部打印了康,相当于服务端都收到了,但是呢,这一块没有打印,没有打印我们的这个return message,因为这个呢,我们说这是投递到队列失败的时候才会打印,所以我们想怎么样会失败,那我们最简单的一种失败方式,那就是投递的时候我们路由件指的不对,比如我们进来测试一下,那在发消息的时候,CTRL来发消息的时候,如果对二求鱼,我们让下边的这个路由件,我们不对,好,我们就叫HELLO22,好,我们现在来测试一下,走们来看此时发的这个消息对不对,只要消息不对。
25:29
我们能不能达到我们这个回调,我们这个回调这一块呢,会不会有打印好,我们这个启动成功,那现在重新来发消息,现在这里边呢,已经有20个消息了,那现在来重新发送,发送好,发送成功以后,我们来看我们的这一块康复,我们确认的这些消息呢,都成功了,但是有几个失败的,我们fair message,我们失败的第一个是我们order SN这几个,然后呢,我们来看一下失败的这些信息,首先我们的失败消息,我们的body这一块信息呢都有,包括他失败当时用的这个消息的头信息肯定也都有,来往下翻来看一下他的这些,诶,Content type这都是我们的message properties这些属性图信息也有,然后呢,我们再来看其他的这几个,我们回复的这个状态码312,然后呢,再接下来我们的发给哪个交换机是这个交换机,然后呢,路由件我们用的是这个,现在我们明确的知道了哪个。
26:29
Do投递失败了,发给的交换机是什么?路由件是什么,以及我们回复的这个状态码是什么,我们回复的这个文本内容有没有打印呢?来看一下reply test这个code这一块呢,打印了,但是reply test呢,没打印,因为我们这一块没有加上它,好,我们可以来加上它,再来看一下这个rely test,这是什么东西?好,Rely test。我们来看一下,如果投递失败,他给我们返回的这个文本内容,这是一个什么信息,好,我们现在来重新启动一下这一块,比方说我们现在能看到我们两种调用时机,第一个只要服务端收到消息,我们就会调用我们的这个confirm,回调我们这个confirm,然后接下来只要我们这个消息抵达我们队列,相当于正确抵达,我们就什么不调用,没有抵达队列,我们就会调用我们的这个return的message,那这个毁掉,那现在还是来清空控制台,来重新测试一下。
27:29
好,我再来刷新,那现在呢,把消息全部都发出去了,有一些消息抵达失败,来看一下他回复的我们这一块文本内容,诶文本内容就是no root,没有这个路由,相当于我们312这个错误呢,对应的就是没有此路由信息,所以我们现在呢就能收到我们的这两种回调,而这个回调里边呢,在这一块我们的设置确认回调这一块呢,有一个东西大家要注意一下,就是这个correlation data,这个correlation data里边,它主要我们说这是消息的唯一ID,但这个唯一ID从哪来?应该在这我们第一次来发消息的时候,我们看到我们发消息啊,除了来指定我们要发的消息,我们还可以来传第四个参数,如我来第四个参数,我来写一个,那那这第四个参数是一个什么参数,我先来写一个,那我们来看一下,那第四个参数我们就可以是一个col data。
28:30
所以呢,我们接下来就来用第四个参数来创建一个Co relation data,这个data的值呢,比如我们就用UU id.random u u ID点一个to string,好,这代表我们消息的唯一ID,我把这个呢,复制过来,CTRLC,我们来创建它这个构造器呢,直接能传一个string,这个string就是我们消息的ID,所以我们每发一个消息来指定这个消息的唯一ID是什么?这样呢,我们在这确认的时候,我们就知道到底是哪个消息服务端收到了,现在我们收收到了消息的ID,现在我们来测试一下,走来重新启动,走好,我们这个服务呢启动成功,那接下来再来发消息,看我们服务端确认收到消息以后,我们每一个消息的ID能不能打印到来刷新。
29:18
好,我们现在呢,服务端都收到了这些消息,好,每一个confirm,我们这个消息这一块data的内容,我们这儿没打印,没打印的原因,我们之前把这个唯一ID写到这个测试类里边了,没写到controlrler里边。好,我们发消息的时候呢,都可以来指定消息的唯一ID,有一个cor relation data,好,我们这个唯一ID我们就来用UUID来表示,U u ID random导我们u u ID to string。好,下边的也一样,我们发消息给他来指定call relation data,那就是UUID,有些同学说我们这随便指定一个UID,我们最终咋知道我们这个服务端收到的是哪个消息呢?其实我们就可以在发消息的时候,除了把消息发给我们的MQ消息服务器外,我们还可以把这个消息呢保存到我们的MYS库数据库里边,想每一个唯一ID对应此消息,如果我们服务端收到了这个消息。
30:18
那么就在数据库里边说一下,我们这个消息已经被收到了,我们想要知道哪些消息没收到,我们就去遍利数据库看哪些消息的状态是没收到状态,当然后边我们会说我们这个本地事物表的方式来保证我们最终的消息是可靠抵达,我们这一块呢,只是给一个消息的唯一ID,那现在再来做一个确认,走好,接下来我们服务启动成功,那现在重新再来发一些消息,走,现在消息呢,都发出去了,我们来看每一个con的这个数据,它的这个ID唯一ID,那就是我们当时指定的,那这些消息呢,就有唯一ID了,那以后我们就如果关联了数据库,我们就能明显的知道哪些数据,像这些消息才是真正的被我们re MQ服务器已经确认收到的消息。
31:09
那相当于可靠的已经抵达了,如果没有可靠抵达,比如我们数据库里边记录了每一个消息ID对应的状态以及它的内容,我们可以定时扫描一下数据库哪些消息没有可靠送达,我们给他重新再来投递一次,那这是我们说的我们消息确认机制里边的发送端确认,因为我们发送端为了可靠的确认我们每一个消息是确认抵达了,而且呢,可靠的投递到队列里边呢,我们可以有两个回调,这两个回调想要使用,你就必须来设置这些参数,好我把这两个回调呢放在这,这都是我们说的发送端确认,好,我们再来设置确认回调,那前两个都是我们发送端确认,那下节课我们就来可以再来说一下这个消费端确认,那消费端要确认每一个消息被成功消费,因为消息只要一消费以后就会从我们队列里边移除,如果我们都没有成功消费。
32:03
假设我们现在re MQ服务器把消息呢,他发出去了,他认为他发给我们的这个消费者了,但由于网络闪弹等各种原因,我们消费者确实没收到,那这个消息不就又丢失了吗?所以我们接下来再来开启消费端确认机制,就来保证每一个消息都能被正确消费,只有被正确消费了,我才可以删除,所以它的作用,消费端确认就是为了来保证每一个消息,保证每一个消息被正确消费,然后呢,此时才可以broke删除这个消息,Broker删除这个消息,因为只要我们消费了的消息,我们都要进行删除的,那么下一个再来说这个消费端确认。
我来说两句