redis生产环境实践优化

缓存穿透：根本不在的数据不断访问，因为redis不存在这些数据，他会不断的去数据库查找；
1、
2、使用布隆函数解决；
原理：一个10亿还是百亿大小的数组(依照我们自己的数据而定)，将有效key经过运算得到一串数字存入其中，当请求来临，将请求key经过固定的hash运算在这数组中他的二进制1是否全部都找得到对应的上的。如果全部找到的话可以证明其可能存在，如果没有就时肯定不在。
RBloomFilter bloomFilter = redisson.getBloomFilter(“nameList”);
//初始化布隆过滤器：预计元素为100000000L,误差率为3%,根据这两个参数会计算出底层的bit数组大小
bloomFilter.tryInit(100000000L,0.03);
缓存失效(击穿)
大批缓存同时到期导致大量请求直接到了数据库；
设置缓存时间时，可以是固定时间+一些随机时间，使得他们到期时间不一致。
缓存雪崩
就是访问量巨大，redis支撑不住，redis宕机或者出现故障；
1、使用redis哨兵或者集群，加强rendis高可用性能；
2、后端限流，熔断并降级；
缓存与数据库双写不一致
使用redis分布式锁，在关键步骤上串行执行。并行处理这些数据没u办法保证百分百一致而且代价很大。
key的设计
1、可读性管理性；如(业务名：表明：id)等命名方式避免重复，可读性也高
2、也需要避免长度过长，毕竟redis是存活在内存里面的。其内存占用也是不可忽视的
3、避免包含空格换行单双引号以及其他转义字符；
value的设计
一定要尽量避免 bugkey，就是value的值不能过大
一般超过10kb就会被认为bigkey
String：控制在10KB内
hash,list,set,zset:不能超过5000
非字符串的bigkey不要使用del要使用hscan,sccan,zscan方式渐进式删除。
例如：一个200万的zset设置1小时过期会触发del操作造成阻塞
连接池参数
其他参数都可以使用默认参数
maxTotal（资源池中最大连接数。默认：8）
大于理论上需要的连接数，也要大于maxIdle ，为一些请求比较多的情况做准备
**maxIdle **（资源池允许最大空闲的连接数。默认：8）
这个值就设置大于业务理论需要的连接数，不能设置太小，new Jedis的开销尽量避免
minIdle（资源池确保最少空闲的连接数。默认：0）
一般把这个值设定为理论上需要的平均连接数即可
redis预热当我们刚启动系统马上就有很多请求过来这时还没有建立连接，就马上要处理大量的业务。必然会照成很多问题。这时我们先做预热，将系统的redis‘先启动到minIdle级别。
大致流程
我们做预热把redis连接启动至minIdle设置的个数。如果有更多的连接进来，则继续添加连接。如果连接个数超过maxIdle后，超出的那部分会在执行完业务逻辑没被使用后，慢慢的被关掉，至于小于maxIdle那部分就会长期存活着。如果连接数达到maxIdle时就不会新增连接数。
redis过期建三种清除策略
1、被动删除：过期的key触发惰性删除(等到执行getkey操作时，才删除key)。
不合理之处：大量冷数据不能被及时删除。
2、主动删除：过期的key，redis自己设定定时任务，执行定时任务时将这些数据删除掉。
主动清除key的策略:

1. volatile-ttl：在筛选时，会针对设置了过期时间的键值对，根据过期时间的先后进行删
2. volatile-random：就像它的名称一样，在设置了过期时间的键值对中，进行随机删除。
3. volatile-lru：会使用 LRU 算法筛选设置了过期时间的键值对删除。
4. volatile-lfu：会使用 LFU 算法筛选设置了过期时间的键值对删除。
5. allkeys-random：从所有键值对中随机选择并删除数据。
6. allkeys-lru：使用 LRU 算法在所有数据中进行筛选删除。
7. allkeys-lfu：使用 LFU 算法在所有数据中进行筛选删除。
8. noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error)
   LRU算法：淘汰很久没有被访问过的数据。(热点数据，我们平常都使用这总算法)
   LFU算法：近期访问最少的数据。(周期性，批量处理的数据使用这种算法)