如果连铁将军都不再可靠--记一次排查使用分布式轮候锁+SESSION防订单重复仍然加锁失效问题经历

0.问题背景

此次问题源于一次挺严重的生产事故:客户的订单被重复生成了,而出问题的代码其实很简单:

// ....
redisLockUtil.lock(memberVo.getMember().getId());

String orderTmpId = orderSubmitVo.getRid();

/** 防止表单重复提交,orderTmpId只能一次有效 */
String rid = (String) request.getSession().getAttribute(GlobalContants.ORDER_TEMP_ID);
if (!Lang.isEmpty(rid) && rid.equals(orderTmpId)) {
    request.getSession().removeAttribute(GlobalContants.ORDER_TEMP_ID);
} else {
    attr.addAttribute("error", errorCode);
    attr.addAttribute("message", "订单提交数据有误,请不要重复提交");
    return "redirect:/order/orderSubmitResult";
}
//...

代码的逻辑很简单,首先,通过redisLockUtil.lock实现了一个轮候锁,每个用户的多次请求是以轮候排队形式进行处理;其次,通过预分配并存入Session的RID,临时订单号防止重复提交,一切看上去是多么的健壮啊,怎么会出问题呢!

项目使用了spring-session框架的RedisSession实现基于Redis的跨应用的Session共享

1.初步分析

