【备战春招】第4天 springboot 技术栈分析之redis 超售

课程名称：SpringBoot2.X + Vue + UniAPP，全栈开发医疗小程序

课程章节： 第一章

课程讲师：神思者

课程内容

超售现象的产生原因？

商品秒杀过程中经常会出现超售的现象，超售就是卖出了超过预期数量的商品。比如说A商品库存是100个，但是秒杀的过程中，一共卖出去500个A商品。对于卖家来说，这就是超售。对于买家来说，这属于超买。

商品超售的后果是非常严重的，比如说，某个店铺在电商平台上搞活动，拿出20部苹果手机半价销售。相当于买到的人，省了四、五千块钱，抢购手机的人肯定趋之若鹜。于是几万人、甚至几十万人去抢购商品。这下可好，原本商家拿出20部手机搞促销，但是出现了超售现象，实际有两千人用半价抢到了手机。这下子，商家可亏大发了。商家仔细一下，不对啊，我在电商平台的后台设置了，秒杀商品的库存是20，结果卖出去2000部半价手机。电商平台有不可推卸的责任，这是电商系统的程序问题，于是商家提出向电商平台索赔。像是淘宝这一样的B2B电商平台，里面的商家几百万。要是双十一促销活动，都出现了超售现象，淘宝得赔多少钱啊？所以超售这个问题必须解决，一定要解决。

怎么预防数据库超售？

第一种办法技术上最稳妥，但是业务上不可行。那就是设置事物的隔离级别为Serializable。这个事物隔离级别非常严格，因为多个事物并发执行，对同一条记录修改，就会出现超售现象。所以干脆，咱们就禁止事物的并发执行吧。Serializable就是让数据库，串行执行事物，一个事物执行完，才能执行下一个事物，这种办法确实解决了超售的问题。但是同学们，SQL语句对数据的修改，最终都是要反应到磁盘上的。磁盘的IO速度你也是知道的，比内存和CPU慢多了。所以说，串行化执行事物，一个事物执行的时间就不短，你让后面的排队的事物等到什么时候？因此说，串行化执行事物的办法是不可行的。你要是这么搞，电商系统几千万人一起买东西的时候，几千万个事物串行执行，最后的事物，真得是要等到猴年马月了，所以绝对不能这么搞。

第二种办法是给数据表设置乐观锁。我们在数据表上面添加一个乐观锁字段，数据类型是整数的，用来记录数据更新的版本号，这个跟SVN机制很像。乐观锁是一种逻辑锁，他是通过版本号来判定有没有更新冲突出现。比如说，现在A商品的乐观锁版本号是0，现在有事务1来抢购商品了。事务1记录下版本号是0，等到执行修改库存的时候，就把乐观锁的版本号设置成1。但是事务1在执行的过程中，还没来得及执行UPDATE语句修改库存。这个时候事务2进来了，他执行的很快，直接把库存修改成99，然后把版本号变成了1。这时候，事务1开始执行UPDATE语句，但是发现乐观锁的版本号变成了1，这说明，肯定有人抢在事务1之前，更改了库存，所以事务1就不能更新，否则就会出现超售现象。

为了避免患者挂到已经过期时间段的门诊号，所以我们给每个缓存的记录都设置过期时间。如果当前时间到了某个缓存记录的出诊时间段，那么该缓存记录被自动删除，患者就不能挂该时间段的号了。例如某个缓存记录对应的出诊时间是2022年10月10日 09:00~09:30，当前时间是2022年10月10的09:01分，那么该缓存记录就属于过期，Redis会立即删除这条缓存，避免患者挂这个时间段的号。简单的说就是患者只能挂未来时间段的号，不能挂当前和过去时间的号。