00:00
同学们,我们已经写完了,谁呢?写完了这个新的优化啊,延迟优化,优化了一个QC,并且把生产者也写完了,消费者不需要写是吧?不需要写,所以我们接下来启动服务器进行测试。测试呢,你就发送这个请求了,那么我们文档上呢,也给提供了,提供了这个测试的这个结果是吧,你看让我们发送两波请求,第一波呢,发送一个你好一。发生的时长为20秒,对,因为单位是毫秒的嘛,20秒下一个呢是发两秒,名字叫你好二,对你好二,所以呢,这个呢,就是我们发的内容当中看一看。能不能达到,他要20秒接到你好一是吧,他是两秒就接收到好二能不能达到我们预期的效果呢?来一起来试一下。首先将服务器重启。代码只要改了,你就要重启服务器啊。
01:02
所以重启了。诶,写好了,没有报任何错误,所以呢,咱们就把这个日志清掉,一会儿要通过控制台进行打印查看效果,来,我们把这两个链接粘一波。首先走第一波链接。走第一波链接是吧,来了啊,走第一波链接之后发送个你好一。对吧。发。发完了再粘第二波链接发个你好二注意是两秒的,谁先到啊。应该是两秒的先到是吧,那咱看一下是不是这样的。这呢?发送了一个你好一发送了个你好二,你好一用20秒。对吧,这个是两秒,按照这个情况。应该什么,应该谁先到,你好二先到,因为你好二不是两秒钟吗?对吧,那两秒先到。完了呢,20毫秒后到,但是结果。
02:02
令我们大失所望。为什么大失所望呢?因为你好,一你看用时多久啊,这个是这个30和51。之间差距21秒,注意腰不要太计较这个事情,因为他毕竟程序嘛,发的时候他略微会有那么一个一秒的一个差距,所以差21秒,对不对呢?确实是对,就是20秒,因为程序在运转的时候可能会浪费一秒钟。所以就有一个误差。你要是可以频繁的发两遍就会这个误差就没用了,那么这个就证明是20秒,确实是20秒,但是我不理解的就是你好二,明明是两秒后就得来吧。那为什么它也是21秒呢?所以我们的延迟消息优化了吗?优化了首先可以这么说,你讲多久,你想多久就多久,哎,你想几多秒就多少,你想几秒就几秒。
03:02
已经能达到想多少秒是多少秒了,但是不好在哪呢?一旦发送两条以上信息时,你会发现它什么呢?它是排队的。延迟消息竟然排队有先来后到,谁先来的?你好,一先来的。你好,二是后来的。你好,一是多少,是20秒,那你好,二明明是两秒。对吧,明明是两秒,但是竟然按谁走了,按你好一走。也就是说,以第一条信息时间为准。第一条信息如果不发出去,第二条信息是不发出去的。所以导致第二条信息明明比第一条时间短两秒就过来,但是竟然按照谁走了,按照第一个。消息的时间走了,所以这就是一个死信,在做延迟的时候一个巨大的缺陷。来说一说缺陷。
04:00
这呢啊,他这个文档上的案例呢,也是这个意思,你看你好一二十秒,但是呢,对吧,但是呢,怎么的,但是发现你好二后来的,因为你好二是两秒钟也是按顺序走,也有这个问题。那么这呢,你看看起来似乎没有什么问题,但是在最开始的时候就介绍过,如果使用消息属性上设置TTS的方式,消息可能并不会按时什么的死亡。谁不按时了?肖你好,二没有按时。你好,二按的时间应该是两秒,但是很可惜是按照20秒第一条数据走的。所以因为什么?因为MQ只会检测第一个消息是否过期。如果过期,则丢到死信队列。那么如果第一条信息延迟时间很长,而第二条信息延迟时间很短,那么。第二条信息并不会优先得到执行。
05:01
他会以第一条信息执行完之后才会执行第二条。所以导致第二条时间短的反倒比时间长的执行的还要慢。对,因为他会检测,它只会检测第一条信息是否过期,它不会检测第二条信息是否过期,所以这就是。用死信队列做延迟的时候,有这么一个巨大的缺陷。就是当。消息特别多的时候。只以只以第一个消息为准,不以第二个。消息为准。所以造成了第二个消息。时间是不正确的。那么这个缺陷怎么得到弥补呢?只能接下来通过MQ的叫插件实现延迟队列来进行弥补啊,没办法,上面这个死基于死信呢,就没办法弥补,就就存在这问题啊。
06:01
没办法弥补,因为就存在这个问题,那么要想解决这个问题,只能提后续内容了。
我来说两句