大佬教程收集整理的这篇文章主要介绍了架构师必备:系统性解决幂等问题,大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。
要在应用中做到幂等,其实并不难,本文尝试做一个系统性的总结,欢迎一起探讨。
某个操作执行一次,跟执行多次的效果一样。幂等一词来自于数学中的幂等,即f(f(x)) = f(x)。
查询类的读操作,天然是幂等的,多次调用不会有副作用。需考虑以下几种写操作的情况:
例子:不能给用户重复发放优惠券、现金奖励、通知等,商家更新商品时不能重复增加或减少库存。
下面分别讨论这几种情况。
主要依靠下游服务保证幂等。 本服务能做的是,在调下游写接口时不做重试,需设置重试次数为0。
这种情况比较简单,只有当满足前置条件时才允许操作,否则不允许更新(例如已经是终态),直接返回。 例子:订单支付成功后,不允许重复支付。
与业务强相关,可以是商品id、订单id、用户id,或者日期等,或者是几个业务字段的组合。
几个例子:
值得注意的是,需要区分新增和修改:修改时的幂等key往往需要带上版本号,才能区分是否同一次修改,每次修改对应一个唯一的版本号。
MySQL表中为幂等key建立唯一索引:强幂等,例如资金、订单,绝对不允许重复处理,当插入重复数据时报错。 不推荐用Redis实现幂等,一旦Redis出问题,比如节点宕机,可能出现2个client同时获取到锁的情况。
MySQL幂等伪代码: 插入重复记录,捕获异常,提示幂等拦截。
try {
// 插入记录
someDao.create(someRecord);
} catch (DataIntegrityViolationException e) {
// 如果是重复记录,返回异常
return failResponse("幂等拦截");
} catch (Throwable t) {
// 异常处理
return failResponse("其他异常");
}
MQ通常会保证消息至少发送一次(可能多次),并且在机器实例重启或发版时,consumer group会做rebalance,进而收到重复的消息。因此,消息的幂等处理必不可少。
实现方式: 在处理消息前加上Redis锁:如果上锁成功,则继续处理,否则稍后重试。
Redis幂等伪代码:
// 生成幂等key
String redisKey = buildRedisKey();
// 上Redis锁,租期为leaseTime
if (redisLock.tryLock(redisKey, leaseTime)) {
// 业务逻辑处理
} else {
// 稍后重试
}
以上是大佬教程为你收集整理的架构师必备:系统性解决幂等问题全部内容,希望文章能够帮你解决架构师必备:系统性解决幂等问题所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。