066-消费幂等的实现

好，下边我们来看啊，这个MQ里边是如何实现这个消费密等的。呃，这是又是一个具体的解决方案，那就不仅仅是在这个支付了，是吧，我们看啊，呃，消费力存的解决方案其实很简单，被消息指定不会重复的V标识。这上面说了，因为message ID啊，可能会出现重复的情况，所以真正安全的密处理不建议使用message ID作为处理依据，最好的方式是以什么？以业务为标识为密的处理的。那个观点依据。是吧？啊，也做做做我们的这个这个这个这个关键意义就是我们这个这个密的令牌是吧。而业务的唯一标识可以通过啊。消息T设置。然后呢，这又支付通场景为例，可以为消息key设置什么定牌号，具体的代码，当然这里边像这些东西啊，我们代码应该怎么写，因为我们在第四章啊，呃，要看QQ应用里边会给大家说这个代码的问题啊，现在先简单看一下就行了。

呃，作为密的处理，你看代码里边是这样的，我这message是吧，然后message里边我放的什么，我订单号。是不是我只有订单号，我放到麦姐里边。然后我就把这个producer是把这个message给你发过去了。是吧，然后呢，我这边消费者接收到这个消息以后啊，然后这个。接到接到K为订单号的消息，呃，进行密等。呃，实现密等这个密等处理，你具体的密等处理代码在这儿在这儿完成，大家可以看啊，也简单看一下吧，啊，我这consumer我给他注册了一个什么消息监听器。呃，消息监听器，然后呢，呃，我这里边儿实际上创建了一个监听器啊。

创建个监听器啊，就是匿名内部类是吧，创建一个监听器，呃，这里边设这个回调方法啊，一旦监听到，然后马上就调用这个回调方法，调用这个回调以后，呃，这里边对这个message思是吧，你这你看他。这是什么消息啊，因为我们一次都是消费是不是？一批消息啊，所以我把它读过来。啊，我便利啊，这里便利这个这个所有的消息。然后呢，回到K。回到K，我只要有了这个K了，我就可以根据什么业务为标识K做密的处理，就我我看看我这个处理过没有。怎么处理？这个怎么处理？我有了这个K了，我就可以按照这。到缓存里边查查。

然后缓存没有到数据库里边查查。啊哎，如果这这些呃都没有对吧？哎，那好了，我就可以完成这个这个这个支付了。呃，如果如果这里边是重复的缓存里面直接就查到了，那你这样后边就不再做支付支付支付呗，也就是说具体的业务逻辑在这里边实现的。你只要能获取到就可。就OK了。对不对。嗯，这是我们Q里边啊，这个消费密它是啊如何是，就我们自己写代码，主要你写写哪一块就写这儿。继续这样啊。那么其实我们分析到这儿以后啊，咱们有哥们可能会有这样一个疑问啊，就这个。都看不清啊。这是我在这又务做处理这个MQ，他他为什么不能。本身由Q本身给我们实现。消息驱除。

就我过来的消息，肯定不重复。一定不会是重的。只要存在，存到我博客里边的消息一定不会是重复的消息。那这样的话，我业务写起来不就简单了吗？这个啊呃，能不能做到也是可以的，就我们大家首先要清楚一点啊，清楚一点什么呢？就是我们look q。他能够保证什么？消息不丢失。注意啊，可以保证消息不丢失。但不能。保证啊，我们消息。不重复，我这样写吧。这样的以说明的方式啊。为什么？原因主要有两点，第一个本身肉MQ里边啊，出现这种消息重复的这种概率很低。这首先来说概率很低，那概率低那总有啊。

那能解决呢，能，你如果要想给的去虫，你就得对消息做额外的这种什么，就就是去虫操作需要的啊，你像这个哈希呀，什么order啊等等，而这些操作。他需要消耗大量的系统资源。所以你为了这种这种这种概率很低的这种事件，你消耗大量的系统性能。是得不偿失的。所以。这个从Q这个设计本身来说，诶。这个消息去重，这个呢，就交给你业务。来处理，就我本身的功能上不给你做这个处理了。明白吧？所以这是给大家要做这样一个说明，就是说它本身啊。PU本身不能保证消息不重复。

Okok。那么这样的话啊，我们可以说就把这个消息密档，呃，给大家就。这个这个比较深入全面的，呃。One。