Redis

EmiyaCC 于 2021-06-24 发布

Redis 是什么？都有哪些使用场景？

Redis 是一个开源的、基于内存、支持多种数据结构的存储系统，是个可持久化的日志型、Key-Value数据库，并提供多种语言的API，也可以作为缓存和消息中间件。

它支持的数据结构有字符串（strings）、哈希（hashes）、列表（lists）、集合（sets）、有序集合（sorted sets）等，除此之外还支持 bitmaps、hyperloglogs 和地理空间（ geospatial ）索引半径查询等功能。

Redis 使用场景：

Redis 有哪些功能？

Redis 数据类型及底层实现

图解redis五种数据结构底层实现

Redis 的架构及应用实践

  1. 持久化
  2. 主从
  3. 哨兵
  4. 集群

Redis架构原理及应用实践

Redis 和 memecache 有什么区别？

Redis 为什么是单线程的？

因为 cpu 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是机器内存或者网络带宽。既然单线程容易实现，而且 cpu 又不会成为瓶颈，那就顺理成章地采用单线程的方案了。

关于 Redis 的性能，官方网站也有，普通笔记本轻松处理每秒几十万的请求。

而且单线程并不代表就慢 nginx 和 nodejs 也都是高性能单线程的代表。

为什么Redis单线程模型效率也能那么高？

Redis为什么这么快

压缩表为什么可以节省内存

ziplist 虽然不维护前后节点的指针，但是它却维护了上一个节点的长度和当前节点的长度，然后每次通过长度来计算出前后节点的位置。

而在 Redis 中，一个指针是占了 8 个字节，但是大部分情况下，如果直接存储长度是达不到 8 个字节的，所以采用存储长度的设计方式在大部分场景下是可以节省内存空间的。

牺牲速度来节省内存，Redis是觉得自己太快了吗

Redis 有什么优点和缺点

介绍下 Redis 集群

集群有三种模式：主从复制模式、哨兵模式、Cluster 模式

主从复制模式：

Redis集群主从复制

主从复制作用：

通过持久化功能，Redis保证了即使在服务器重启的情况下也不会丢失（或少量丢失）数据，因为持久化会把内存中数据保存到硬盘上，重启会从硬盘上加载数据。 但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。

为了避免单点故障，通常的做法是将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务。

为此， Redis 提供了复制（replication）功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。

