博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
消息队列如何保证幂等性?
阅读量:5745 次
发布时间:2019-06-18

本文共 984 字,大约阅读时间需要 3 分钟。

面试官心理剖析: 主要是看你对消息队列数据重复消费的问题,是否有了解,是否知道怎么解决?如果这块不知道,那么面试官会觉得如果交给你做功能,可能会出现多次消费的情况。

回答:

为什么会出现重复消费? 分析: imagepng 如图,在什么场景会出现消息重复消费?比如说消费端已经消费了 offset=2,offset=3,offset=4 的三条数据,正准备把这个 offset 的值传给 kafka,这时候消费端机器宕机了,这个数据没传过去;重启之后,消费端同步 kafka,kafka 那边消费的记录 offset 还是 1,那么 kafka 会认为之前的 2、3、4 都没有消费过,会把这几个数据在传给消费端;这样消费端这边就重复对这几条数据进行消费了。在数据库里面可能就多了很多重复的数据。 像其他的 MQ,也是一样,消费端再返回给 MQ 的时候,当机了或者重启了,那么都会出现重复消费的问题。

问题解决:

幂等性:一个请求,不管重复来多少次,结果是不会改变的。

每个消息都会有唯一的消息 id。 1)、先查再保存 每次保存数据的时候,都先查一下,如果数据存在了那么就不保存。这个情况是并发不高的情况。

2)、业务表添加约束条件 如果你的数据库将来都不会分库分表,那么可以在业务表字段加上唯一约束条件(UNIQUE),这样相同的数据就不会保存为多份。

3)、添加消息表 再数据库里面,添加一张消息消费记录表,表字段加上唯一约束条件(UNIQUE),消费完之后就往表里插入一条数据。因为加了唯一约束条件,第二次保存的时候,mysql 就会报错,就插入不进去;通过数据库可以限制重复消费。

4)、使用 redis 如果你的系统是分布式的,又做了分库分表,那么可以使用 redis 来做记录,把消息 id 存在 redis 里,下次再有重复消息 id 在消费的时候,如果发现 redis 里面有了就不能进行消费。

5)、高并发下 如果你的系统并发很高,那么可以使用 redis 或者 zookeeper 的分布式对消息 id 加锁,然后使用上面的几个方法进行幂等性控制。

链接:https://hacpai.com/article/1542160729029
来源:黑客派

转载于:https://www.cnblogs.com/UncleWang001/p/10606388.html

你可能感兴趣的文章
开启“无线网络”,提示:请启动windows零配置wzc服务
查看>>
【SDN】Openflow协议中对LLDP算法的理解--如何判断非OF区域的存在
查看>>
纯DIV+CSS简单实现Tab选项卡左右切换效果
查看>>
栈(一)
查看>>
姑娘你大胆地往前走——答大二学生XCL之八问
查看>>
UVA196
查看>>
ios 自定义delegate(一)
查看>>
创建美国地区的appleId
查看>>
例题10-2 UVa12169 Disgruntled Judge(拓展欧几里德)
查看>>
[c语言]c语言中的内存分配[转]
查看>>
JS 原生ajax写法
查看>>
day 10 字符编码和文件处理 细节整理
查看>>
如何打造亚秒级加载的网页1——前端性能
查看>>
「陶哲軒實分析」 習題 3.5.9
查看>>
在首次发布三周之后,MLflow迎来了0.2版本
查看>>
聊天宝彻底凉了,遭罗永浩抛弃,团队就地解散
查看>>
Composer管理PHP依赖关系
查看>>
React.js学习笔记之JSX解读
查看>>
WebPack1.x 常用功能介绍
查看>>
我所了解的Libevent和SEDA架构
查看>>