来个查漏补缺！关于 Redis 都在这一篇里了

Redis简介

Redis 是 C 语言开发的一个开源高性能键值对的内存数据库，可以用来做数据库、缓存、消息中间件等场景，是一种 NoSQL（not-only sql，非关系型数据库）的数据库。

Redis特点

优秀的性能，数据是存储在内存中，读写速度非常快，可支持并发10W QPS。

• 单线程但进程，是线程安全的，采用IO 多路复用制
• 可作为分布式锁
• 支持五种数据类型
• 支持数据持久化到磁盘

可以作为消息中间件使用，支持消息发布及订阅。

数据类型

下表是我列举的五种数据类型的特性及其使用场景

缓存

• 直接通过 RedisTemplate 使用
• 通过 Spring Cache 集成 Redis（也就是注解的方式）

使用缓存遇到的问题

（1）数据一致性

（2）缓存雪崩

这就是雪崩事件，是 Redis 缓存中最致命问题之一（有一个是穿透）。大家可以看看下图：

出现雪崩事件后不要急不要慌，我们可以在事故前中后三个方面来思考解决方案：

• 事故前：redis 高可用方案，主从+哨兵，集群方案，避免全盘崩溃；
• 事故中：较少数据库的压力，本地 Ehcache 缓存+限流及降级，避免超过数据库承受压力；
• 事故后：做 Redis 持久化，一旦 Redis 重启，可从磁盘中快速恢复数据。

我们来看看改造后的数据流程，假设用户A发送一个请求，系统先请求本地 Ehcache 是否有数据，如果没有再去 Redis 请求数据，如果没有再去数据库请求数据，获取到数据后同步到 Ehcache 和 redis。

这样做的好处是:

• 数据库安全：在限流组件可用的情况下，数据库不会挂掉，限流根据确保了每秒多少请求能通过；
• 部分请求可以被处理：数据库没挂，就意味着至少2/5的请求可以被处理掉；
• 高峰时期部分请求无法处理到，需要用户多次点击，因为只有 2/5 的请求被处理，剩下的请求，用户刷不出来界面，需要多点击几次；
• redis 设置的缓存失效时间不是设置成同一个时间，可根据功能、业务、请求接口灵活设置缓存时间：setRedis（key, value, time+Math.random()*10000）;

（3）缓存穿透

缓存穿透是指缓存和数据库中都没有的数据，用户（黑客）不断发起请求，导致请求直接查询数据库，这种恶意行为攻击场景的会直接导致数据库挂掉，数据流程如下图所示：

• 在请求接口层可以做一些校验，比如用户签权、参数校验，不合法的请求直接return；
• 还可以针对有效id做认证或直接拦截，不符合的 id 直接过滤或采用统一key保存到redis，下次不合法的id请求时，直接到缓存中获取数据；
• 采用 redis 的高级接口 Bloom Filter，利用高效的数据结构和算法快速判断出你这个 Key 是否在数据库中存在，不存在你 return 就好了，存在你就去查 DB 刷新 KV 再 return。

（4） 缓存击穿

上面讲的穿透是针对大面积数据请求，那么击穿是针对一点(一个key)来来导致redis异常，但某个key是非常热点，请求非常频繁，处于集中式访问现象，当这个key失效(过期)时，大量的请求就会击穿了缓存，直接请求数据库，就像在屏障中凿开了一个洞。

不同场景下缓存击穿解决方案

• 数据基本不变：热点数据value基本不更新时，可以设置成永不过期
• 数据更新不频繁：缓存刷新流程耗时较少时，可采用redis、zookeeper等分布式中间件的分布式互斥锁或者本地互斥锁保证少量的请求能请求到数据库并重新更新缓存，其他的流程等锁释放后才可以访问新缓存
• 数据更新频繁：采用定时线程，在缓存过期前主动重新构建缓存或延长过期时间，保证所有的请求能一直访问缓存

为什么Redis这么快

• 使用类似于 HashMap 的原理，HashMap 的查询及操作的时间复杂度是O(1)，且绝大多数请求是纯碎的内存操作，数据存在内存中；
• 数据结构简单，对数据操作也简单，基于KV；
• 不错死锁现象采用单线程操作，避免了不必要的上下文切换及竞争条件，不存在CPU切换现象，也就不存在考虑各种锁的问题；
• 使用非阻塞IO，多路复用IO模型。

Redis 淘汰策略

• volatile为前缀的策略都是从已过期的数据集中进行淘汰。
• allkeys为前缀的策略都是面向所有key进行淘汰。
• LRU（least recently used）最近最少用到的。
• LFU（Least Frequently Used）最不常用的。
• 它们的触发条件都是Redis使用的内存达到阈值时。

Redis持久化

Redis 持久化策略有两种：

• RDB：快照形式是直接把内存中的数据保存到一个 dump 的文件中，定时保存，保存策略。
• AOF：把所有的对 Redis 的服务器进行修改的命令都存到一个文件里，命令的集合。Redis 默认是快照 RDB 的持久化方式。

如果非常关心你的数据，但仍然可以承受数分钟内的数据丢失，那么可以额只使用 RDB 持久。

AOF 将 Redis 执行的每一条命令追加到磁盘中，处理巨大的写入会降低Redis的性能，不知道你是否可以接受。

数据库备份和灾难恢复：定时生成 RDB 快照非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度快。

当然了，Redis 支持同时开启 RDB 和 AOF，系统重启后，Redis 会优先使用 AOF 来恢复数据，这样丢失的数据会最少。

Redis主从复制

• 从节点执行 slaveof[masterIP][masterPort]，保存主节点信息；
• 从节点中的定时任务发现主节点信息，建立和主节点的 Socket 连接；
• 从节点发送 Ping 信号，主节点返回 Pong，两边能互相通信；
• 连接建立后，主节点将所有数据发送给从节点（数据同步）；
• 主节点把当前的数据同步给从节点后，便完成了复制的建立过程；

  接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

Redis哨兵模式

我们先说说主从复制会存在问题：

• 一旦主节点宕机，从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。
• 主节点的写能力受到单机的限制。
• 主节点的存储能力受到单机的限制。
• 原生复制的弊端在早期的版本中也会比较突出，比如：

  Redis 复制中断后，从节点会发起 psync。

• 此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时，可能会造成毫秒或秒级的卡顿。

哨兵的架构模式如下：

该系统可以执行以下四个任务：

• 监控：不断检查主服务器和从服务器是否正常运行。
• 通知：当被监控的某个 Redis 服务器出现问题，Sentinel 通过 API 脚本向管理员或者其他应用程序发出通知。
• 自动故障转移：当主节点不能正常工作时，Sentinel 会开始一次自动的故障转移操作，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点，这样人工干预就可以免了。
• 配置提供者：在 Redis Sentinel 模式下，客户端应用在初始化时连接的是 Sentinel 节点集合，从中获取主节点的信息。

来源：https://www.jianshu.com/p/0a1c9fc23c01