68_高级特性之防止重复调用

好，那么各位同学，那接下来我们来看一下重复消费的问题，以及密等性调用好那么首先哈，说穿了，呃，这个问题干嘛呢？大家不要被吓到，妹妹一听名字就说说消息啊，或者接口调用什么密等性。哎哟，把你吓的，我跟你讲哈，这些现在就是有些面试官啊，就是喜欢是装逼，那么我们就这么说啊，你这个东西其实大家也接触过，说难听点就是。之前我们学习什么外部。框架阶段的什么东东繁殖？表单重复提交，只不过现在这个表单变成了什么，变成了我们的消息。OK。那么言下之夜就是。不要重复调用，或者说我只要调用过以后，我每次都要一样，那么首先哈，我们呢来看看。

低点。由于网络延时卡顿，这些会造成进行MQ的重试过程当中，在重试过程当中有可能造成重复消费，那么怎么解决？一般我们认为有两种，但是推荐用第二种，但是第一种也了解一下第一个。如果是要把这些消息是做数据库的什么操作插入，那么坦白讲就是说不要重复，不要重复，那么大哥有了。就说明什么消费过一次啊，没有是不是说明没有那么好，有了什么意思啊，有了只要是数据库里面是不是主键就会有一条，那么这个时候如果主键冲突了，那么这个时候是不是一定挂，那么比如说我们消息中间键你懂的哈。是不是有个message idea这种东西，如果在数据库里面的某张表已经有了，你要再去插一次，是不是会报错。那么所以说我们这。干嘛？给这个消息做一个唯一主见，那么就算重复出现重复的消费就会导致什么冲突啊，主键冲突啊，避免数据库啊，出现了什么脏数据，这是第一种往数据库里面第二种。

干嘛，如果上述的这两种情况哈，当然还有一种呢，也不推荐。那种情况是用token啊什么的，我就不想写了，好，那么这种情况下呢，干嘛呢，我们呢直接准备一个第三方来做消息服务，那么这个就是什么red，那么大家都明白，我们现在是不是可以给red这set k1V1那个value无所谓，只要这个key假设这个已经有了消费过，我们就存进去，将ID干嘛？Message以KV的形式写入数据库，那么消费者开始消费之前，我就先去ready中查询一下有没有消费记录，有了说明消费过没有，不消费听懂，那么注意ID message什么意思呢？回顾我们以前讲的这个异步投递签收，大家还记不记得那个时候杨哥是不是说过，这个对每一个消息而言，他可以set GS message ID，那么言下之意，这个message ID什么可以给我们人工整一个，那么这个值是哪一个有点类似于哈，假设发送完了。

每一个消息是不是都会有这么一个值啊，同学们，没问题吧，我们这儿粗略的简单的说一下哈，那么假设哈，我们把它。取和消费的时候先去ready去查一下，那么这个时候我们这个red.set那么假设我们要ID和message，那么这个时候我们怎么写呢？那么这个set，那么假设这个ID，那么是不是就可以是我们的这么一个东东，那message是不是我们的UUID。这么说兄弟们能不能跟上，那么言下，当然你可以反过来哈，比方说这个T就是我们自己要设置一个唯一区别的标识号，你怎么干都可以，那么在调用或者处理之前，我们就要先去red去查一下。有了那么这个。说明消费过没有说明可以消费，OK，就这么简单，那么所以说不要被他面试官呢，干嘛吓到哦，有密等性问题，你谈谈一听，这个密等线说穿了就是解决重复消费，那么现在。

我们扔到里面，因为比较快，查一次有了消费过没有。可以消费，那么无非就是多一次查询和判断，那么整一个全局ID以这么一个ID message的形式写入来进行使用，之前来进行一些排查，ID message哈，OK，那么来决定它重复与否，好，那么同学们大家辛苦了，我们下课休息吧。