Redis进阶

发表于： 分类于：
字数： 7499 阅读：≈ 15分钟 浏览： 评论：

Redis是什么？

Redis是一个使用 C 语言编写的，高性能非关系型的键值对数据库。与传统数据库不同的是，Redis 的数据是存在内存中的，所以读写速度非常快，被广泛应用于缓存方向。Redis可以将数据写入磁盘中，保证了数据的安全不丢失，而且Redis的操作是原子性的。

Redis事务

事务的原理是将一个事务范围内的若干命令发送给Redis，然后再让Redis依次执行这些命令。

事务的生命周期：

使用MULTI开启一个事务 在开启事务的时候，每次操作的命令将会被插入到一个队列中，同时这个命令并不会被真的执行 EXEC命令进行提交事务

Redis事务支持隔离性吗？

Redis 是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执行完所有事务队列中的命令为止。因此，Redis 的事务是总是带有隔离性的。

Redis事务保证原子性吗，支持回滚吗？

Redis单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。

持久化机制

持久化就是把内存的数据写到磁盘中，防止服务宕机导致内存数据丢失。

Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。前者会根据指定的规则定时将内存中的数据存储在硬盘上，而后者在每次执行完命令后将命令记录下来。一般将两者结合使用。

RDB持久化

是 Redis 默认的持久化方案。RDB持久化时会将内存中的数据写入到磁盘中，在指定目录下生成一个文件。Redis 重启会加载文件恢复数据。

  1. 执行BGSAVE命令
  2. Redis 父进程判断当前是否存在正在执行的子进程，如果存在，BGSAVE命令直接返回。
  3. 父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞。
  4. 父进程fork完成后，父进程继续接收并处理客户端的请求，而子进程开始将内存中的数据写进硬盘的临时文件；
  5. 当子进程写完所有数据后会用该临时文件替换旧的 RDB 文件。

触发 RDB 持久化的方式：

手动触发：用户执行SAVE或BGSAVE命令。SAVE命令执行快照的过程会阻塞所有客户端的请求，应避免在生产环境使用此命令。BGSAVE命令可以在后台异步进行快照操作，快照的同时服务器还可以继续响应客户端的请求，因此需要手动执行快照时推荐使用BGSAVE命令。

被动触发：根据配置规则进行自动快照，如SAVE 100 10，100秒内至少有10个键被修改则进行快照。 如果从节点执行全量复制操作，主节点会自动执行BGSAVE生成 RDB 文件并发送给从节点。 默认情况下执行shutdown命令时，如果没有开启 AOF 持久化功能则自动执行·BGSAVE·。

优点： Redis 加载 RDB 恢复数据远远快于 AOF 的方式。 使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 Redis 的高性能。

缺点： RDB方式数据无法做到实时持久化。因为BGSAVE每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本比较高。 RDB 文件使用特定二进制格式保存，Redis 版本升级过程中有多个格式的 RDB 版本，存在老版本 Redis 无法兼容新版 RDB 格式的问题。

AOF持久化

AOF（append only file）持久化：以独立日志的方式记录每次写命令，Redis重启时会重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，AOF 是Redis持久化的主流方式。

默认情况下Redis没有开启AOF方式的持久化，可以通过参数启用。开启AOF方式持久化后每执行一条写命令，Redis就会将该命令写进缓冲区，AOF缓冲区根据对应的策略向硬盘做同步操作。

默认情况下系统每30秒会执行一次同步操作。为了防止缓冲区数据丢失，可以在Redis写入AOF文件后主动要求系统将缓冲区数据同步到硬盘上。可以通过参数设置同步的时机。

appendfsync always //每次写入aof文件都会执行同步，最安全最慢，不建议配置 appendfsync everysec //既保证性能也保证安全，建议配置 appendfsync no //由操作系统决定何时进行同步操作

  1. 所有的写入命令会追加到 AOP 缓冲区中。
  2. AOF 缓冲区根据对应的策略向硬盘同步。
  3. 随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩文件体积的目的。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。
  4. 当 Redis 服务器重启时，可以加载 AOF 文件进行数据恢复。

