Redis简介

Redis

参考与这位大佬

定义:
redis 是一个用 C/C++ 开发的开源、高性能键值对的 Nosql 内存数据库。可用作数据库、缓存、消息中间件等

特点:

• 性能优秀，数据在内存中读写速度非常快，支持并发 10wQPS
• 单线程单进程，是线程安全的，采用 IO 多路复用机制
• 支持多种数据类型: 字符串(strings)、散列(hashes)、列表(lists)、集合(sets)、有序集合(sorted sets)
• 支持数据持久化，可将内存中数据存储到磁盘中，重启时加载
• 主从复制、哨兵、高可用
• 可用作分布式锁、消息中间件、发布订阅

使用:
引入依赖 spring boot starter data redis ，直接通过 RedisTemplate 来使用

数据一致性问题:
在做了缓存的情况下，请求获取数据时一般是先去缓存里查找，如果没有再去数据库中查找。数据一致性问题指的是缓存中的数据与数据库中的数据不一致的情况，一般分为两个场景:

• 正常情况下: 更新数据时，先更新数据库中数据，然后更新缓存，当更新缓存失败时，数据库中为新数据，缓存中为旧数据，这时就出现数据不一致情况
   解决办法: 先删除缓存，再更新数据库。这种情况下可先删除缓存中数据，再更新数据库，当获取数据请求发现缓存中没有时，从数据库获取到，再添加到缓存中
• 并发情况下: 当一个更新数据请求到达后，先删除缓存中的数据，再去更新数据库，当数据库更新未完成时另一个查询数据请求到达，发现缓存中没有，则从数据库中获取到，重新添加到缓存中，这时更新数据库完成，这就导致了数据库中为新数据，而缓存中为旧数据
   解决办法: 这里可以考虑用队列解决。根据要更新的数据唯一标志创建队列，当有更新请求时加入到队列中，同时如果有查询请求时，先去队列中查看是否有对应要查询数据的队列id，如果有，则将其也加入到队列中，待更新请求完成后再做查询

内存溢出问题

• 设置 key 过期时间
• 按需使用八种淘汰策略:
  volatile-lru(least recently used): 从已设置过期时间的数据集中挑选最近最少使用的数据淘汰
  volatile-lfu(least frequently used): 从已设置过期时间的数据集中挑选一段时间内使用频率最少的数据淘汰
  volatile-ttl(time to live): 从已设置过期时间的数据集中挑选将要过期的数据淘汰
  volatile-random: 从已设置过期时间的数据集中随机挑选数据淘汰
  allkeys-lru: 从数据集中挑选最近最少使用的数据淘汰
  allkeys-lfu: 从数据集中挑选一段时间内使用频率最少的数据淘汰
  allkeys-random: 从数据集中随机挑选数据淘汰
  no-eviction: 禁止驱逐，不采用任何淘汰策略，默认使用此设置

redis 雪崩:
描述: 更新缓存两种方式是定时任务更新和缓存中没有后查询到重新添加。定时任务更新就会出现雪崩情况。缓存中数据具有时效性，假如首页数据要在12点更新，也就是缓存数据的 key 12点失效，结果刚好12点有优惠活动出现大量请求，7000/s，然后 key 失效了，就相当于没有缓存，直接请求数据库，然后数据库必然扛不住，挂了。此时就会出现雪崩现象。
解决办法:

• 在添加数据时，给 key 的时间加上随机值，保证 key 不会在同一时间全部失效
• 如果 Redis 是集群部署，则可以将热点数据存放在多个 redis 中
• 对于热点数据不设置失效时间，更新时更新缓存（实际上电商首页就是这么做的）

缓存穿透:
缓存穿透指的是在缓存和数据库中没有数据的情况下，用户不断发起请求，由于缓存中没有数据，所以请求直接落在数据库上。比如用户用 id = -1请求数据
解决办法:

• 接口校验（权限验证、参数校验）
• 布隆过滤器（高级用法），利用高校的数据结构和算法判断 key 是否在数据库中存在

缓存击穿:
缓存击穿指的是对于某一个热点数据的 key，当这个 key 更新或失效时，瞬间有大量的请求到达，由于 key 失效，则直接访问数据库，导致数据库崩溃
解决办法:

• 将热点数据设置为永不过期
• 使用互斥锁

缓存击穿与雪崩的区别: 缓存击穿指的是一个 key 失效导致的数据库崩溃，雪崩指的是大量 key 失效导致数据库崩溃

持久化:

• RDB: 以快照形式将内存中的数据备份到一个二进制 dump 文件中，定时保存。优点是保存数据极快、还原数据极快，适用于灾难备份，缺点是持久化的数据不够完整，redis 默认使用 RDB 持久化
• AOF: 将对 redis 服务器修改操作的指令保存到一个 aof 文件中，命令的集合。优点是用 AOF 持久化的数据更完整，缺点是由于写入大量指令影响性能

注：当 Redis 同时使用 RDB 和 AOF 持久化数据时，重启后，优先选择 AOF 恢复数据，因为 AOF 持久化的数据更完整

先知而后行 行必有有所为
@