《Redis事务失效问题记录》
限时抢购场景下，热点数据的写操作如果是在RDBMS中进行，会造成多线程之间相互竞争InnoDB的行锁，并发越高等待的线程就会越多，这会导致RT上升，TPS下降，最终引起系统雪崩。因此将库存扣减动作放置Redis，使用乐观锁方式进行扣减，是一个不错的选择，毕竟Redis的吞吐量摆在那里，也没有行锁问题。
这段时间在对库存扣减进行二次优化(提成库存扣减成功率、减少同一时间watch碰撞概率)，发现一个问题，直接在redis-cli使用watch+multi进行操作，居然会发生超卖现象，并且产生了很多诡异现象：
1、multi后，没有加入事务队列，直接被提交；
2、成功加入事务队列，但没有达到一致性；
3、...
这事有点大，赶紧review线上库存扣减逻辑代码，并核对秒杀订单是否存在超卖，但均正常，并且用jedis直接连接redis进行超卖测试，也并没有重现上述这个问题，这就有点诡异了。review了一段时间，后来将问题定位到redis的timeout上。
扫描二维码关注公众号，回复：
208568 查看本文章
Redis的事物队列是存放在客户端的。简单说，超时后，会话断开重建连接，上个会话的事务队列自然销毁了，所以才会出现这个诡异的情况，感觉事务失效。另外各个redis表现不同，因为不同业务的server超时不同，造成了烟雾弹。Server端的timeout就是“罪魁祸首”，之所以jedis压测没超卖，是因为操作停顿时间不会大于server的超时时间，就不会被redis认为空闲连接释放。
当然如果redis的timeout是0，永不超时，则意味着客户端事务队列永不过期，当然，这是不合理的哈。