从普通查询商品到高并发查询商品的优化思路

• version 0（初始版本）

        问题1：商品越来越多，redis承载越来越大

• version 1

        问题1解决思路：设置超时时间

        问题2：我们一般会在启动时初始化redis的产品库存，如果这样设置的话，可能发生在同一时间大量缓存失效的情况。

• version 2

        问题2解决思路：将redis的有效时间从固定时间变为可变时间。

        问题3：对于冷门商品可能半年都没有人浏览过，针对这一对能不能减少我们redis的存储呢

• version 3

        问题3解决思路：每次我们从redis拿到的商品都是热门商品，所以我们进行读延期（红框中），这样就可以简单的实现一个冷热分离。 

        问题4：假如用户或者黑客不停的访问不存在的商品（缓存穿透问题），除开使用布隆过滤器，我们在后端代码可以怎么处理。

• version 4

        问题4解决方案：既然有查询到空的产品，那么我们就返回给前端一个空产品就好，redis中设置一个稍短的有效时间，配合布隆过滤器，可以有效防止缓存穿透的问题。

        问题5：如果遇到了突然出现的爆品（热点重建），一瞬间数以万记的访问打到我们数据库，直接导致我们数据库宕机（缓存击穿），怎么办。

• version 5 

        将从redis获取商品的代码提取出来封装，要不有点乱。下面为版本5的优化。

        问题5解决方案：用锁进行实现，这里我还使用双重校验（DCL）来进行保证。

        问题6：对于生产环境，在并发量特别高的情况下还是极易出现双写不一致的情况，怎么办。

• version 6 

        问题6解决方案：数据库查询和redis设置这一步在加锁，以尽量保证我们的双写一致。

        问题7：加了两把锁，是否能够对锁进行优化。

• version 7

 

        问题7解决思路：我们可以对这种读多写少的情况使用读写锁，保证线程在读读时可以并行执行，提高吞吐量。

        总结，在使用缓存时基本都要加锁，如果并发量大到现在这套框架仍扛不住的情况下就可以在增加使用guava或者ehcache等本地缓存框架。