Java岗大厂面试百日冲刺 - 日积月累，每日三题【Day34】—— 消息队列2

最新推荐文章于 2024-11-09 12:43:52 发布

2401_84413490

最新推荐文章于 2024-11-09 12:43:52 发布

阅读量607

点赞数 9

分类专栏：程序员文章标签： java 面试 linq

本文链接：https://blog.csdn.net/2401_84413490/article/details/137935705

版权

程序员专栏收录该内容

95 篇文章 0 订阅

订阅专栏

本文讨论了RabbitMQ、Kafka和RocketMQ中消息重复消费的问题，重点介绍了如何通过偏移量、幂等性原则以及队列设计来保证消息消费的顺序和避免数据不一致。文章还涉及MySQL中的插入策略和使用Redis实现幂等性方法。

摘要由CSDN通过智能技术生成

RabbitMQ、RocketMQ、Kafka，都有可能会出现消息重复消费的问题。因为这问题通常不是 MQ 自己保证的，而是消费方自己来保证的。

比如说Kafka，他实际上有个 offset 的概念（偏移量），就是每个消息写进去，都有一个 offset，代表消息的序号，然后 consumer 消费了数据之后，每隔一段时间（定时定期），会把自己消费过的消息的 offset 提交一下。代表我已经消费过了，就算消费者重启，Kafka也会让消费者继上次消费到的offset继续消费。

场景示例：

kafka 中有一条数据：A、B，kafka给这条数据分一个 offset（偏移量），offset为： 1001、1002。消费者从 kafka 去消费的时候，也是按照这个顺序去消费。当消费者消费到 offset=1002 的这条数据（此时offset=1001还没消费完），刚提交 offset=1002 到 zookeeper，消费者进程就被重启了。此时消费过的数据 A 的 offset 还没有提交，kafka 也就不知道消费者已经消费了1001这条数据。那么重启之后，消费者会找 Kafka 把上次消费到的那个地方后面的数据继续传递过来。数据 A 再次被消费。

在这里插入图片描述

如果消费者是拿到一条数据就往数据库里写一条，就会导致把数据 A 在数据库里插入了 2 次，导致数据不一致。重复消费其实并不可怕，可怕的是你没考虑到重复消费时，怎么保证幂等性。

追问1：如何保证消息不被重复消费？如何实现幂等性？

幂等性，比如一个数据或者一个请求，给后台重复发多次，针对这类情况，你得确保对应的数据结果是不会改变的，不能因为发了多个相同请求导致数据出错。

怎么保证消息队列消费的幂等性？

比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update就行。对了，ES的插入接口是不是就采用了插入并更新的策略？发现相同的数据就直接更新他。
如果是写 Redis，那没问题，反正每次都是set，天然幂等性。
比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的 id，类似订单 id 之类的东西，然后你这里消费到了之后，先根据这个 id 去 Redis 里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个 id 写进Redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。
比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了，重复数据插入只会报错，不会导致数据库中出现脏数据。（类似于第一条，可以通过修改SQL，转成插入或更新的策略）

MySQL中的插入或替换、插入或更新、插入或忽略策略，详情可参考《MySQL中特别实用的几种SQL语句送给大家》

在这里插入图片描述

课间休息，看看 广州城中村一角。

面试题2：RabbitMQ如何保证消息的顺序性

======================================================================================

消息队列中的若干消息如果是对同一个数据进行操作，这些操作又具有先后关系，必须按顺序执行，否则可能会造成数据错误。

比如有三个请求，是对数据库中的同一条数据进行了插入->更新->删除操作，执行顺序必须保证，如果变成删除->更新->插入就很可笑了，造成最终数据不一致。

顺序错乱的场景：

一个queue，有多个consumer去消费，这样就会造成顺序的错误，consumer从MQ里面读取数据是有序的，但是每个consumer的执行时间是不固定的，无法保证先读到消息的consumer一定先执行完操作，这样就会出现消息并没有按照顺序执行，造成数据顺序错误。

rabbitmq如何保证消息的消费顺序

将原来的一个queue拆分成多个queue，每个queue都有一个自己的consumer。该种方案的核心是生产者在投递消息的时候根据业务数据关键值（例如订单ID哈希值对订单队列数取模）来将需要保证先后顺序的同一类数据（同一个订单的数据）发送到同一个queue当中，让同一个consumer来按顺序处理。

在这里插入图片描述

图片取自中华石杉架构课件

一个queue就一个consumer，在consumer中维护多个内存队列，根据业务数据关键值（例如订单ID哈希值对内存队列数取模）将消息加入到不同的内存队列中，然后多个真正负责处理消息的线程去各自对应的内存队列当中获取消息进行消费。

在这里插入图片描述

图片取自中华石杉架构课件

RabbitMQ保证消息顺序性总结：

核心思路就是根据业务数据关键值划分成多个消息集合，而且每个消息集合中的消息数据都是有序的，每个消息集合有自己独立的一个consumer。多个消息集合的存在保证了消息消费的效率，每个有序的消息集合对应单个的consumer也保证了消息消费时的有序性。也就是保证了生产者 - MQServer - 消费者是一对一对一的关系。

在这里插入图片描述