优点： AOF可以更好的保护数据不丢失，可以配置 AOF 每秒执行一次fsync操作，如果Redis进程挂掉，最多丢失1秒的数据。 AOF以append-only的模式写入，所以没有磁盘寻址的开销，写入性能非常高。

缺点： 对于同一份文件AOF文件比RDB数据快照要大。 数据恢复比较慢。

RDB和AOF如何选择？

通常来说，应该同时使用两种持久化方案，以保证数据安全。

如果数据不敏感，且可以从其他地方重新生成，可以关闭持久化。

如果数据比较重要，且能够承受几分钟的数据丢失，比如缓存等，只需要使用RDB即可。

如果是用做内存数据，要使用Redis的持久化，建议是RDB和AOF都开启。

如果只用AOF，优先使用everysec的配置选择，因为它在可靠性和性能之间取了一个平衡。

当RDB与AOF两种方式都开启时，Redis会优先使用AOF恢复数据，因为AOF保存的文件比RDB文件更完整。

Redis有哪些部署方案？

  1. 单机版：单机部署，单机redis能够承载的 QPS 大概就在上万到几万不等。这种部署方式很少使用。存在的问题：1、内存容量有限 2、处理能力有限 3、无法高可用。

  2. 主从模式：一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容，支撑读高并发。master 节点挂掉后，需要手动指定新的 master，可用性不高，基本不用。

  3. 哨兵模式：主从复制存在不能自动故障转移、达不到高可用的问题。哨兵模式解决了这些问题。通过哨兵机制可以自动切换主从节点。master 节点挂掉后，哨兵进程会主动选举新的 master，可用性高，但是每个节点存储的数据是一样的，浪费内存空间。数据量不是很多，集群规模不是很大，需要自动容错容灾的时候使用。

  4. Redis cluster(集群)：服务端分片技术，3.0版本开始正式提供。Redis Cluster并没有使用一致性hash，而是采用slot(槽)的概念，一共分成16384个槽。将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行。主要是针对海量数据+高并发+高可用的场景，如果是海量数据，如果你的数据量很大，那么建议就用Redis cluster，所有主节点的容量总和就是Redis cluster可缓存的数据容量。

主从架构

单机的 redis，能够承载的 QPS 大概就在上万到几万不等。对于缓存来说，一般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构，一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容，支撑读高并发。

Redis的复制功能是支持多个数据库之间的数据同步。主数据库可以进行读写操作，当主数据库的数据发生变化时会自动将数据同步到从数据库。从数据库一般是只读的，它会接收主数据库同步过来的数据。一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。

主从复制的原理？

  1. 当启动一个从节点时，它会发送一个 PSYNC 命令给主节点；
  2. 如果是从节点初次连接到主节点，那么会触发一次全量复制。此时主节点会启动一个后台线程，开始生成一份 RDB 快照文件；
  3. 同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB 文件生成完毕后， 主节点会将RDB文件发送给从节点，从节点会先将RDB文件写入本地磁盘，然后再从本地磁盘加载到内存中；
  4. 接着主节点会将内存中缓存的写命令发送到从节点，从节点同步这些数据；
  5. 如果从节点跟主节点之间网络出现故障，连接断开了，会自动重连，连接之后主节点仅会将部分缺失的数据同步给从节点。

哨兵模式

主从复制存在不能自动故障转移、达不到高可用的问题。哨兵模式解决了这些问题。通过哨兵机制可以自动切换主从节点。

客户端连接Redis的时候，先连接哨兵，哨兵会告诉客户端Redis主节点的地址，然后客户端连接上Redis并进行后续的操作。当主节点宕机的时候，哨兵监测到主节点宕机，会重新推选出某个表现良好的从节点成为新的主节点，然后通过发布订阅模式通知其他的从服务器，让它们切换主机。