一开始,我们并不能稳定的重现问题,总是在正常订单中偶尔的出现一些重复单,在通过不断的尝试后,终于让我们发现了一些规律:

  1. 使用QQ浏览器会极大的提高重现成功率(不要问我为什么QQ浏览器总会发送两个时间间隔极短的请求!ε=( o`ω′)ノ)
  2. 当程序处理较慢时容易重现

接下来我们模拟了连续发送重复请求的场景进行了测试,结果发现了一个有趣的情况,提交两个连续的请求,会生成两个一样的订单,而提交三个连续请求时也只会生成两个一样的订单,提交4个请求呢,生成了3个订单!而订单的生成时间间隔通常都在2s到3s之间,这基本就可以排除轮候锁的问题了,那,难道是rid的判重出问题了?
接下来的测试我们将主要关注rid的变化,以下是其中一组数据示意:

req1: {SESSION[TEMP_ORDER_ID]: 2018052204911}
req2: {SESSION[TEMP_ORDER_ID]: 2018052204911}
req3: {SESSION[TEMP_ORDER_ID]: null}

等等!session_rid重复了2次,怎么可能!根据代码,在req1处理之后,session中的TEMP_ORDER_ID应该立即被remove掉才对!
于是,我们继续关注这个rid,发现存在这样的诡异情况:

  1. req1、req2在调用request.getSession().getAttribute(GlobalContants.ORDER_TEMP_ID)后,都可获取到同一个rid,而req3为空
  2. req1、req2在调用完 request.getSession().removeAttribute(GlobalContants.ORDER_TEMP_ID) 后打印Session中的ORDER_TEMP_ID,值为空

req2中可以获取到req1中本应被删除的rid,而直到处理req3时,SESSION中的TEMO_ORDER_ID才被正确移除!但是,每次removeAttribute后,request.getSession().getAttribute(GlobalContants.ORDER_TEMP_ID)的取值又的确为空!这怎么可能?!
因为项目使用了RedisSession实现Session共享,冷静下来的我又去看了看Redis中的数据,结果发现,当req1调用完removeAttribute后,Redis上Value里的ORDER_TEMP_ID属性根本没置空,同样的,也是直到req2处理完毕req3开始处理时才变为空!现在基本可以确定就是removeAttribute没有如我们所想的那样去正确删除Redis里的值导致了下一请求处理时仍然能获取到本应被删除的属性。

难道是spring-session搞的鬼?跟进源码看看吧...

2.抽丝剥茧

先看看RedisSession里是怎么实现removeAttribute的:
clipboard.png
先在cached中移除待删除的属性,然后将detla中的对应属性至空
嗯....好像也没什么问题...再看看flushImmediateIfNecessary方法,这个方法应该就是吧detla中保存的属性写入Redis了吧,至少也是前置的某些步骤吧:
clipboard.png
嗯,果然调用了saveDelta,看名字相当直白,就是保存detla,看看具体实现吧
clipboard.png
可见,delta就是Session里的内容,通过BoundHashOperations写入Redis,嗯,很Spring,很正路,应该也没有太多问题...
等等,好像哪里不对
flushImmediateIfNecessary? IfNecessary?!
clipboard.png
回顾一下之前看到的代码,调用saveDelta前可是有个判断的,只有配置了redisFlushMode为RedisFlushMode.IMMEDIATE时才会立即将session写入Redis!
那么,问题来了,如果不设置这个配置呢?

3.真相大白

来看看RedisSession提供了什么FlushMode:
clipboard.png
可以看到,RedisFlushMode提供了ON_SAVE跟IMMEDIATE两种方式,根据这里的注释,这两个配置的作用分别是这样的:

ON_SAVE: 只有当SessionRepository.save方法被调用的时候才将缓存的Session属性写入Redis,而在一般的Web项目中,上述方法会在Http Response被提交的时候才会被调用。
IMMEDIATE: 尽可能地将数据写入Redis,例如创建Session、设置Session的Attribute都会将数据立即的写入Redis

再来看看API文档怎么描述的
图片描述
看看这可爱的默认值!我们终于知道了当我们不做任何设置时,spring-session默认采用的是ON_SAVE方式!显而易见,使用ON_SAVE方式能最大限度的减少与Redis的IO交互,而在大多数场景下都是没有问题的。然而我们的代码就恰恰是在第一个请求还没提交,第二个请求已经进入到Action方法并获取Session,此时缓存中的TEMP_ORDER_ID并没有在Redis中被设置成空,因此导致了这个几乎不可能发生的“Session脏读”事件!

4. 解决方案

目前我们采取将RedisFlushMode改为IMMEDIATE,修改方法为在@EnableRedisHttpSession注解中指定flushMode:

Configuration
@EnableRedisHttpSession(redisFlushMode = RedisFlushMode.IMMEDIATE)
public class WebSessionConfig {
    //...
}

如此修改后,在每次调用removeAttribure后,都能正确的观察到Redis中相应的属性被置为空,问题也就基本得到了解决。

更多的思考

到此,其实问题已经解决了,但是还有一个疑问:我的轮候锁是假的么?说好的锁中贵族铁将军呢?!怎么还能有重复的请求进来呢?!
让我们再次的回顾一下整体的代码,将业务代码去掉,我们的代码是这样的:

@RequestMapping(value = {"/orderSubmit", "/orderSubmit.action", "/orderSubmit.html"}, method = RequestMethod.POST)
public String orderSubmit(OrderSubmitVo orderSubmitVo, Map model, HttpServletRequest request, RedirectAttributes attr) {
    MemberVo memberVo = loginService.findMemberVo(request);
    try {
        //同一用户排队下单
        redisLockUtil.lock(memberVo.getMember().getId());
        String orderTmpId = orderSubmitVo.getRid();
        /** 防止表单重复提交,orderTmpId只能一次有效 */
        String rid = (String) request.getSession().getAttribute(GlobalContants.ORDER_TEMP_ID);
        if (!Lang.isEmpty(rid) && rid.equals(orderTmpId)) {
            request.getSession().removeAttribute(GlobalContants.ORDER_TEMP_ID);
        } else {
            attr.addAttribute("error", errorCode);
            attr.addAttribute("message", "订单提交数据有误,请不要重复提交");
            return "redirect:/order/orderSubmitRe
        }
        // ...balabalabala 这里有很多代码..
        return "redirect:/order/orderSubmitResult";
    } catch (Exception e) {
        logger.error("提交订单异常", e);
        attr.addAttribute("error", GlobalContants.CREATE_ORDER_ERROR_NEW_ORDER_FAIL);
    } finally {
        // 释放锁
        redisLockUtil.unlock(memberVo.getMember().getId());
    }
    model.put("error", GlobalContants.CREATE_ORDER_ERROR_NEW_ORDER_FAIL);
    return "redirect:/order/orderSubmitResult";
}

简而言之,就是这么一个流程:

获取锁 -> 获取session的rid -> 校验rid是否重复提交 -> 删除session的rid -> 业务逻辑 -> 释放锁

看似很严谨啊,那问题出在哪里呢?回忆一下上文提到的,spring-session在默认情况下,是在response被commit后,将数据写入Redis。相信到此大家都明白了吧,释放锁的操作在respone被commit之前!当在较短的间隔内有A、B两个请求进入这个Action,A获得锁进行处理,而B在等待A释放锁,此时A处理完了业务逻辑但还没有提交response锁就被释放了!B获得了锁并且读取了A还没提交的Session!就好比小明上厕所,屁股还没擦水还没冲就把门打开了,后面进来的人就当然能看到马桶里aslfkjsdalvijasdvjlsaslvjasdiovjvjsdalvjasdlvjsdvjasdklv哎!我写文章呢lkjaslfjladsjfldfjafl你干嘛!aslfjasldkvjlasdnvlsavjnsljuiewosvnvowijjvsovn

咳咳,大家不要误会,我的脸绝对没有被摁在键盘上摩擦,OK,这篇分享就先到这,我们有缘再会!

keywords: spring-session removeAttribute 无效


Akers的技术分享
主要分享java、python、koltin方面的个人技术整理

屡次转投Python神教失败的Java全栈工程师,目前主要关注微服务、人工智能、Koltin语言、用还没学会的区...

29 声望
1 粉丝
0 条评论
推荐阅读
BigTreeTech Octopus 必趣章鱼主板使用Klicky probe
注意,官方文档说的是接公共地(GND)和信号,对应章鱼主板,可以用J40接口(跟接近开关同个接口)分别接DC和PB7,DC电压建议改成5V![(HGL2}K(51}JD%IB[~{}]9Q.png](/img/bVcW50o)

Akers阅读 2.6k

刨根问底 Redis, 面试过程真好使
充满寒气的互联网如何在面试中脱颖而出,平时积累很重要,八股文更不能少!下面带来的这篇 Redis 问答希望能够在你的 offer 上增添一把🔥。

菜农曰17阅读 946

封面图
PHP转Go实践:xjson解析神器「开源工具集」
我和劲仔都是PHP转Go,身边越来越多做PHP的朋友也逐渐在用Go进行重构,重构过程中,会发现php的json解析操作(系列化与反序列化)是真的香,弱类型语言的各种隐式类型转换,很大程度的减低了程序的复杂度。

王中阳Go10阅读 1.9k评论 2

封面图
万字详解,吃透 MongoDB!
MongoDB 是一个基于 分布式文件存储 的开源 NoSQL 数据库系统,由 C++ 编写的。MongoDB 提供了 面向文档 的存储方式,操作起来比较简单和容易,支持“无模式”的数据建模,可以存储比较复杂的数据类型,是一款非常...

JavaGuide5阅读 789

封面图
计算机网络连环炮40问
本文已经收录到Github仓库,该仓库包含计算机基础、Java基础、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享等核心知识点,欢迎star~

程序员大彬8阅读 1.1k

与RabbitMQ有关的一些知识
工作中用过一段时间的Kafka,不过主要还是RabbitMQ用的多一些。今天主要来讲讲与RabbitMQ相关的一些知识。一些基本概念,以及实际使用场景及一些注意事项。

lpe2348阅读 1.9k

封面图
Git操作不规范,战友提刀来相见!
年终奖都没了,还要扣我绩效,门都没有,哈哈。这波骚Git操作我也是第一次用,担心闪了腰,所以不仅做了备份,也做了笔记,分享给大家。问题描述小A和我在同时开发一个功能模块,他在优化之前的代码逻辑,我在开...

王中阳Go5阅读 2.3k评论 2

封面图

屡次转投Python神教失败的Java全栈工程师,目前主要关注微服务、人工智能、Koltin语言、用还没学会的区...

29 声望
1 粉丝
宣传栏