redis 查看过期时间 redis查看过期时间命令

Redis 配置过期自动删除策略

Redis的过期删除策略： 惰性删除 和 定期删除 两种策略配合使用。

Redis作是基于内存的，大小有限。当内找到配置 maxmemory-policy 默认被注释 生效策略 noevictionl存不足或占用过高时，需要自动放弃一些未到期的数据

redis 查看过期时间 redis查看过期时间命令

缓存击穿是指一个请求要访问的数据，缓存中没有，但数据库中有的情况。这种情况一般都是缓存过期了。

Redis 默认 的生效的配置为 noeviction ，需要根据不同的业务选择不同的淘汰策略

volatile-lru：在设置过期时间的数据里淘汰最近访问最少的数据

volatile-lfu：在设置过期时间的数据里淘汰访问频率的数据

allkeys-lfu：所有数据中淘汰访问频率的数据

volatile-random：在设置过期时间的数据里，随机淘汰

allkeys-random：在所有的数据随机淘汰

volatile-ttl：在设置过期时间的数据里，淘汰剩余存活时间 (TTL) 最少的数据

我这里越久的数据价值越低，不在乎调用次数。所以选择

volatile-ttl

保存

重启redis 生效

redis常见问题

就是在数据库即使没有查询到数据，我们也把这次请求当做 key 缓存起来，value 可以是 NULL。下次同样请求就会命中这个 NULL，缓存层就处理了这个请求，不会对数据库产生压力。这样实现起来简单，开发成本很低。

1. 缓存击穿

针对这个场景，对应的解决方案一般来说有三种。

但是这时由于并发访问这个缓存的用户特别多，这是一个热点 key，这么多用户的请求同时过来，在缓存里面没有取到数据，所以又同时去访问数据库取数据，引起数据库流量激增，压力瞬间增大，直接崩溃给你看。

allkeys-lru：所有数据中淘汰最近访问最少的数据

所以一个数据有缓存，每次请求都从缓存中快速的返回了数据，但是某个时间点缓存失效了，某个请求在缓存中没有请求到数据，这时候我们就说这个请求就"击穿"了缓存。

后台开一个定时任务，专门主动更新过期数据

比如程序中设置 why 这个热点 key 的时候，同时设置了过期时间为 10 分钟，那后台程序在第 8 分钟的时候，会去数据库查询数据并重新放到缓存中，同时再次设置缓存为 10 分钟。

其实上面的后台续命思想的最终体现是也是过期。

只是后台续命的思想，会主动更新缓存，适用于缓存会变的场景。会出现缓存不一致的情况，取决于你的业务场景能接受多长时间的缓存不一致。

2. 缓存穿透

缓存穿透是指一个请求要访问的数据，缓存和数据库中都没有，而用户短时间、高密度的发起这样的请求，每次都打到数据库服务上，给数据库造成了压力。一般来说这样的请求属于恶意请求。

解决方案有两种：

3. 缓存雪崩

缓存雪崩是指缓存中大多数的数据在同一时间到达过期时间，而查询数据量巨大，这时候，又是缓存中没有，数据库中有的情况了。

防止雪崩的方案简单来说就是错峰过期。

在设置 key 过期时间的时候，在加上一个短的随机过期时间，这样就能避免大量缓存在同一时间过期，引起的缓存雪崩。

如果发了雪崩，我们可以有服务降级、熔断、限流手段来拒绝一些请求，保证服务的正常。但是，这些对用户体验是有一定影响的。

4. Redis 高可用架构

哨兵模式：

它主要执行三种类型的任务：

哨兵其实也是一个分布式系统，我们可以运行多个哨兵。

然后这些哨兵之间需要相互通气，交流信息，通过投票来决定是否执行自动故障迁移，以及选择哪个从作为新的主。

哨兵之间采用的协议是 gossip，是一种去中心化的协议，达成的是最终一致性。

选举规则：

Redis过期删除策略和内存淘汰策略

noevictionl：当内存不足以写入新数据时，拒绝新数据写入。Redis 默认策略

Redis可以用使用 expire 指令设置过期时间，在Redis内部，每当我们设置一个键的过期时间时，Redis就会将该键带上过期时间存放到一个过期字典中。当我们查询一个键时，Redis便首先检查该键是否存在过期字典中，如果存在，那就获取其过期时间。然后将过期时间和当前系统时间进行比对，比系统时间大，那就没有过期；反之判定该键过期。

那对于过期数据，一般有三种方式进行处理：

spring-boot-starter-data-redis 包中提供了过期的类，对于key过期，需要得到通知，做业务处理的，可以做此。

springboot整合Redis参考， SpringBoot整合Redis - (jianshu)

REFRESH ：用来存放refreshToken在整合Redis的基础上，在新加配置

配置类

类

将Redis用作缓存时，如果内存空间用满，就会自动驱逐老Redis 高可用架构，大家基本上都能想到主从、哨兵、集群这三种模式。的数据。

Redis中有6种淘汰策略：

redis.conf 文件中配置策略，有2个地方：

RedisTokenStore 源码解析 以及内存泄漏问题

client_id_to_access 和 uname_to_access 使用的是set，众所周知redis的set的过期时间是按照整个key来设置的；

前端时间，正好在做公司权限相关的架构问题，然后选择了Spring OAuth2来作为公司权限框架，先记录下目前遇到原生问题吧，后续有时间再来整理这个框架的整体脉络；

我们先来看下缓存到redis中有哪些key

ACCESS ：用来存放 AccessToken 对象（登录的token值，还有登录过期时间，token刷新值）

AUTH_TO_ACCESS ：缓存的也是AccessToken 对象，是可以根据用户名和client_id来查找当前用户的AccessToken

AUTH ：用来存放用户信息（OAuth2Authentication），有权限信息，用户信息等

ACCESS_TO_REFRESH ：可以根据该值，通过AccessToken找到refreshToken

REFRESH_TO_ACCESS ：根据re借助Redis setNX命令设置一个标志位就行。设置成功的放行，设置失败的就轮询等待。就是在更新缓存时加把锁freshToken来找到AccessToken

CLIENT_ID_TO_ACCESS ：存放当前client_id有多少AccessToken

UNAME_TO_ACCESS ：当没有做单点登录的话，可以使用该key，根据用户名查找当前用户有多少AccessToken可以使用

根据client_id和用户名，来获取当前用户的accessToken，如果缓存中的OAuth2Authentication已经过期，或者雷勇有变化，则会重新更新缓存；

缓存OAuth2AccessToken 和 OAuth2Authentication 对象，该方法主要在登录时调用，会把上面说的所有key值都缓存起来；

再看下，移除accessToken时

目前主要是看这几个方法，其他方法也挺简单的，主要是一些redis缓存作的；

每次登陆时，会先根据client_id和用户名去缓存中查找是否有可使用的AccessToken，如果有则返回缓存中的值，没有则生成新的；

所以每次登陆都会往这两个中放入新的accessToken，如果当某个用户在AccessToken有效期内没有作，则当前用户的登陆信息会被动下线，access 和 auth 中缓存的值都会过期，再次登陆时就查找不到了；

但是如果当前平台用户量不小，那么一直都会有人作，client_id_to_access 这个就会一直续期，那么过期了的accessToken就会一直存在该中，且不会减少，造成内存泄漏；

1.自己实现TokenStore，修改client_iRedisTokenStore 主要是来做token持久化到redis的工具类d_to_access 数据结构

2.写个定时任务，定期扫描client_id_to_access ，清除掉已经过期的token

3.如果不需要知道当前有哪些用户登录，或者该功能已经用了其他方式实现的，可以直接去掉这两个redis key