哨兵Sentinel的原理？

  • 每个Sentinel以每秒钟一次的频率向它所知道的Master，Slave以及其他 Sentinel实例发送一个 PING命令。
  • 如果一个实例距离最后一次有效回复 PING 命令的时间超过指定值， 则这个实例会被 Sentine 标记为主观下线。
  • 如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel要以每秒一次的频率确认Master是否真正进入主观下线状态。
  • 当有足够数量的 Sentinel（大于等于配置文件指定值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 。若没有足够数量的 Sentinel同意 Master 已经下线， Master 的客观下线状态就会被解除。 若 Master重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
  • 哨兵节点会选举出哨兵 leader，负责故障转移的工作。
  • 哨兵 leader 会推选出某个表现良好的从节点成为新的主节点，然后通知其他从节点更新主节点信息。

Redis cluster

哨兵模式解决了主从复制不能自动故障转移、达不到高可用的问题，但还是存在主节点的写能力、容量受限于单机配置的问题。而cluster模式实现了Redis的分布式存储，每个节点存储不同的内容，解决主节点的写能力、容量受限于单机配置的问题。

Redis cluster集群节点最小配置6个节点以上（3主3从），其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。

Redis cluster采用虚拟槽分区，所有的键根据哈希函数映射到0～16383个整数槽内，每个节点负责维护一部分槽以及槽所映射的键值数据。

工作原理

  1. 通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽(哈希值)区间的数据，默认分配了16384 个槽位
  2. 每份数据分片会存储在多个互为主从的多节点上
  3. 数据写入先写主节点，再同步到从节点(支持配置为阻塞同步)
  4. 同一分片多个节点间的数据不保持一致性
  5. 读取数据时，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点
  6. 扩容时需要把旧节点的数据迁移一部分到新节点

在 redis cluster 架构下，每个 redis 要放开两个端口号，比如一个是 6379，另外一个就是 加1w 的端口号，比如 16379。

16379 端口号是用来进行节点间通信的，也就是 cluster bus 的东西，cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

优点：

  1. 无中心架构，支持动态扩容；
  2. 数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布；
  3. 高可用性。部分节点不可用时，集群仍可用。集群模式能够实现自动故障转移（failover），节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色转换。

缺点：

  1. 不支持批量操作（pipeline）。
  2. 数据通过异步复制，不保证数据的强一致性。
  3. 事务操作支持有限，只支持多key在同一节点上的事务操作，当多个key分布于不同的节点上时无法使用事务功能。
  4. key作为数据分区的最小粒度，不能将一个很大的键值对象如hash、list等映射到不同的节点。
  5. 不支持多数据库空间，单机下的Redis可以支持到16个数据库，集群模式下只能使用1个数据库空间。
  6. 只能使用0号数据库。

过期键的删除策略？

  1. 被动删除。在访问key时，如果发现key已经过期，那么会将key删除。

  2. 主动删除。定时清理key，每次清理会依次遍历所有DB，从db随机取出20个key，如果过期就删除，如果其中有5个key过期，那么就继续对这个db进行清理，否则开始清理下一个db。

  3. 内存不够时清理。Redis有最大内存的限制，通过maxmemory参数可以设置最大内存，当使用的内存超过了设置的最大内存，就要进行内存释放， 在进行内存释放的时候，会按照配置的淘汰策略清理内存。

内存淘汰策略有哪些？

当Redis的内存超过最大允许的内存之后，Redis 会触发内存淘汰策略，删除一些不常用的数据，以保证Redis服务器正常运行。

Redis v4.0前提供 6 种数据淘汰策略：

  1. volatile-lru：LRU（Least Recently Used），最近使用。利用LRU算法移除设置了过期时间的key
  2. allkeys-lru：当内存不足以容纳新写入数据时，从数据集中移除最近最少使用的key
  3. volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰
  4. volatile-random：从已设置过期时间的数据集中任意选择数据淘汰
  5. allkeys-random：从数据集中任意选择数据淘汰
  6. no-eviction：禁止删除数据，当内存不足以容纳新写入数据时，新写入操作会报错

