063-消费幂等及消息重复场景分析

好，下边呢，我们来看一下啊，这个消息，这个消消费密的啊消费密。呃，首先我们先要看一下什么是消费密度。那么当出现。消费者对某条消息重复消费的情况时。重复消费的结果与消费一次的结果。是相同的。并且多次消费并未对系统业务系统产生任何负面影响。那么这个消费过程。啊，就是消费幂等的。就是啊，为什么说这个是消费没等的呃。这个这个你要想知道啊，他为什么这样定义啊，你就得清楚什么是。这个密的我相信大家啊，都都清楚啊，我在这儿简单的给大家补充一下啊。呃，让不清楚的哥们儿也也呃也了解一下啊行人力的。

就是如果说我们某一个操作。他执行很多次和执行一次。最后对系统产生的影响是一模一样的，就是我执行一遍，我执行多遍。对系统产生影响是一模一样的。那么这个操作就是幂等的，但我们一般说这个幂等是指的什么啊。一般就是写操作，读操作。呃呃，就是我们判断一个操作是否是密等的啊，一般指的是写操作，读操作，呃，几乎上啊，不能也不能绝对几乎上都是密等的。几乎上都是幂等的啊，或者大多数情况下都是幂等的，写操作可不一定，所以我们一般判断的时候就是对写操作判断是否是幂等的。呃，简单写一下啊，呃，若。那么操作啊执行。

多次于。执行一次。呃，对，系统。产生的。影响。那是相同的。则成。该。操作啊是。密等的啊，这密等，所以你知道什么是密等了，再看这个消费密等，那可能就更清楚了，是吧？啊，我我这个消费啊，我我消费者对某个数据的消费，我消费一消费一次和消费多次啊。呃，这个结果对系统产生的这个结果，或者说呃，没有交易多次，没有产生任何的负面影响，那么这个就是我们说消费密等的啊。呃，继续看在互联网里边啊。在网络不稳定的情况下，呃，消息很有可能会出现重复发送或者是重复消费。

如果重复的消息，呃，可能会影响。我们的业务处理，那么就应该对消息做密档处理。就我们这个密等啊，我们这儿讲这个东西干嘛的。就是你要在设计你的系统的时候要注意这个密等处理。所以你看我们下面有什么有解决方案啊，有解决方案。这边咱们举个例子啊，简单举个例子，比如说我们那个支付啊，我们的支付呃，系统。呃，我们的网络不稳定，网络不稳定会导致什么情况？我们扣款消息系统会重复。投递。系统会重复投递。就我这边可能提交了啊，我这边这个已经，呃，已已经已经这个扣款了。

但是他系统没有收到。没有收到他，他会什么再次给你发这个扣款消息。那那这里面就会有一个问题，那那会不会重复扣款呢。肯定不能让他重复扣款的是吧，所以我们的消费者啊，重复消费这个扣款消息。那么你注意他消费肯定是消费了。重复消费，因为你给你投递了，投递你就会消费重复消费的这个扣款消息。但是我们最后扣款的结果是只能扣一次。就是用户扣款记录里边对应的我们的那个订单啊，呃，只有一条我们的扣款的流水。你这样，如果你设计的这个这个支付系统是这样的，那就说明你满足要求了，呃，如果说因为网络的问题，你你你你是吧，EE扣了多次款，那说明你这个系统是不符合要求的。

那么你就需要对这个系统做什么，做这个密的处理。就这个意思啊，就这个意思。这先给大家解释一下。呃，那么我们再看一下这个。这个这个消息啊，重复。我们出现消息重复啊呃，在什么情况下可能会出现消息被重复消费。我们常见的有三种啊，常见的三种。呃，首先说发送。啊，发送消息的时候重复了当一条消息啊呃，已经被成功的发送到broker，并且完成了持久化是吧，成功发送了，已完成了持久化。就写到博里边了，那么这时候出现了什么网络闪段，网络断了？那么这时候就会导致什么啊，导致broker对producer。是吧？就我们生产者应答失败。

如果这时候producer他意识到什么，因为他没有收到。这个。啊呃，发送的这个这个这我收到了啊是吧，这个这个这个应，所以这时候意识到消息发送失败，他认为是失败的。然后他就会什么尝试着再次发送消息。你注意，他是认为这个消息发送失败了，他要尝试再发送消息。这时候他发的消息和上一次发的消息是一模一样的啊，重复发的吗？这个所谓的一模一样，这不仅仅包括消息的内容相同。连什么？Message ID就是我producer产生那个那个ID啊message ID，因为我们在前面说过，大家看。这个message ID啊ID呃，可以由谁producer端能够生成。

