1. 慢日志设置1234# 当命令耗时超过5毫秒时，记录慢日志CONFIG SET slowlog-log-slower-than 5000# 只保留最近500条慢日志CONFIG SET slowlog-max-len 500 2. 查看慢日志123456789101112131415127.0.0.1:6379> SLOWLOG get 51) 1) (integer) 32693 # 慢日志ID 2) (integer) 1593763337 # 执行时间戳 3) (integer) 5299 # 执行耗时(微秒) 4) 1) "LRANGE" # 具体执行的命令和参数 2) "user_list:2000" 3) "0" 4) "-1"2) 1) (integer) 32692 2) (integer) 1593763337 3) (integer) 5044 4) 1) "GET" 2) "user_info:1000"...

1. 缓存雪崩在短时间内本应交由 Redis 处理的大量请求，都发送到了数据库进行处理，从而导致对数据库的压力迅速增大，严重时数据库可能崩溃，从而导致整个系统崩溃，就像雪崩一样，引发连锁效应，所以叫缓存雪崩。 出现上述情况的常见原因主要有以下两点： 大量缓存数据同时过期，导致本应请求到缓存的需重新从数据库中获取数据。 redis 本身出现故障，无法处理请求，那自然会再请求到数据库那里。 针对大量缓存数据同时过期的情况： 实际设置过期时间时，应当尽量避免大量 key 同时过期的场景，如果真的有，那就通过随机、微调、均匀设置等方式设置过期时间，从而避免同一时间过期。 添加互斥锁，使得构建缓存的操作不会在同一时间进行。 双 key 策略，主 key 是原始缓存，备 key 为拷贝缓存，主 key 失效时，可以访问备 key，主 key 缓存失效时间设置为短期，备 key 设置为长期。 后台更新缓存策略，采用定时任务或者消息队列的方式进行 redis 缓存更新或移除等。 针对 Redis 本身出现故障的情况： 在预防层面，可以通过主从节点的方式构建高可用的集群，也就是实现主 Redis 实例挂掉后，能有其他从库快速切换为主库，继续提供服务。 如果事情已经发生了，那就要为了防止数据库被大量的请求搞崩溃，可以采用服务熔断或者请求限流的方法。当然服务熔断相对粗暴一些，停止服务直到 redis 服务恢复，请求限流相对温和一些，保证一些请求可以处理，不是一刀切，不过还是看具体业务情况选择合适的处理方案。