Redis缓存

        使用redis作为缓存首先要考虑几个常见的问题。

1、缓存穿透

2、缓存雪崩

3、缓存击穿

4、数据一致性

1、缓存穿透

        缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

        解决方案：

        1）布隆过滤器、将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截 掉，从而避免了对底层存储系统的查询压力，有一定误判率

         2）如果一个DB查询返回的数据为空（不管是数 据不存在，还是系统故障）仍然把这个空结果进行缓存，但它的过期时间会很短。

2、缓存雪崩

        缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。缓存失效时的雪崩效应对底层系统的冲击非常可怕。

          解决方案：可以考虑用加锁或队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。

        1）将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

         2）使用两份缓存，一份短失效，一份长失效，甚至永久有效。在第一份缓存失效的时候，第一个到达的请求访问DB,后续请求访问备份缓存。

          两种方案可以同时使用，单独使用也可。切忌将数据库某一张表整表缓存为1个key

          题外话:如果不幸在你的项目中已经将整张表缓存为1个key，并且你的数据量已经有一定规模。更新一次key用时相当长。这时你可以在你的key上在加一条数据。数据内容保存（当前时间+2小时），你每次使用数据都将这个值取出来判断，且保证这个判断持续工作。在即将到达失效时间的前1小时开始更新。呵呵

3、缓存击穿

        对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。

        缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

        解决方案：

             1）使用互斥锁（mutex key）           

             在缓存失效的时候，不是立即去DB，而是先存入一个值set一个mutex key，当操作返回成功时，再进行DB的操作并回设缓存；否则，就重试整个get缓存的方法。(可以改进为2.2,双缓存策略)

            2）提前使用互斥锁（mutex key）

              在value内部设置1个超时值，当读取超时值发现已经过期时候延长超时值并且调用DB

            3）逻辑过期

               不设置数据过期或失效时间。只在key对应的value里设置时间，如果发现要过期。调用异步的DB方法。也就是只在逻辑上存在过期时间，这种方式对性能非常友好。

4、缓存与数据库 数据一致性

        尽量缓存不可变数据 

        假设先写数据库，再淘汰缓存：数据库操作成功，淘汰缓存失败。               db中是新数据，cache中是旧数据       

    假设先淘汰缓存，再写数据库：淘汰缓存成功，写数据库失败。一次Cache miss   cache中无数据，db中是旧数据

    这个问题实质上是和分布式数据一致性是一样的，数据库和缓存和看做分布式数据库或分布式缓存，都是存储数据的