00:00
同学们,Rabbit MQ的其他知识点。都是什么知识点呢?就是我们在企业上班时。MQ在使用的过程当中会出现关于密等性问题。还有优先级队列问题以及惰性队列。到底什么问题呢,咱们一一说一下啊,首先第一个。密等性问题。在使用MQ当中会出现密等性问题。什么叫密等性?用户对同一个操作发起的一次请求或者多次请求的结果是一致的。就不会因为多次点击而产生什么副作用。举个例子,那就是支付。用户购买商品后支付。支付呢,扣款成功。但是呢,返回的结果的时候呢,由于网络异常。此时,钱已经扣了。那么用户再次点击按钮时,此时就会进行第二次扣款。
01:00
返回结果成功,用户查询余额发现多扣钱了,流水记录也变成了两条。在以前单应用服务系统中,我们只需要把数据库作为事务中进行操作即可。发生错误立即回滚。但是呢?在响应客户端的时候呢,也有可能出现网络中中断等等异常问题。哎,这就是幂等性问题。简单一点说,就是重复提交。或者说就是重复的去扣了用户的钱。扣了几次?扣了两次。对吧,所以说真正的情况就是消息被重复消费了。那么我们的消息会不会被重复重复消费呢?会呀,消费者在消费MQ中的消息的时候,MQ已经把消息发给消费者了。消费者呢?在给MQ返回应答说A是应答时,网络中断了。
02:04
所以导致MQ并没有收到确认信息,该条信息会重新发给他的消费者。或者是在网络重连后再次发给该消费者,但实际上该消费者已经成功消费了该条信息,造成了消费者消息的一个重复性消费。所以这就是一个MQ存在的一个重大问题,叫幂等性问题。怎么解决是吧?来说说解决思路。MQ的消费者的密等性。解决,一般使用全局ID。咱怎么使全全局ID啊,就是每次你在做完一次内容时,应该生成一个唯一标识,比如什么时间戳啊,UUID啊,或者是订单,消费者消费MQ中消息,也可以利用MQ的该ID来判断,因为MQ自己不也是有ID吗?
03:05
或者可按照自己的规则生成一个全局唯一ID,每次消费消息时,用该ID先判断该消息是否已经消费过。其实就是加了一个判断,判断此消息是否已经来过了,办法特别的多,什么UUID,什么时间戳是吧。那消费端的密等性是如何保障的?在海量订单生成的这个业务高峰时呢,这个生产端有可能会重复产生消息,这个时候消息端呢,就要实现密等性,这就意味着消费永远不会被消费多次,即使收到了一样的消息,业界主流的密等性操作有两种,一种。叫唯一ID加指纹码机制,利用数据库组件去重。第二种,利用原子性去实现。
04:01
这两种方式呢,分别在这呢?一个叫唯一ID加指纹码机制,什么叫指纹码啊?指纹码就是按照一定的规则,时间戳加上别的服务器给的唯一信息码,它并不一定是我们系统生成的。但是基本上都是由我们系统的业务规则拼接而来。你只要保证唯一性就可以。然后呢,利用查询语句进行判断,这个ID是否已经在数据库中存在了。优势就是实现简单,只需要一个拼接就可以,然后呢查询判断是否重复,劣势呢就是在高并发的时候,如果单个数据库就会。出现写入什么性能瓶颈,当然了也可以采用哦。分工分表的提升,提升性能。这个呢,并不是我们的最佳实验方式,最佳的实验方式应该是第二种,利用原子性,哎,利用red执行set n叉命令,天然就具备那个密等性的一个判断,从而实现了不重复消费。
05:06
所以呢,这解决方案当中的两种当中呢,我们强烈建议是ready是原子性。对,它有原子性操作,所以利用它来完成密等性的校验,哎,这个就是我们在企业上班关于MQ密等性问题的最终。最好的解决方案就是最后一个。中间的方案呢,咱们也不能说没有。只能说最后一个是方案。我们认为是最好。
我来说两句