Redis v4.0后增加以下两种：

  1. volatile-lfu：LFU，Least Frequently Used，最少使用，从已设置过期时间的数据集中挑选最不经常使用的数据淘汰。
  2. allkeys-lfu：当内存不足以容纳新写入数据时，从数据集中移除最不经常使用的key。 内存淘汰策略可以通过配置文件来修改

如何保证缓存与数据库双写时的数据一致性？

1、先删除缓存再更新数据库

进行更新操作时，先删除缓存，然后更新数据库，后续的请求再次读取时，会从数据库读取后再将新数据更新到缓存。

存在的问题：删除缓存数据之后，更新数据库完成之前，这个时间段内如果有新的读请求过来，就会从数据库读取旧数据重新写到缓存中，再次造成不一致，并且后续(下次更新前)读的都是旧数据。

2、先更新数据库再删除缓存

进行更新操作时，先更新MySQL，成功之后，删除缓存，后续读取请求时再将新数据回写缓存。

存在的问题：更新MySQL和删除缓存这段时间内，请求读取的还是缓存的旧数据，不过等数据库更新完成，就会恢复一致，影响相对比较小。

3、异步更新缓存

数据库的更新操作完成后不直接操作缓存，而是把这个操作命令封装成消息扔到消息队列中，然后由Redis自己去消费更新数据，消息队列可以保证数据操作顺序一致性，确保缓存系统的数据正常。

以上几个方案都不完美，需要根据业务需求，评估哪种方案影响较小，然后选择相应的方案。

缓存常见问题

缓存穿透

缓存穿透是指查询一个不存在的数据，由于缓存是不命中时被动写的，如果从DB查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到DB去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了。

怎么解决？

缓存空值，不会查数据库。 采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，查询不存在的数据会被这个bitmap拦截掉，从而避免了对DB的查询压力。 布隆过滤器的原理：当一个元素被加入集合时，通过K个哈希函数将这个元素映射成一个位数组中的K个点，把它们置为1。查询时，将元素通过哈希函数映射之后会得到k个点，如果这些点有任何一个0，则被检元素一定不在，直接返回；如果都是1，则查询元素很可能存在，就会去查询Redis和数据库。

布隆过滤器一般用于在大数据量的集合中判定某元素是否存在。

缓存雪崩

缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重挂掉。

解决方法：

在原有的失效时间基础上增加一个随机值，使得过期时间分散一些。这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。 加锁排队可以起到缓冲的作用，防止大量的请求同时操作数据库，但它的缺点是增加了系统的响应时间，降低了系统的吞吐量，牺牲了一部分用户体验。当缓存未查询到时，对要请求的 key 进行加锁，只允许一个线程去数据库中查，其他线程等候排队。 设置二级缓存。二级缓存指的是除了 Redis 本身的缓存，再设置一层缓存，当 Redis 失效之后，先去查询二级缓存。例如可以设置一个本地缓存，在 Redis 缓存失效的时候先去查询本地缓存而非查询数据库。

缓存击穿

缓存击穿：大量的请求同时查询一个 key 时，此时这个 key 正好失效了，就会导致大量的请求都落到数据库。缓存击穿是查询缓存中失效的 key，而缓存穿透是查询不存在的 key。

解决方法：

1、加互斥锁。在并发的多个请求中，只有第一个请求线程能拿到锁并执行数据库查询操作，其他的线程拿不到锁就阻塞等着，等到第一个线程将数据写入缓存后，直接走缓存。可以使用Redis分布式锁实现

2、热点数据不过期。直接将缓存设置为不过期，然后由定时任务去异步加载数据，更新缓存。这种方式适用于比较极端的场景，例如流量特别特别大的场景，使用时需要考虑业务能接受数据不一致的时间，还有就是异常情况的处理，保证缓存可以定时刷新。

缓存预热

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

解决方案：

直接写个缓存刷新页面，上线时手工操作一下； 数据量不大，可以在项目启动的时候自动进行加载； 定时刷新缓存；

缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

缓存降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级； 警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警； 错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级； 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。 服务降级的目的，是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis出现问题，不去数据库查询，而是直接返回默认值给用户。