是吧，它能够生成啊，就是他这时候他可能啊给我们发送的。这是吧。呃，此时我想调它那个麦来D也有可能都是一模一样的。也可能会会是一模一样啊，然后呢，呃，那么后续这个consumer就就就会呃，就一定会消费两次这个消息，那有哥们儿刚才呃可能会说啊，说老雷你看一下刚才你看的这个东西啊，说丢塞尔端生成的这个消息。呃，生成这个message ID啊，它里边有谁有有这些东西。是吧，这里边儿还有时间。有时间账号自增计数器，那你再发送一次它，它这个麦ID还能相同吗？你注意我刚才给大家一再就强调这个问题。

这是什么？他认为啊，消息发送失败了。它会再次发送，就他认为是失败以后再次发送，所以他会拿到你刚才那个消息的Mac ID，这个就不是再次生成的了，而是刚才发送的那个消息的Mac ID拿过来代发，所以不仅仅内容相同，那你这个Mac ID也是相同的。呃，这这就是，但这个东西发的他会发给谁？发给我们的博ER brokeer里边就会存两条一模一样的消息。你既然消息都存了两条，那我消费者消费的时候肯定就会。消费两次，那当然就重复了，重复消费了，对吧。这是第一个啊，发送消息的时候重复了第二个消费的时候。这个消息重复了。那我们消息啊，已经投递到consumer。

就我已也拿到了，并且完成了业务处理，就是我已经消费过这个消息了啊。当consumer给博克反馈应答时。就你消费成功了，然后我要给broke。反馈应答，那我们前面说过，就是提交那个。呃，那个那个那个叫什么消费记录嘛，是吧，那个offset对吧，提交他。那么。这是网络闪，那ER就没有接收到啊，消费成功的响应。为了保证消息至少被消费一次，这个原则你看我们我们前面刚讲过呀。一次性原则是吧，至少一次原则是吧，相信啊。至少被消费一次。的原则是吧，我们的博将将在网络恢复以后啊，再次尝试投D之前已经被处理过的消息。

那他再次发送过来了，相当于什么？我消费者再次拿到这个消息了，那此时消费者就会收到与之前处理过的内容相同，Mac的ID也相同的消息。那那是不是就重复消费了。对不对，这是第二种情况，第三种情况啊，这个情况，呃，我们前面说过，讲这个re balance的时候啊，我们说过当consumer group里边的consumer数量发生变化的时候。啊，或者是其定义topic的Q数Q数量啊，发生变化的时候会触发什么？Re balance，这是它的两个条件，对吧？那么这时候consumer可能就会。收到什么曾经被消费过的消息，就我们前面给大家就详细的说过啊，当然在这儿可以再给大家说一下是吧，再说一下比如说。

比如说啊啊这这这是我的队列是吧？这我的队列啊呃队列里边，呃，这这里边。先不说这这里Q啊对不对，然后原来啊，呃，消费者是谁消费是是他在消费。是这个消费是吧。啊，这是那个group里边啊，这些考啊。是吧，原来他在消费。啊，他消费了，消费完以后啊，他这个消费，比如说原来消费到哪，消费到这儿了，消费到这儿以后，Offet在这儿呢，然后他又读，读了100条一一次读一批嘛，读了100条啊，我们读过了，读到这儿。老师他在消费的，正在消费的过程里边。正在消费的过程。怎么出现了re？那出现balance有有不客人说那他正在消费的，那我们前面的说re balance他是不分时机的啊，因为你正在消费的过程里面，有可能比如说夸嚓。这哥们儿。

或者是我又增加了一个新的，这是不是都有可能啊？你在这个时候假设他挂。他挂了，马上就重新再分配一分配，这个分给谁了？原来是给他的，现在分给他了。可是他正在消费的还没有提交他这个。呃，消费消费记录。那现在这个已经分给他了，那他要消费从哪开始消费，肯定是从这个worker里边记录的，你之前那个offet从这开始消费。那他会把这100条消息重新再读到这儿，再次消费，那你想想他原来是不是消费过，他等于是又消费了。有哥们说这两个不同的。你不要忘记啊，这是什么，这是一个。这个consumer group。所以。他这个表现出来是一个考啊。也正因为这里边re balance了，大家就就就就更加能体会到啊，更加能体会到什么。

你记不记得我们之前？这个关系一致性的时候。我们还专门给大家说了，你看对应关系一致性，它这个你对应关系里面除了topic tag以外，是不是这个处理逻辑必须要完全一致啊，你要不一致是不是就乱套了。哪乱套了，刚才你re balanceance的时候，原来是他消费的是这种消费方式，换成换了一个consumer了，然换了另一另外一种消费方式了，那不就乱套了吗？对不对？而且大家就应该能够理解了啊。嗯。这是我们说的这个。啊，这这就是呃，我们消息重复的这种这三种最常见的场景啊。