医疗器械查询官网,南京网络推广优化哪家好,微信文章采集 wordpress,网站设计价格大概多少1、幂等的基本概念 幂等简单点讲#xff0c;就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的#xff0c;不会产生任何副作用。幂等分很多种#xff0c;比如接口的幂等、消息的幂等#xff0c;它是分布式系统设计时必须要考虑的一个方面。
查询操作(天然幂等…1、幂等的基本概念 幂等简单点讲就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的不会产生任何副作用。幂等分很多种比如接口的幂等、消息的幂等它是分布式系统设计时必须要考虑的一个方面。
查询操作(天然幂等) 查询一次和查询多次在数据不变的情况下查询结果是一样的。查询是天然的幂等操作删除操作 (天然幂等) 删除操作也是幂等的删除一次和删除多次都是把数据删除(注意可能返回结果不一样删除的数据不存在返回 0删除的数据多条返回结果多个)。
删除操作 (天然幂等) 删除操作也是幂等的删除一次和删除多次都是把数据删除(注意可能返回结果不一样删除的数据不存在, 返回 0删除的数据多条返回结果多个).
新增操作 新增操作这种情况下多次请求可能会产生重复数据
修改操作 修改操作如果只是单纯的更新数据比如: update account set money100 where id1是没有问题的如果还有计算比如: update account set moneymoney100 where idl这种情况下多次请求可能会导致数据错误。
总结当出现消费者对某条消息重复消费的情况时重复消费的结果与消费一次的结果是相同的并且多次消费并未对业务系统产生任何负面影响那么这个消费者的处理过程就是幂等的。例如在支付场景下消费者消费扣款消息对一笔订单执行扣款操作扣款金额为 100 元。如果因网络不稳定等原因导致扣款消息重复投递消费者重复消费了该扣款消息但最终的业务结果是只扣款一次扣费 100 元且用户的扣款记录中对应的订单只有一条扣款流水不会多次扣除费用。那么这次扣款操作是符合要求的整个消费过程实现了消费幂等。
2、产生消息重复的原因 在可联网应用中尤其在网络不稳定的情况下消息队列的消息有可能会出现重复如果消息重复消费会影响您的业务处理请对消息做幂等处理。消息重复的可能原因如下:
发送时消息重复 当一条消息已被成功发送到服务端并完成持久化此时出现了网络闪断或者生产者宕机导致服务端对生产者应答失败。 如果此时生产者 Producer 意识到消息发送失败并尝试再次发送消息消费者 Consumer 后续会收到两条内容相同的消息。
投递时消息重复 消息消费的场景下消息已投递到消费者 Consumer 并完成业务处理当消费者给服务端反馈应答的时候网络闪断为了保证消息至少被消费一次消息队列的服务端将在网络恢复后再次尝试投递之前已被处理过的消息消费者 Consumer 后续会收到两条内容相同的消息
负载均衡时消息重复 当消息队列的服务端或消费者重启、扩容或缩容时都有可能会触发 rebalance此时消费者 Consumer 可能会收到重复消息。
3、解决方案及案例分析 既然消息可能会产生重复那如何解决消息幂等的问题呢?我们需要从生产者、中间件、消费者这几个不同层面来保证消息的幂等,[消息的幂等业界有很多种方案我这里列出常见的几种方案供大家参考
3.1 设置业务唯一 key 方案 (应用最广泛) 业务唯一key 可以是单个字段或者组合字段这个方案是怎么实现的呢?
生产者消息休构造业务唯一 key消息端针对这个 key 加分布式锁
在消费端创建一个消息防重表利用插入记录唯一健约束控制 但是这会与业务有一定的耦合另外高并发下频繁对消息防重表进行操作性能比较低不太建议使用我们通常是在消费端加一个redis分布式锁防止短期内消息的重复投递
数据库业务表加唯一索引 (数据库)
以用户在积分商城下单为例具体业务流程如下
1、客户发起支付流程
2、生产者生产消息构造一个订单号作为消息体幂等的唯一 key
3、发送消息给 brokerbroker 持久化消息到磁盘
4、消费者开始消费消息在消费逻辑中加一个分布式锁key为订单号防止短时间内消息重复投递
5、当加锁成功后执行核心业务逻辑然后释放分布式锁当加锁失败直接结束
6、最后为了防止后续生产者重复推送相同唯一key 的消息我们需要在数据库的业务表中给这个订单号加一个唯一索引通过唯一健约束来保证数据库表不会出现两条相同的记录从而实现消息幂等
3.2 设置业务唯一id方案 这个其实跟上一个方案类似只是唯一id是需要我们通过 分布式id服务 生成其他的处理方法跟上一个方案一样。
3.3 基于业务的状态机方案 在设计单据相关的业务或者是任务相关的业务肯定会涉及到状态机(状态变更图)我们以业务单据为例在业务单据上面会有个状态状态在不同的情况下会发生变更一般情况下存在有限状态机当消费业务消息的时候如果状态机已经处于下一个状态这时候来了一个上一个状态的消息直接丢弃消息不处理保证了有限状态机的幂等。 3.4 基于version版本号的乐观锁方案 此方案一般是适用于更新业务的场景更新表的时候通过版本号对比来保证消息的幂等
具体业务流程 1、客户购买商品完成后准备发送一条扣减账户200 的消息
2、生产端开始生产消息构造消息体{ id1money200version1 }
3、发送消息给 brokerbroker 持久化这条消息后返回确认消息给生产者此时时出现了网络闪断或者生产者宕机导致 broker 对生产者响应失败 如果此时生产者意识到消息发送失败并尝试再次发送消息消费者后续会收到两条内容相同的消息
4、消费者收到相同的消息开始消费第一条消息{id1money200version1}根据 version1 更新记录更新成功
5、接着开始消费第二条消息{id1money200versionl }根据 version1更新记录但是此时 version 已经被更新为 2条件不满足更新失败
6、消费者通过基于version的乐观锁保证了消息幂等。 3.5 insert ... on duplicate key update 方案 此方案一般适合一些统计更新类的业务或者定时同步第三方平台数据到自己数据库的场景例如: 定时同步企业微信的成员数据到自已企微库的成员表就可以采用这种方案实现。
on dupdate key update 语句基本功能是当表中没有原来记录时就插入有的话就更新。
1. on duplicate key update 语句根据主键id或唯一键来判断当前插入是否已存在。 2. 记录已存在时只会更新on duplicate key update之后指定的字段。 3. 如果同时传递了主键和唯一键以主键为判断存在依据唯一键字段内容可以被修改。 具体业务流程 1、张三关注某 A 公司企业微信加人深圳区企微群 2、管理员在深圳区企微群投放一个活动张三第一次点击这个活动这个时候活动模块发送一条 kafka 消息 3、在数据库创建一张活动效果统计表act_code 和 usr_id 两个字段作为联合唯一索引 4、数据处理模块消费这条消息通过 insert on duplicate key update 插人一条记录 5、过了几小时张三第二次点击这个活动这个时候活动模块再发送一条 kafka 消息数据处理模块再次消费这条消息通过 insert...on duplicate key update 更新对应唯一索引的这条记录的更新时间字段 6、通过 insert...on duplicate key update 命令可以实现数据库表不会出现重复的记录还能实现业务的更新逻辑。
补充
消息消费失败的时候可以做好监控报警以便进行人工干预 消费消息的方法确保在同一个事务以便消费失败的时候可以回滚