在复制的概念中，数据库分为两类，一类是主数据库（master），另一类是从数据库(slave）。主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。

主从复制原理：

Redis集群主从复制原理

  • 从数据库启动成功后，连接主数据库，发送 SYNC 命令；
  • 主数据库接收到 SYNC 命令后，开始执行 BGSAVE 命令生成 RDB 文件并使用缓冲区记录此后执行的所有写命令；
  • 主数据库 BGSAVE 执行完后，向所有从数据库发送快照文件，并在发送期间继续记录被执行的写命令；
  • 从数据库收到快照文件后丢弃所有旧数据，载入收到的快照；
  • 主数据库快照发送完毕后开始向从数据库发送缓冲区中的写命令；
  • 从数据库完成对快照的载入，开始接收命令请求，并执行来自主数据库缓冲区的写命令；（从数据库初始化完成）
  • 主数据库每执行一个写命令就会向从数据库发送相同的写命令，从数据库接收并执行收到的写命令（从数据库初始化完成后的操作）
  • 出现断开重连后，2.8之后的版本会将断线期间的命令传给重数据库，增量复制。
  • 主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。Redis 的策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

主从复制优缺点：

优点：

缺点：

Sentinel（哨兵）模式：

第一种主从同步/复制的模式，当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

哨兵模式是一种特殊的模式，首先 Redis 提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个 Redis 实例。

Redis集群哨兵模式.png

然而一个哨兵进程对Redis服务器进行监控，也可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

Redis集群多哨兵模式.png

故障切换的过程：

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行 failover 过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行 failover 操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。

作用：

哨兵模式的工作方式：

哨兵模式的优缺点：

优点：

缺点：

redis哨兵模式选举机制：

  1. 故障节点主观下线
  2. 故障节点客观下线
  3. Sentinel集群选举Leader
    • 节点确认主观下线就拉票
  4. Sentinel Leader决定新主节点
    • 过滤故障的节点
    • 选择优先级slave-priority最大的从节点作为主节点，如不存在则继续
    • 选择复制偏移量（数据写入量的字节，记录写了多少数据。主服务器会把偏移量同步给从服务器，当主从的偏移量一致，则数据是完全同步）最大的从节点作为主节点，如不存在则继续
    • 选择runid（redis每次启动的时候生成随机的runid作为redis的标识）最小的从节点作为主节点

redis哨兵模式选举机制

Cluster 集群模式（Redis官方）：

Redis Cluster是一种服务器 Sharding 技术，3.0版本开始正式提供。

Redis 的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台 Redis 服务器都存储相同的数据，很浪费内存，所以在 redis3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的内容

Redis集群Cluster集群模式

在这个图中，每一个蓝色的圈都代表着一个 redis 的服务器节点。它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。

集群的数据分片：

Redis 集群没有使用一致性 hash，而是引入了哈希槽【hash slot】的概念。

Redis 集群有16384 个哈希槽，每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽。集群的每个节点负责一部分hash槽，举个例子，比如当前集群有3个节点，那么：

这种结构很容易添加或者删除节点。比如如果我想新添加个节点 D ， 我需要从节点 A， B， C 中得部分槽到 D 上。如果我想移除节点 A ，需要将 A 中的槽移到 B 和 C 节点上，然后将没有任何槽的 A 节点从集群中移除即可。由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。

在 Redis 的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是 cluster，可以理解为是一个集群管理的插件。当我们的存取的 Key到达的时候，Redis 会根据 CRC16 的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

Redis 集群的主从复制模型：

为了保证高可用，redis-cluster集群引入了主从复制模型，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点 ping 一个主节点 A 时，如果半数以上的主节点与 A 通信超时，那么认为主节点 A 宕机了。如果主节点 A 和它的从节点 A1 都宕机了，那么该集群就无法再提供服务了。

集群的特点：

你了解 Redis 的三种集群模式吗？

缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级

  1. 缓存雪崩：

    问题描述：我们可以简单的理解为：由于原有缓存失效，新缓存未到期间 (例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃

    解决方法：大多数系统设计者考虑用加锁（最多的解决方案）或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。还有一个简单方案就时讲缓存失效时间分散开。

  2. 缓存穿透：

    问题描述：缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题

    解决方法：最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴。5TB的硬盘上放满了数据，请写一个算法将这些数据进行排重。如果这些数据是一些32bit大小的数据该如何解决？如果是64bit的呢？对于空间的利用到达了一种极致，那就是Bitmap和布隆过滤器(Bloom Filter)。Bitmap：典型的就是哈希表缺点是，Bitmap对于每个元素只能记录1bit信息，如果还想完成额外的功能，恐怕只能靠牺牲更多的空间、时间来完成了

  3. 缓存预热：

    问题描述：缓存预热这个应该是一个比较常见的概念，相信很多小伙伴都应该可以很容易的理解，缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据

    解决方法：1. 直接写个缓存刷新页面，上线时手工操作下； 2、数据量不大，可以在项目启动的时候自动进行加载； 3、定时刷新缓存；

  4. 缓存更新：

    除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：（1）定时去清理过期的缓存；（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡

  5. 缓存降级：

    当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。以参考日志级别设置预案：（1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；（2）警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；（3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；（4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。 服务降级的目的，是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis出现问题，不去数据库查询，而是直接返回默认值给用户

缓存失效的场景

热点数据是怎么加载到缓存中的

  1. 请求访问缓存，缓存没有则访问数据库，并同步写入缓存中
  2. 通过 淘汰机制 保证缓存中存放的都是热点数据
  3. 同时还需要保证 双写的一致性

怎么保证缓存和数据库数据的双写一致性？

从理论上来说，给缓存设置过期时间，是可以保证最终一致性的解决方案

接下来的方案是保障缓存与数据库数据能尽可能的更快一致：

  1. 先更新数据库，再更新缓存
  2. 先更新缓存，再更新数据库
  3. 先删除缓存，再更新数据库
  4. 先更新数据库，再删除缓存

上面四种都有点问题，可以采用第三种或者第四种方案，然后加上延时双删

当删除缓存这个操作失败，上面的措施就会出问题，这时候可以提供一个重试机制：1）利用消息队列；2）利用中间件

缓存读写策略

  1. 旁路缓存模式：比较适合读请求比较多的场景

    措施：先更新数据库，再删除缓存

    缺陷：

    1. 首次请求数据一定不在缓存中

      解决方法：热点数据提前放入缓存中

    2. 写操作比较频繁的话会导致缓存中的数据会被频繁的删除，影响缓存命中率

      解决方法：

      1. 数据库和缓存数据强一致性场景：更新数据库同时更新缓存，加分布式锁来保证更新缓存不存在线程安全问题
      2. 数据库和缓存数据弱一致性场景：更新数据库同时更新缓存，但是给缓存一个比较短的过期时间，这样保证即使数据不一致的话，影响也比较小

  2. 读写穿透

    措施：

    1. 写：先查缓存，缓存不存在，直接更新数据库；缓存中存在，先更新缓存，再缓存服务更新数据库
    2. 读：从缓存中读取数据，读取到就直接返回；读取不到就先从数据库加载，写入缓存再返回响应

  3. 异步缓存写入

    读写穿透不同的是，异步缓存写入则只更新缓存，不直接更新数据库，而是改为异步批量的方式来更新数据库

Redis 持久化有几种方式？

Redis 的持久化有两种方式，或者说有两种策略：

持久化有两种，那应该怎么选择呢？

  1. 不要仅仅使用 RDB ，因为那样会导致你丢失很多数据。
  2. 也不要仅仅使用 AOF ，因为那样有两个问题，第一，你通过 AOF 做冷备没有 RDB 做冷备的恢复速度更快; 第二， RDB 每次简单粗暴生成数据快照，更加健壮，可以避免 AOF 这种复杂的备份和恢复机制的 bug 。
  3. Redis 支持同时开启开启两种持久化方式，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。
  4. 如果同时使用 RDB 和 AOF 两种持久化机制，那么在 Redis 重启的时候，会使用 AOF 来重新构建数据，因为 AOF 中的数据更加完整。

什么情况下可能会导致 Redis 阻塞？

缓存和数据库谁先更新呢

实现分布式锁的方式

  1. 数据库锁：竞争表级资源和行级资源
  2. zookeeper 分布式锁：竞争文件资源。每个请求的客户端随机生成一个 id，id 最小的获得资源，使用完就删除该 id
  3. redis 的分布式锁：通过 setnx 竞争键值资源

几种分布式锁的实现方式

Redis 怎么实现分布式锁？

Redis 分布式锁其实就是在系统里面占一个“坑”，其他程序也要占“坑”的时候，占用成功了就可以继续执行，失败了就只能放弃或稍后重试。

占坑一般使用 setnx(set if not exists)指令，只允许被一个程序占有，使用完调用 del 释放锁。

扩展：分布式锁的实现之 Redis 篇

Redlock（redis分布式锁）原理分析- RGC - 博客园

Redis 分布式锁有什么缺陷？

Redis 分布式锁不能解决超时的问题，分布式锁有一个超时时间，程序的执行如果超出了锁的超时时间就会出现问题。

Redis 如何做内存优化？

尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。

比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面。

Redis 刷新策略

Redis过期key是怎么清理的?

Redis 淘汰策略有哪些？

Redis 常见的性能问题有哪些？该如何解决？

Reference: