缓存穿透
缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中，通常出于容错的考虑，如果从存储层查不到数据则不写入缓存层。
缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。
造成缓存穿透的基本原因有两个：
1.自身业务代码或者数据出现问题。
2.一些恶意攻击、爬虫等造成大量空命中。
缓存穿透问题解决方案：
1.缓存空对象
2.布隆过滤器
布隆过滤器
对于恶意攻击，向服务器请求大量不存在的数据造成的缓存穿透，还可以用布隆过滤器先做一次过滤，对于不存在的数据布隆过滤器一般都能够过滤掉，不让请求再往后端发送。当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在(底层是长度很长的二进制数组)
布隆过滤器就是一个大型的位数组和几个不一样的无偏 hash 函数。所谓无偏就是能够把元素的 hash 值算得比较均匀。
向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash 算得一个整数索引值然后对位数组长度进行取模运算得到一个位置，每个 hash 函数都会算得一个不同的位置。再把位数组的这几个位置都置为 1 就完成了 add 操作。
向布隆过滤器询问 key 是否存在时，跟 add 一样，也会把 hash 的几个位置都算出来，看看位数组中这几个位置是否都为 1，只要有一个位为 0，那么说明布隆过滤器中这个key 不存在。如果都是 1，这并不能说明这个key 就一定存在，只是极有可能存在，因为这些位被置为 1 可能是因为其它的 key 存在所致。如果这个位数组比较稀疏，这个概率就会很大，如果这个位数组比较拥挤，这个概率就会降低。
这种方法适用于数据命中不高、 数据相对固定、 实时性低（通常是数据集较大） 的应用场景， 代码维护较为复杂， 但是缓存空间占用很少。
总结：
布隆过滤器由一个二进制向量（Bit Array）和多个哈希函数组成：
初始化：创建一个长度为 m 的二进制数组(全0)。
添加元素：对元素执行 k 个哈希函数，得到 k 个哈希值，将对应的二进制位设为 1。
查询元素：对元素执行同样的 k 个哈希函数，如果所有对应的二进制位都是 1，则可能存在；否则一定不存在。
ps：布隆过滤器不能删除数据，如果要删除得重新初始化数据(指标准的布隆过滤器)；如计数布隆过滤器(Counting Bloom Filter)就可以删除，原理是将位数组中的每个bit替换为一个计数器(如 4-bit 计数器)。插入时对计数器加1，删除时减1。
Config config = new Config();
config.useSingleServer().setAddress("redis://localhost:6379");
//构造Redisson
RedissonClient redisson = Redisson.create(config);
RBloomFilter<String> bloomFilter = redisson.getBloomFilter("nameList");
//初始化布隆过滤器：预计元素为100000000L,误差率为3%,根据这两个参数会计算出底层的bit数组大小
bloomFilter.tryInit(100000000L,0.03);
//将zhuge插入到布隆过滤器中
bloomFilter.add("zhuge");
//判断下面号码是否在布隆过滤器中
System.out.println(bloomFilter.contains("guojia"));//false
System.out.println(bloomFilter.contains("baiqi"));//false
System.out.println(bloomFilter.contains("zhuge"));//true
缓存失效
由于大批量缓存在同一时间失效可能导致大量请求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大甚至挂掉，对于这种情况可以在批量增加缓存时最好将这一批数据的缓存过期时间设置为一个时间段内的不同时间。
缓存雪崩
缓存层由于某些原因不能提供服务(比如超大并发过来，缓存层支撑不住，或者由于缓存设计不好，类似大量请求访问bigkey，导致缓存能支撑的并发急剧下降)， 于是大量请求都会打到后端存储层， 存储层的调用量会暴增， 造成存储层也会级联宕机的情况，如明星某某事件。
预防和解决缓存雪崩问题， 可以从以下三个方面进行着手
1.保证缓存层服务高可用性，比如使用Redis Sentinel或Redis Cluster；
2.依赖隔离组件为后端限流熔断并降级。比如使用Sentinel或Hystrix限流降级组件；比如服务降级，可以针对不同的数据采取不同的处理方式。当业务应用访问的是非核心数据(例如电商商品属性，用户信息等)时，暂时停止从缓存中查询这些数据，而是直接返回预定义的默认降级信息、空值或是错误提示信息；当业务应用访问的是核心数据(例如电商商品库存)时，仍然允许查询缓存，如果缓存缺失，也可以继续通过数据库读取；
3.提前演练。 在项目上线前， 演练缓存层宕掉后， 应用以及后端的负载情况以及可能出现的问题， 在此基础上做一些预案设定。
缓存双写不一致
线程1写数据库stock=10->删除缓存，执行后，线程3查缓存为空，查数据库是10，要更新缓存时存在延时，结果线程2把写数据stock=6删除缓存做了或stock=10->更新缓存，执行后，线程3查缓存为空，查数据库是10，要更新缓存时存在延时，结果线程2把写数据stock=6更新缓存做了(更新查询操作间加分布式锁)。
缓存更新双写不一致-缓存删除同理.png
问题解读：线程1写数据库stock=10，执行后，线程3查缓存为空，查数据库是10，要更新缓存时存在延时，结果线程2把写数据stock=6删除缓存或更新缓存做了，线程3更新缓存，查询缓存查的是错误的数据。
解决方案：
1.对于并发几率很小的数据(如个人维度的订单数据、用户数据等)，这种几乎不用考虑这个问题，很少会发生缓存不一致，可以给缓存数据加上过期时间，每隔一段时间触发读的主动更新即可。
2.就算并发很高，如果业务上能容忍短时间的缓存数据不一致(如商品名称，商品分类菜单等)，缓存加上过期时间依然可以解决大部分业务对于缓存的要求。
3.如果不能容忍缓存数据不一致，可以通过加分布式读写锁保证并发读写或写写的时候按顺序排好队，读读的时候相当于无锁。
4.也可以用阿里开源的canal通过监听数据库的binlog日志及时的去修改缓存，但是引入了新的中间件，增加了系统的复杂度。
之后可以使用分布式读写锁优化分布式锁(需要分读写锁场景)。
开发规范与性能优化
key名设计：
(1)【建议】: 可读性和可管理性，以业务名(或数据库名)为前缀(防止key冲突)，用冒号分隔，比如业务名:表名:id trade:order:1
(2)【建议】：简洁性保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视，例如：user:{uid}:friends:messages:{mid} 简化为 u:{uid}:fr:m:{mid}
(3)【强制】：不要包含特殊字符 反例：包含空格、换行、单双引号以及其他转义字符
value设计：
【强制】：拒绝bigkey(防止网卡流量、慢查询)在Redis中，一个字符串最大512MB，一个二级数据结构(例如hash、list、set、zset)可以存储大约40亿个(2^32-1)个元素，但实际中如果下面两种情况，就会认为它是bigkey。
1. 字符串类型：它的big体现在单个value值很大，一般认为超过10KB就是bigkey。
2. 非字符串类型：哈希、列表、集合、有序集合，它们的big体现在元素个数太多。
一般来说，string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。反例：一个包含200万个元素的list。
非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞）bigkey的危害：
1.导致redis阻塞(真正执行命令是单线程)
2.网络拥塞：bigkey也就意味着每次获取要产生的网络流量较大，假设一个bigkey为1MB，客户端每秒访问量为1000，那么每秒产生1000MB的流量，对于普通的千兆网卡(按照字节算是128MB/s)的服务器来说简直是灭顶之灾，而且一般服务器会采用单机多实例的方式来部署，也就是说一个bigkey可能会对其他实例也造成影响，其后果不堪设想。(网络带宽被打满)
3. 过期删除：有个bigkey，它安分守己（只执行简单的命令，例如hget、lpop、zscore等），但它设置了过期时间，当它过期后，会被删除，如果没有使用Redis 4.0的过期异步删除(lazyfree-lazy-expire yes)，就会存在阻塞Redis的可能性。命令使用：
1.【推荐】 O(N)命令关注N的数量例如hgetall、lrange、smembers、zrange、sinter等并非不能使用，但是需要明确N的值。有遍历的需求可以使用hscan、sscan、zscan等轮询代替。
2.【推荐】：禁用命令
禁止线上使用keys、flushall、flushdb等，通过redis的rename机制禁掉命令，或者使用scan的方式渐进式处理。
3.【推荐】合理使用select
redis的多数据库较弱，使用数字进行区分，很多客户端支持较差，同时多业务用多数据库实际还是单线程处理，会有干扰。
4.【推荐】使用批量操作提高效率
原生命令：例如mget、mset。
非原生命令：可以使用pipeline提高效率。
但要注意控制一次批量操作的元素个数(例如500以内，实际也和元素字节数有关)。
注意两者不同：
1. 原生命令是原子操作，pipeline是非原子操作。
2. pipeline可以打包不同的命令，原生命令做不到
3. pipeline需要客户端和服务端同时支持。
5.【建议】Redis事务功能较弱，不建议过多使用，可以用lua替代
连接池相关
连接池参数.png
maxTotal与maxIdle：maxTotal最大线程数达到后，如果不使用，线程会慢慢释放至maxIdle的数量
优化建议：
1)maxTotal：最大连接数，早期的版本叫maxActive实际上这个是一个很难回答的问题，考虑的因素：
业务希望Redis并发量；
客户端执行命令时间；
Redis资源：例如 nodes(例如应用个数) * maxTotal 是不能超过redis的最大连接数maxclients；
资源开销：例如虽然希望控制空闲连接(连接池此刻可马上使用的连接)，但是不希望因为连接池的频繁释放创建连接造成不必靠开销。以一个例子说明，假设:
一次命令时间（borrow|return resource + Jedis执行命令(含网络) ）的平均耗时约为1ms，一个连接的QPS大约是1000，业务期望的QPS是50000。那么理论上需要的资源池大小是50000 / 1000 = 50个。但事实上这是个理论值，还要考虑到要比理论值预留一些资源，通常来讲maxTotal可以比理论值大一些。但这个值不是越大越好，一方面连接太多占用客户端和服务端资源，另一方面对于Redis这种高QPS的服务器，一个大命令的阻塞即使设置再大资源池仍然会无济于事。2)maxIdle和minIdle(一开始连接池不会有任何，来一个创建一个，不会初始就弄minIdle之类的)，maxIdle实际上才是业务需要的最大连接数，maxTotal是为了给出余量，所以maxIdle不要设置过小，否则会有new Jedis(新连接)开销。
连接池的最佳性能是maxTotal = maxIdle，这样就避免连接池伸缩带来的性能干扰。但是如果并发量不大或者maxTotal设置过高，会导致不必要的连接资源浪费。一般推荐maxIdle可以设置为按上面的业务期望QPS计算出来的理论连接数，maxTotal可以再放大一倍。
minIdle(最小空闲连接数)，与其说是最小空闲连接数，不如说是"至少需要保持的空闲连接数"，在使用连接的过程中，如果连接数超过了minIdle，那么继续建立连接，如果超过了maxIdle，当超过的连接执行完业务后会慢慢被移出连接池释放掉。
如果系统启动完马上就会有很多的请求过来，那么可以给redis连接池做预热，比如快速的创建一些redis连接，执行简单命令，类似ping()，快速的将连接池里的空闲连接提升到minIdle的数量。
连接池预热
开始就有大量请求访问系统的情况：系统启动时，拿到maxIdle或minIdle，针对每个连接执行简单命令，和redis进行交互(不要执行jedis.close(),执行完同一归还，原因是
jedis.close()会把连接归还给连接池，之后获取连接可以拿归还的这个连接，最终会导致只有一个连接)
Redis对于过期键的三种清除策略
1. 被动删除：当读/写一个已经过期的key时，会触发惰性删除策略，直接删除掉这个过期key(设置过期时间，下一次访问时，判断有没有过期，有就删除，返回空)
PS:没人访问就删除不了
2. 主动删除：由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰一批已过期的key(定期找过期数据删除)
3. 当前已用内存超过maxmemory限定时，触发主动清理策略(超过缓存配置的限定会主动删除)
淘汰策略：
a) 针对设置了过期时间的key做处理：
1. volatile-ttl：在筛选时，会针对设置了过期时间的键值对，根据过期时间的先后进行删除，越早过期的越先被删除。
2. volatile-random：就像它的名称一样，在设置了过期时间的键值对中，进行随机删除。
3. volatile-lru：会使用 LRU 算法筛选设置了过期时间的键值对删除。
4. volatile-lfu：会使用 LFU 算法筛选设置了过期时间的键值对删除。
b) 针对所有的key做处理：
5. allkeys-random：从所有键值对中随机选择并删除数据。
6. allkeys-lru：使用 LRU 算法在所有数据中进行筛选删除。
7. allkeys-lfu：使用 LFU 算法在所有数据中进行筛选删除。(淘汰最近一段时间被访问次数最少的数据，以次数作为参考)
c) 不处理：
8. noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error) OOM command not allowed when used memory"，此时Redis只响应读操作。
当存在热点数据时，LRU的效率很好，但偶发性的、周期性的批量操作会导致LRU命中率急剧下降，缓存污染情况比较严重。这时使用LFU可能更好点(热点应该看访问次数，此处指的是冷热混合的时候)大多数场景都可以LRU。
根据自身业务类型，配置好maxmemory-policy(默认是noeviction)，推荐使用volatile-lru。如果不设置最大内存，当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 (swap)，会让 Redis 的性能急剧下降。
当Redis运行在主从模式时，只有主结点才会执行过期删除策略，然后把删除操作”del key”同步到从结点删除数据。
LFU：淘汰访问次数最少；LRU：淘汰最近不访问
