Redis:
Redis支持的数据类型？
String字符串、Hash（哈希）、List（列表）、Set（集合）、zset(sorted set：有序集合)
如何解决缓存雪崩：
我们先说一下什么是缓存雪崩吧~
简单来说就是Redis挂掉了，请求全部走数据库。
还有就是 如果缓存数据设置的过期时间是相同的，并且Redis恰好将这部分数据全部删光了。这就会导致在这段时间内，这些缓存同时失效，全部请求到数据库中。这就是缓存雪崩。
如何解决？
第一种的话：
-
事发前：实现Redis的高可用(主从架构+Sentinel 或者Redis Cluster)，尽量避免Redis挂掉这种情况发生。
-
事发中：万一Redis真的挂了，我们可以设置本地缓存(ehcache)+限流(hystrix)，尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的)
-
事发后：redis持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。
第二种：
在缓存的时候给过期时间加上一个随机值，这样就会大幅度的减少缓存在同一时间过期。
如何解决缓存穿透：
缓存穿透是什么？
请求的数据在缓存大量不命中，导致请求走数据库。然后搞垮数据库。
如何解决呢？
有两种方案：
-
由于请求的参数是不合法的(每次都请求不存在的参数)，于是我们可以使用布隆过滤器(BloomFilter)或者压缩filter提前拦截，不合法就不让这个请求到数据库层！
-
当我们从数据库找不到的时候，我们也将这个空对象设置到缓存里边去。下次再请求的时候，就可以从缓存里边获取了。这种情况我们一般会将空对象设置一个较短的过期时间。
缓存与数据库双写一致的问题？其实就是缓存与数据库数据不一致怎么办？
从理论上说，只要我们设置了键的过期时间，我们就能保证缓存和数据库的数据最终是一致的。因为只要缓存数据过期了，就会被删除。随后读的时候，因为缓存里没有，就可以查数据库的数据，然后将数据库查出来的数据写入到缓存中。
除了设置过期时间，我们还需要做更多的措施来尽量避免数据库与缓存处于不一致的情况发生。
对于更新操作有两种选择：
-
先操作数据库，再操作缓存
-
先操作缓存，再操作数据库
首先，要明确的是，无论我们选择哪个，我们都希望这两个操作要么同时成功，要么同时失败。所以，这会演变成一个分布式事务的问题。
所以，如果原子性被破坏了，可能会有以下的情况：
-
操作数据库成功了，操作缓存失败了。
-
操作缓存成功了，操作数据库失败了。
如果第一步已经失败了，我们直接返回Exception出去就好了，第二步根本不会执行。
操作缓存：
操作缓存也有两种方案：
-
更新缓存
-
删除缓存
一般我们都是采取删除缓存缓存策略的，原因如下：
-
高并发环境下，无论是先操作数据库还是后操作数据库而言，如果加上更新缓存，那就更加容易导致数据库与缓存数据不一致问题。(删除缓存直接和简单很多)
-
如果每次更新了数据库，都要更新缓存【这里指的是频繁更新的场景，这会耗费一定的性能】，倒不如直接删除掉。等再次读取时，缓存里没有，那我到数据库找，在数据库找到再写到缓存里边(体现懒加载)
基于这两点，对于缓存在更新时而言，都是建议执行删除操作！
先更新数据库，再删除缓存：
正常的情况是这样的：
-
先操作数据库，成功；
-
再删除缓存，也成功；
如果原子性被破坏了：
-
第一步成功(操作数据库)，第二步失败(删除缓存)，会导致数据库里是新数据，而缓存里是旧数据。
-
如果第一步(操作数据库)就失败了，我们可以直接返回错误(Exception)，不会出现数据不一致。
如果在高并发的场景下，出现数据库与缓存数据不一致的概率特别低，也不是没有：
-
缓存刚好失效
-
线程A查询数据库，得一个旧值
-
线程B将新值写入数据库
-
线程B删除缓存
-
线程A将查到的旧值写入缓存
要达成上述情况，还是说一句概率特别低
删除缓存失败的解决思路：
-
将需要删除的key发送到消息队列中
-
自己消费消息，获得需要删除的key
-
不断重试删除操作，直到成功
先删除缓存，再更新数据库：
正常情况是这样的：
-
先删除缓存，成功；
-
再更新数据库，也成功；
如果原子性被破坏了：
-
第一步成功(删除缓存)，第二步失败(更新数据库)，数据库和缓存的数据还是一致的。
-
如果第一步(删除缓存)就失败了，我们可以直接返回错误(Exception)，数据库和缓存的数据还是一致的。
看起来是很美好，但是我们在并发场景下分析一下，就知道还是有问题的了：
-
线程A删除了缓存
-
线程B查询，发现缓存已不存在
-
线程B去数据库查询得到旧值
-
线程B将旧值写入缓存
-
线程A将新值写入数据库
所以也会导致数据库和缓存不一致的问题。
并发下解决数据库与缓存不一致的思路：
-
将删除缓存、修改数据库、读取缓存等的操作积压到队列里边，实现串行化。
对比一下两种策略：
我们可以发现，两种策略各自有优缺点：
-
先删除缓存，再更新数据库
-
在高并发下表现不如意，在原子性被破坏时表现优异
-
先更新数据库，再删除缓存(
Cache Aside Pattern设计模式) -
在高并发下表现优异，在原子性被破坏时表现不如意