然而，在高并发下，同一时刻会有大量的请求，都在秒杀同一件商品，这些请求同时去查缓存中没有数据，然后又同时访问数据库。结果悲剧了，数据库可能扛不住压力，直接挂掉。
如何解决这个问题呢？
这就需要加锁，最好使用分布式锁。
当然，针对这种情况，最好在项目启动之前，先把缓存进行预热。即事先把所有的商品，同步到缓存中，这样商品基本都能直接从缓存中获取到，就不会出现缓存击穿的问题了。
是不是上面加锁这一步可以不需要了？
表面上看起来，确实可以不需要。但如果缓存中设置的过期时间不对，缓存提前过期了，或者缓存被不小心删除了，如果不加速同样可能出现缓存击穿。
其实这里加锁，相当于买了一份保险。
5.2 缓存穿透如果有大量的请求传入的商品id，在缓存中和数据库中都不存在，这些请求不就每次都会穿透过缓存，而直接访问数据库了。
由于前面已经加了锁，所以即使这里的并发量很大，也不会导致数据库直接挂掉。
但很显然这些请求的处理性能并不好，有没有更好的解决方案？
这时可以想到布隆过滤器。
系统根据商品id，先从布隆过滤器中查询该id是否存在，如果存在则允许从缓存中查询数据，如果不存在，则直接返回失败。
虽说该方案可以解决缓存穿透问题，但是又会引出另外一个问题：布隆过滤器中的数据如何更缓存中的数据保持一致？
这就要求，如果缓存中数据有更新，则要及时同步到布隆过滤器中。如果数据同步失败了，还需要增加重试机制，而且跨数据源，能保证数据的实时一致性吗？
显然是不行的。
所以布隆过滤器绝大部分使用在缓存数据更新很少的场景中。
如果缓存数据更新非常频繁，又该如何处理呢？
这时，就需要把不存在的商品id也缓存起来。
下次，再有该商品id的请求过来，则也能从缓存中查到数据，只不过该数据比较特殊，表示商品不存在。需要特别注意的是，这种特殊缓存设置的超时时间应该尽量短一点。
6 库存问题对于库存问题看似简单，实则里面还是有些东西。
真正的秒杀商品的场景，不是说扣完库存，就完事了，如果用户在一段时间内，还没完成支付，扣减的库存是要加回去的。
所以，在这里引出了一个预扣库存的概念，预扣库存的主要流程如下：
扣减库存中除了上面说到的预扣库存和回退库存之外，还需要特别注意的是库存不足和库存超卖问题。
6.1 数据库扣减库存使用数据库扣减库存，是最简单的实现方案了，假设扣减库存的sql如下：
update product set stock=stock-1 where id=123;
这种写法对于扣减库存是没有问题的，但如何控制库存不足的情况下，不让用户操作呢？
这就需要在update之前，先查一下库存是否足够了。
伪代码如下：