NoSQL概述

1. 为什么要用NoSQL

  1. 单机MySQL年代
    一个网站的访问量一般不会太大，单个数据库完全足够Redis面试问题 - 图1
  2. Memcached（缓存）+MySQL+垂直拆分（读写分离）
    主要解决读的压力
    网站80%发情况都是在读，每次都去查询数据库效率很低，为减轻压力，可以使用缓存来保证效率。
    发展过程：优化数据结构和索引 -> 文件缓存（IO）-> MemcachedRedis面试问题 - 图2
  3. 分库分表+水平拆分（MySQL集群）
    主要解决写的压力

Redis面试问题 - 图3

  1. 近些年
    用户的个人信息、社交网络、地理位置、用户日志等等爆发式增长，变化很快，某些时候MySQL等关系型数据库不够用，效率也低。

2. 什么是NoSQL

NoSQL = Not only SQL
泛指非关系型数据库。随着web2.0时代的到来，传统的关系型数据库很难对付现有的应用场景。很多数据类型，如用户的个人信息、地理位置等等，这些数据类型的存储不需要一个固定的格式，无需多余操作就可以横向拓展。

NoSQL特点：

  1. 方便拓展：数据之间没有关系，容易拓展
  2. 大数据量高性能：比如redis一秒可以写8万次，读取11万次

  3. 数据类型多样：不需要事先设计数据库，随取随用

    简单介绍一下 Redis 呗

    1. 是什么：

    Redis：REmote DIctionary Server（远程字典服务器）
    是完全开源免费的，用C语言编写的，遵守BSD协议，是一个高性能的（key-value）分布式内存数据库，基于内存运行，也支持持久化的NoSQL数据库，是当前最热门的NoSQL数据库之一，也被人们称为数据结构服务器。

    2. 能干什么：

  4. Redis最常用来做缓存，是实现分布式缓存的首选中间件；

  5. Redis可以作为数据库，实现诸如点赞、关注、排行等对性能要求极高的互联网需求；
  6. Redis可以作为计算工具，能用很小的代价，统计诸如PV/UV、用户在线天数等数据；
  7. Redis还有很多其他的使用场景，例如：可以实现分布式锁，可以作为消息队列使用。

    3. 三个特点：

  • 支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载使用
  • 不仅仅支持简单的key-value类型的数据（key和value都是string），value还支持list、set、zset、hash等数据结构的存储

  • 支持数据的备份，即master-slave模式的数据备份

    Redis和传统的关系型数据库有什么不同

  • Redis是一种基于键值对的NoSQL数据库，而键值对的值是由多种数据结构和算法组成的。Redis的数据都存储于内存中，因此它的速度惊人，读写性能可达10万/秒，远超关系型数据库。

  • 关系型数据库是基于二维数据表来存储数据的，它的数据格式更为严谨，并支持关联查询。关系型数据库的数据存储于磁盘上，可以存放海量的数据，但性能远不如Redis。

    分布式缓存常见的技术选型方案有哪些？

  • 分布式缓存的话，使用的比较多的主要是 Memcached 和 Redis。不过，现在基本没有看过还有项目使用 Memcached 来做缓存，都是直接用 Redis。

  • Memcached 是分布式缓存最开始兴起的那会，比较常用的。后来，随着 Redis 的发展，大家慢慢都转而使用更加强大的 Redis 了。
  • 分布式缓存主要解决的是单机缓存的容量受服务器限制并且无法保存通用的信息。因为，本地缓存只在当前服务里有效，比如如果你部署了两个相同的服务，他们两者之间的缓存数据是无法共用的。

    说一下 Redis 和 Memcached 的区别和共同点

    现在公司一般都是用 Redis 来实现缓存，而且 Redis 自身也越来越强大了！不过，了解 Redis 和 Memcached 的区别和共同点，有助于我们在做相应的技术选型的时候，能够做到有理有据！

共同点 ：

  1. 都是基于内存的数据库，一般都用来当做缓存使用。
  2. 都有过期策略。
  3. 两者的性能都非常高。

区别 ：

  1. Redis 支持更丰富的数据类型（支持更复杂的应用场景）。Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储。Memcached 只支持最简单的 k/v 数据类型。
  2. Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用，而 Memecache 把数据全部存在内存之中。
  3. Redis 有灾难恢复机制。 因为可以把缓存中的数据持久化到磁盘上。
  4. Redis 在服务器内存使用完之后，可以将不用的数据放到磁盘上。但是，Memcached 在服务器内存使用完之后，就会直接报异常。
  5. Memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是 Redis 目前是原生支持 cluster 模式的.
  6. Memcached 是多线程，非阻塞 IO 复用的网络模型；Redis 使用单线程的多路 IO 复用模型。 （Redis 6.0 引入了多线程 IO ）
  7. Redis 支持发布订阅模型、Lua 脚本、事务等功能，而 Memcached 不支持。并且Redis 支持更多的编程语言。
  8. Memcached 过期数据的删除策略只用了惰性删除，而 Redis 同时使用了惰性删除与定期删除。

相信看了上面的对比之后，我们已经没有什么理由可以选择使用 Memcached 来作为自己项目的分布式缓存了。

使用Redis应该注意什么？

  1. 冷热数据区分

虽然 Redis支持持久化，但将所有数据存储在 Redis 中，成本非常昂贵。建议将热数据 (如 QPS超过 5k) 的数据加载到 Redis 中。低频数据可存储在 Mysql、 ElasticSearch中。

  1. 业务数据分离

不要将不相关的业务数据都放到一个 Redis中。一方面避免业务相互影响，另一方面避免单实例膨胀，并能在故障时降低影响面，快速恢复。

  1. 消息大小限制

由于 Redis 是单线程服务，消息过大会阻塞并拖慢其他操作。保持消息内容在 1KB 以下是个好的习惯。严禁超过 50KB 的单条记录。消息过大还会引起网络带宽的高占用，持久化到磁盘时的 IO 问题。

  1. 连接数限制

连接的频繁创建和销毁，会浪费大量的系统资源，极限情况会造成宿主机宕机。请确保使用了正确的 Redis 客户端连接池配置。

  1. 缓存 Key 设置失效时间

作为缓存使用的 Key，必须要设置失效时间。失效时间并不是越长越好，请根据业务性质进行设置。注意，失效时间的单位有的是秒，有的是毫秒，这个很多同学不注意容易搞错。

  1. 扩展方式首选客户端 hash

如果应用太小就别考虑了，如单 redis 集群并不能为你的数据服务，不要着急扩大你的 redis 集群（包括 M/S 和 Cluster)，集群越大，在状态同步和持久化方面的性能越差。优先使用客户端 hash 进行集群拆分。如：根据用户 id 分 10 个集群，用户尾号为 0 的落在第一个集群。

  1. 建表规范

Redis 的 Key 一定要规范，这样在遇到问题时，能够进行方便的定位。Redis 属于无 scheme 的 KV 数据库，所以，我们靠约定来建立其 scheme 语义。
例如:MySQL的数据库名为vs，用户表名为user,那么对应的键可以用”vs:user:1”,”vs:user:1:name”来表示.
如果当前Redis只被一个业务使用，甚至可以去掉“vs:”。如果键名比较长,例如“user:{uid}:friends:messages:{mid}”，可以在能描述键含义的前提下适当减少键的长度，例如变为“u:{uid}:fr:m:{mid}”，从而减少由于键过长的内存浪费。

缓存数据的处理流程是怎样的？

Redis面试问题 - 图4

简单来说就是:

  1. 如果用户请求的数据在缓存中就直接返回。
  2. 缓存中不存在的话就看数据库中是否存在。
  3. 数据库中存在的话就更新缓存中的数据。
  4. 数据库中不存在的话就返回空数据。

    为什么要用 Redis/为什么要用缓存？

    简单来说使用缓存主要是为了提升用户体验以及应对更多的用户。
    下面我们主要从“高性能”和“高可用”这两点来看待这个问题。
    Redis面试问题 - 图5
  • 高性能 ：
    对照上面 👆 我画的图。我们设想这样的场景：
    假如用户第一次访问数据库中的某些数据的话，这个过程是比较慢，毕竟是从硬盘中读取的。但是，如果说，用户访问的数据属于高频数据并且不会经常改变的话，那么我们就可以很放心地将该用户访问的数据存在缓存中。
    这样有什么好处呢？ 那就是保证用户下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。
    不过，要保持数据库和缓存中的数据的一致性。 如果数据库中的对应数据改变的之后，同步改变缓存中相应的数据即可！

  • 高可用：
    一般像 MySQL 这类的数据库的 QPS 大概都在 1w 左右（4 核 8g） ，但是使用 Redis 缓存之后很容易达到 10w+，甚至最高能达到 30w+（就单机 redis 的情况，redis 集群的话会更高）。[QPS（Query Per Second）：服务器每秒可以执行的查询次数]
    所以，直接操作缓存能够承受的数据库请求数量是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。进而，我们也就提高的系统整体的并发。

    Redis 五大常见数据结构以及使用场景分析

    你可以自己本机安装 redis 或者通过 redis 官网提供的在线 redis 环境。
    1. string

  • 介绍 ：string 数据结构是简单的 key-value 类型。虽然 Redis 是用 C 语言写的，但是 Redis 并没有使用 C 的字符串表示，而是自己构建了一种 简单动态字符串（simple dynamic string，SDS）。相比于 C 的原生字符串，string类型是二进制安全的，意思是redis的string可以包含任何数据，比如图片或者序列化对象，并且获取字符串长度复杂度为 O(1)（C 字符串为 O(N)），除此之外，Redis 的 SDS API 是安全的，不会造成缓冲区溢出。

  • 常用命令：set, get, strlen, exists, decr, incr, setex 等等。
  • 应用场景 ：一般常用在需要计数的场景，比如用户的访问次数、热点文章的点赞转发数量等等。

普通字符串的基本操作：

  1. 127.0.0.1:6379> set key value #设置 key-value 类型的值
  2. OK
  3. 127.0.0.1:6379> get key # 根据 key 获得对应的 value
  4. "value"
  5. 127.0.0.1:6379> exists key  # 判断某个 key 是否存在
  6. (integer) 1
  7. 127.0.0.1:6379> strlen key # 返回 key 所储存的字符串值的长度。
  8. (integer) 5
  9. 127.0.0.1:6379> del key # 删除某个 key 对应的值
  10. (integer) 1
  11. 127.0.0.1:6379> get key
  12. (nil)

批量设置 :

127.0.0.1:6379> mset key1 value1 key2 value2 # 批量设置 key-value 类型的值
OK
127.0.0.1:6379> mget key1 key2 # 批量获取多个 key 对应的 value
1) "value1"
2) "value2"

计数器（字符串的内容为整数的时候可以使用）：

127.0.0.1:6379> set number 1
OK
127.0.0.1:6379> incr number # 将 key 中储存的数字值增一
(integer) 2
127.0.0.1:6379> get number
"2"
127.0.0.1:6379> decr number # 将 key 中储存的数字值减一
(integer) 1
127.0.0.1:6379> get number
"1"

过期：

127.0.0.1:6379> expire key  60 # 数据在 60s 后过期
(integer) 1
127.0.0.1:6379> setex key 60 value # 数据在 60s 后过期 (setex:[set] + [ex]pire)
OK
127.0.0.1:6379> ttl key # 查看数据还有多久过期
(integer) 56

2. list

  • 介绍 ：list 即是 链表。链表是一种非常常见的数据结构，特点是易于数据元素的插入和删除并且可以灵活调整链表长度，但是链表的随机访问困难。许多高级编程语言都内置了链表的实现比如 Java 中的 LinkedList，但是 C 语言并没有实现链表，所以 Redis 实现了自己的链表数据结构。Redis 的 list 的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销。
  • 常用命令：rpush, lpop, lpush, rpop, lrange, llen 等。
  • 应用场景：发布与订阅或者消息队列、慢查询。

通过 **rpush/lpop** 实现队列：

127.0.0.1:6379> rpush myList value1 # 向 list 的头部（右边）添加元素
(integer) 1
127.0.0.1:6379> rpush myList value2 value3 # 向list的头部（最右边）添加多个元素
(integer) 3
127.0.0.1:6379> lpop myList # 将 list的尾部(最左边)元素取出
"value1"
127.0.0.1:6379> lrange myList 0 1 # 查看对应下标的list列表， 0 为 start,1为 end
1) "value2"
2) "value3"
127.0.0.1:6379> lrange myList 0 -1 # 查看列表中的所有元素，-1表示倒数第一
1) "value2"
2) "value3"

通过 **rpush/rpop** 实现栈：

127.0.0.1:6379> rpush myList2 value1 value2 value3
(integer) 3
127.0.0.1:6379> rpop myList2 # 将 list的头部(最右边)元素取出
"value3"

我专门画了一个图方便小伙伴们来理解：

Redis面试问题 - 图6

通过 **lrange** 查看对应下标范围的列表元素：

127.0.0.1:6379> rpush myList value1 value2 value3
(integer) 3
127.0.0.1:6379> lrange myList 0 1 # 查看对应下标的list列表， 0 为 start,1为 end
1) "value1"
2) "value2"
127.0.0.1:6379> lrange myList 0 -1 # 查看列表中的所有元素，-1表示倒数第一
1) "value1"
2) "value2"
3) "value3"

通过 lrange 命令，你可以基于 list 实现分页查询，性能非常高！

通过 **llen** 查看链表长度：

127.0.0.1:6379> llen myList
(integer) 3

3. hash

  1. 介绍 ：hash 类似于 JDK1.8 前的 HashMap，内部实现也差不多(数组 + 链表)。不过，Redis 的 hash 做了更多优化。另外，hash 是一个 string 类型的 field 和 value 的映射表，特别适合用于存储对象，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的值。 比如我们可以 hash 数据结构来存储用户信息，商品信息等等。
  2. 常用命令：hset, hmset, hexists, hget, hgetall, hkeys, hvals 等。
  3. 应用场景：系统中对象数据的存储（如登录之后使用redis存储分布式session中的用户信息）。

下面我们简单看看它的使用！

127.0.0.1:6379> hset userInfoKey name "guide" description "dev" age "24"
OK
127.0.0.1:6379> hexists userInfoKey name # 查看 key 对应的 value中指定的字段是否存在。
(integer) 1
127.0.0.1:6379> hget userInfoKey name # 获取存储在哈希表中指定字段的值。
"guide"
127.0.0.1:6379> hget userInfoKey age
"24"
127.0.0.1:6379> hgetall userInfoKey # 获取在哈希表中指定 key 的所有字段和值
1) "name"
2) "guide"
3) "description"
4) "dev"
5) "age"
6) "24"
127.0.0.1:6379> hkeys userInfoKey # 获取 key 列表
1) "name"
2) "description"
3) "age"
127.0.0.1:6379> hvals userInfoKey # 获取 value 列表
1) "guide"
2) "dev"
3) "24"
127.0.0.1:6379> hset userInfoKey name "GuideGeGe" # 修改某个字段对应的值
127.0.0.1:6379> hget userInfoKey name
"GuideGeGe"

4. set

  • 介绍 ： set 类似于 Java 中的 HashSet 。Redis 中的 set 类型是一种无序集合，集合中的元素没有先后顺序。当你需要存储一个列表数据，又不希望出现重复数据时，set 是一个很好的选择，并且 set 提供了判断某个成员是否在一个 set 集合内的重要接口，这个也是 list 所不能提供的。可以基于 set 轻易实现交集、并集、差集的操作。比如：你可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis 可以非常方便的实现如共同关注、共同粉丝、共同喜好等功能。这个过程也就是求交集的过程。
  • 常用命令：sadd, spop, smembers, sismember, scard, sinterstore, sunion 等。
  • 应用场景：需要存放的数据不能重复以及需要获取多个数据源交集和并集等场景

下面我们简单看看它的使用！

127.0.0.1:6379> sadd mySet value1 value2 # 添加元素进去
(integer) 2
127.0.0.1:6379> sadd mySet value1 # 不允许有重复元素
(integer) 0
127.0.0.1:6379> smembers mySet # 查看 set 中所有的元素
1) "value1"
2) "value2"
127.0.0.1:6379> scard mySet # 查看 set 的长度
(integer) 2
127.0.0.1:6379> sismember mySet value1 # 检查某个元素是否存在set 中，只能接收单个元素
(integer) 1
127.0.0.1:6379> sadd mySet2 value2 value3
(integer) 2
127.0.0.1:6379> sinterstore mySet3 mySet mySet2 # 获取 mySet 和 mySet2 的交集并存放在 mySet3 中
(integer) 1
127.0.0.1:6379> smembers mySet3
1) "value2"

5. sorted set

  • 介绍： 和 set 相比，sorted set 增加了一个权重参数 score，使得集合中的元素能够按 score 进行有序排列，还可以通过 score 的范围来获取元素的列表。有点像是 Java 中 HashMap 和 TreeSet 的结合体。
  • 常用命令：zadd, zcard, zscore, zrange, zrevrange, zrem 等。
  • 应用场景： 需要对数据根据某个权重进行排序的场景。比如在直播系统中，实时排行信息包含直播间在线用户列表，各种礼物排行榜，弹幕消息（可以理解为按消息维度的消息排行榜）等信息。
    127.0.0.1:6379> zadd myZset 3.0 value1 # 添加元素到 sorted set 中 3.0 为权重
(integer) 1
127.0.0.1:6379> zadd myZset 2.0 value2 1.0 value3 # 一次添加多个元素
(integer) 2
127.0.0.1:6379> zcard myZset # 查看 sorted set 中的元素数量
(integer) 3
127.0.0.1:6379> zscore myZset value1 # 查看某个 value 的权重
"3"
127.0.0.1:6379> zrange  myZset 0 -1 # 顺序输出某个范围区间的元素，0 -1 表示输出所有元素
1) "value3"
2) "value2"
3) "value1"
127.0.0.1:6379> zrange  myZset 0 1 # 顺序输出某个范围区间的元素，0 为 start  1 为 stop
1) "value3"
2) "value2"
127.0.0.1:6379> zrevrange  myZset 0 1 # 逆序输出某个范围区间的元素，0 为 start  1 为 stop
1) "value1"
2) "value2"

bitmap

  1. 介绍 ： bitmap 存储的是连续的二进制数字（0 和 1），通过 bitmap, 只需要一个 bit 位来表示某个元素对应的值或者状态，key 就是对应元素本身 。我们知道 8 个 bit 可以组成一个 byte，所以 bitmap 本身会极大的节省储存空间。
  2. 常用命令：setbit 、getbit 、bitcount、bitop
  3. 应用场景: 适合需要保存状态信息（比如是否签到、是否登录…）并需要进一步对这些信息进行分析的场景。比如用户签到情况、活跃用户情况、用户行为统计（比如是否点赞过某个视频）。
    # SETBIT 会返回之前位的值（默认是 0）这里会生成 7 个位
127.0.0.1:6379> setbit mykey 7 1
(integer) 0
127.0.0.1:6379> setbit mykey 7 0
(integer) 1
127.0.0.1:6379> getbit mykey 7
(integer) 0
127.0.0.1:6379> setbit mykey 6 1
(integer) 0
127.0.0.1:6379> setbit mykey 8 1
(integer) 0
# 通过 bitcount 统计被被设置为 1 的位的数量。
127.0.0.1:6379> bitcount mykey
(integer) 2

针对上面提到的一些场景，这里进行进一步说明。

使用场景一：用户行为分析
很多网站为了分析你的喜好，需要研究你点赞过的内容。

# 记录你喜欢过 001 号小姐姐
127.0.0.1:6379> setbit beauty_girl_001 uid 1

使用场景二：统计活跃用户
使用时间作为 key，然后用户 ID 为 offset，如果当日活跃过就设置为 1
那么我该如何计算某几天/月/年的活跃用户呢(暂且约定，统计时间内只要有一天在线就称为活跃)，有请下一个 redis 的命令

# 对一个或多个保存二进制位的字符串 key 进行位元操作，并将结果保存到 destkey 上。
# BITOP 命令支持 AND 、 OR 、 NOT 、 XOR 这四种操作中的任意一种参数
BITOP operation destkey key [key ...]

初始化数据：

127.0.0.1:6379> setbit 20210308 1 1
(integer) 0
127.0.0.1:6379> setbit 20210308 2 1
(integer) 0
127.0.0.1:6379> setbit 20210309 1 1
(integer) 0

统计 20210308~20210309 总活跃用户数: 1

127.0.0.1:6379> bitop and desk1 20210308 20210309
(integer) 1
127.0.0.1:6379> bitcount desk1
(integer) 1

统计 20210308~20210309 在线活跃用户数: 2

127.0.0.1:6379> bitop or desk2 20210308 20210309
(integer) 1
127.0.0.1:6379> bitcount desk2
(integer) 2

使用场景三：用户在线状态
对于获取或者统计用户在线状态，使用 bitmap 是一个节约空间效率又高的一种方法。
只需要一个 key，然后用户 ID 为 offset，如果在线就设置为 1，不在线就设置为 0。

Sorted Set底层数据结构

有序集合对象有2种编码方案，当同时满足以下条件时，集合对象采用ziplist编码，否则采用skiplist编码：

  • 有序集合保存的元素数量不超过128个；
  • 有序集合保存的所有元素的成员长度都小于64字节。

其中，ziplist编码的有序集合采用压缩列表作为底层实现，skiplist编码的有序集合采用zset结构作为底层实现。

其中，zset是一个复合结构，它的内部采用字典和跳跃表来实现，其源码如下。其中，dict保存了从元素到分值的映射关系，zsl则按分值由小到大保存了所有的集合元素。这样，当按照成员来访问有序集合时可以直接从dict中取值，当按照分值的范围访问有序集合时可以直接从zsl中取值，采用了空间换时间的策略以提高访问效率。

typedef struct zset {
    dict *dict;        // 字典，保存了从成员到分值的映射关系；
    zskiplist *zsl;    // 跳跃表，按分值由小到大保存所有集合元素；
} zset;

综上，sorted set对象的底层数据结构包括：压缩列表、字典、跳跃表。

1. ziplist编码：

使用压缩列表实现，当保存的元素长度都小于64字节，同时数量小于128时，使用该编码方式，否则会使用 skiplist。这两个参数可以通过 zset-max-ziplist-entries、zset-max-ziplist-value 来自定义修改。当ziplist作为存储结构时候，每个集合元素使用两个紧挨在一起的压缩列表结点来保存，第一个节点保存元素的成员，第二个元素保存元素的分值.
Redis面试问题 - 图7

2. skiplist编码：

采用zset结构作为底层实现，使用skiplist按序保存集合元素，使用dict来保存元素和分值的对应关系。

zset是一个复合结构，它的内部采用字典和跳跃表来实现，其源码如下。其中，dict保存了从元素到分值的映射关系，zsl则按分值由小到大保存了所有的集合元素。这样，当按照成员来访问有序集合时可以直接从dict中取值，当按照分值的范围访问有序集合时可以直接从zsl中取值，采用了空间换时间的策略以提高访问效率。

typedef struct zset {
    dict *dict;        // 字典，保存了从成员到分值的映射关系；
    zskiplist *zsl;    // 跳跃表，按分值由小到大保存所有集合元素；
} zset;

跳跃表：跳跃表
Redis面试问题 - 图8

Hash

0. 底层数据结构

哈希对象有两种编码方案，当同时满足以下条件时，哈希对象采用ziplist编码，否则采用hashtable编码：

  • 哈希对象保存的键值对数量小于512个；
  • 哈希对象保存的所有键值对中的键和值，其字符串长度都小于64字节。

压缩列表：

  • 压缩列表（ziplist），是Redis为了节约内存而设计的一种线性数据结构，它是由一系列具有特殊编码的连续内存块构成的。一个压缩列表可以包含任意多个节点，每个节点可以保存一个字节数组或一个整数值。
  • 每当有新的键值对要加入到哈希对象时，程序会先将保存了键的节点推入到压缩列表的表尾，然后再将保存了值的节点推入到压缩列表表尾。
    • 1）保存了同一键值对的两个节点总是紧挨在一起，保存键的节点在前，保存值的节点在后；
    • 2）先添加到哈希对象中的键值对会被放在压缩列表的表头方向，而后来添加的会被放在表尾方向。

Redis面试问题 - 图9
hashtable：
使用字典作为底层实现，哈希对象中的每个键值对都使用一个字典键值来保存，跟 java 中的 HashMap 类似。
Redis面试问题 - 图10

1. Hash对象的扩容流程

hash 对象在扩容时使用了一种叫“渐进式 rehash”的方式，将 rehash 分摊到每个操作上，步骤如下：

  1. 计算新表 size、掩码，为新表 ht[1] 分配空间，让字典同时持有 ht[0] 和 ht[1] 两个哈希表。
  2. 将 rehash 索引计数器变量 rehashidx 的值设置为0，表示 rehash 正式开始。
  3. 在 rehash 进行期间，每次对字典执行添加、删除、査找、更新操作时，程序除了执行指定的操作以外，还会触发额外的 rehash 操作，在源码中的 _dictRehashStep 方法。_dictRehashStep：从名字也可以看出来，大意是 rehash 一步，也就是 rehash 一个索引位置。该方法会从 ht[0] 表的 rehashidx 索引位置上开始向后查找，找到第一个不为空的索引位置，将该索引位置的所有节点 rehash 到 ht[1]，当本次 rehash 工作完成之后，将 ht[0] 的 rehashidx 位置清空，同时将 rehashidx 属性的值加一。
  4. 将 rehash 分摊到每个操作上确实是非常妙的方式，但是万一此时服务器比较空闲，一直没有什么操作，难道 redis 要一直持有两个哈希表吗？答案当然不是的。我们知道，redis 除了文件事件外，还有时间事件，redis 会定期触发时间事件，这些时间事件用于执行一些后台操作，其中就包含 rehash 操作：当 redis 发现有字典正在进行 rehash 操作时，会花费1毫秒的时间，一起帮忙进行 rehash。
  5. 随着操作的不断执行，最终在某个时间点上，ht[0] 的所有键值对都会被 rehash 至 ht[1]，此时 rehash 流程完成，会执行最后的清理工作：释放 ht[0] 的空间、将 ht[0] 指向 ht[1]、重置 ht[1]、重置 rehashidx 的值为 -1。

    2. 渐进式 rehash 的优点

  • 渐进式 rehash 的好处在于它采取分而治之的方式，将 rehash 键值对所需的计算工作均摊到对字典的每个添加、删除、查找和更新操作上，从而避免了集中式 rehash 而带来的庞大计算量。
  • 在进行渐进式 rehash 的过程中，字典会同时使用 ht[0] 和 ht[1] 两个哈希表， 所以在渐进式 rehash 进行期间，字典的删除、査找、更新等操作会在两个哈希表上进行。例如，要在字典里面査找一个键的话，程序会先在 ht[0] 里面进行査找，如果没找到的话，就会继续到 ht[1] 里面进行査找，诸如此类。

  • 另外，在渐进式 rehash 执行期间，新增的键值对会被直接保存到 ht[1], ht[0] 不再进行任何添加操作，这样就保证了 ht[0] 包含的键值对数量会只减不增，并随着 rehash 操作的执行而最终变成空表。

    3. rehash 流程在数据量大的时候会有什么问题吗

  • 扩容期开始时，会先给 ht[1] 申请空间，所以在整个扩容期间，会同时存在 ht[0] 和 ht[1]，会占用额外的空间。

  • 扩容期间同时存在 ht[0] 和 ht[1]，查找、删除、更新等操作有概率需要操作两张表，耗时会增加。
  • redis 在内存使用接近 maxmemory 并且有设置驱逐策略的情况下，出现 rehash 会使得内存占用超过 maxmemory，触发驱逐淘汰操作，导致 master/slave 均有有大量的 key 被驱逐淘汰，从而出现 master/slave 主从不一致。

    Redis单线程模型

    1. Redis 是单线程还是多线程

    Redis面试问题 - 图11
    redis 在4.0 之前是完全单线程的。
    Redis面试问题 - 图12
    redis 4.0 时，redis 引入了多线程，但是额外的线程只是用于后台处理，例如：删除对象，核心流程还是完全单线程的。这也是为什么有些人说 4.0 是单线程的，因为他们指的是核心流程是单线程的。这边的核心流程指的是 redis 正常处理客户端请求的流程，通常包括：接收命令、解析命令、执行命令、返回结果等。

而在最近，redis 6.0 版本又一次引入了多线程概念，与 4.0 不同的是，这次的多线程会涉及到上述的核心流程。redis 6.0 中，多线程主要用于网络 I/O 阶段，也就是接收命令和写回结果阶段，而在执行命令阶段，还是由单线程串行执行。由于执行时还是串行，因此无需考虑并发安全问题。
值得注意的时，redis 中的多线程组不会同时存在“读”和“写”，这个多线程组只会同时“读”或者同时“写”。
Redis面试问题 - 图13
具体来说，redis 6.0 加入多线程 I/O 之后，处理命令的核心流程如下:

  1. 当有读事件到来时，主线程将该客户端连接放到全局等待读队列
  2. 读取数据：
    1. 主线程将等待读队列的客户端连接通过轮询调度算法分配给 I/O 线程处理；
    2. 同时主线程也会自己负责处理一个客户端连接的读事件；
    3. 当主线程处理完该连接的读事件后，会自旋等待所有 I/O 线程处理完毕
  3. 命令执行：主线程按照事件被加入全局等待读队列的顺序（这里保证了执行顺序是正确的），串行执行客户端命令，然后将客户端连接放到全局等待写队列
  4. 写回结果：跟等待读队列处理类似，主线程将等待写队列的客户端连接使用轮询调度算法分配给 I/O 线程处理，同时自己也会处理一个，当主线程处理完毕后，会自旋等待所有 I/O 线程处理完毕，最后清空队列。

大致流程图如下：
Redis面试问题 - 图14

2. Redis 为什么不使用多线程？

虽然说 Redis 是单线程模型，但是， 实际上，Redis 在 4.0 之后的版本中就已经加入了对多线程的支持。
不过，Redis 4.0 增加的多线程主要是针对一些大键值对的删除操作的命令，使用这些命令就会使用主线程处理之外的其他线程来“异步处理”。
大体上来说，Redis 6.0 之前主要还是单线程处理。
那，Redis6.0 之前 为什么不使用多线程？
我觉得主要原因有下面 3 个：

  1. 单线程编程容易并且更容易维护；
  2. 因为 redis 是完全基于内存操作的，通常情况下CPU不会是redis的瓶颈，redis 的瓶颈最有可能是机器内存的大小或者网络带宽。；
  3. 多线程就会存在死锁、线程上下文切换等问题，甚至会影响性能。

    官方曾做过类似问题的回复：使用Redis时，几乎不存在CPU成为瓶颈的情况， Redis主要受限于内存和网络。例如在一个普通的Linux系统上，Redis通过使用pipelining每秒可以处理100万个请求，所以如果应用程序主要使用O(N)或O(log(N))的命令，它几乎不会占用太多CPU。 使用了单线程后，可维护性高。多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。Redis通过AE事件模型以及IO多路复用等技术，处理性能非常高，因此没有必要使用多线程。单线程机制使得 Redis 内部实现的复杂度大大降低，Hash 的惰性 Rehash、Lpush 等等 “线程不安全” 的命令都可以无锁进行。

3. Redis是单线程的，为什么还能这么快？

  1. 对服务端程序来说，线程切换和锁通常是性能杀手，而单线程避免了线程切换和竞争所产生的消耗；
  2. Redis的大部分操作是在内存上完成的，这是它实现高性能的一个重要原因；
  3. Redis采用了IO多路复用机制，使其在网络IO操作中能并发处理大量的客户端请求，实现高吞吐率。

    4. Redis6.0 之后为何引入了多线程？

    Redis6.0 引入多线程主要是为了提高网络 IO 读写性能，因为这个算是 Redis 中的一个性能瓶颈（Redis 的瓶颈主要受限于内存和网络）。
    虽然，Redis6.0 引入了多线程，但是 Redis 的多线程只是在网络数据的读写这类耗时操作上使用了， 执行命令仍然是单线程顺序执行。因此，你也不需要担心线程安全问题。

Redis6.0 的多线程默认是禁用的，只使用主线程。如需开启需要修改 redis 配置文件 redis.conf ：

io-threads-do-reads yes

开启多线程后，还需要设置线程数，否则是不生效的。同样需要修改 redis 配置文件 redis.conf :

io-threads 4 #官网建议4核的机器建议设置为2或3个线程，8核的建议设置为6个线程

推荐阅读：

  1. Redis 6.0 新特性-多线程连环 13 问！
  2. 为什么 Redis 选择单线程模型

    5. Redis的事件处理器

    redis 基于 reactor 模式开发了自己的网络事件处理器，由4个部分组成：套接字、I/O 多路复用程序、文件事件分派器（dispatcher）、以及事件处理器。
    Redis面试问题 - 图15
  • 套接字：socket 连接，也就是客户端连接。当一个套接字准备好执行连接、写入、读取、关闭等操作时， 就会产生一个相应的文件事件。因为一个服务器通常会连接多个套接字， 所以多个文件事件有可能会并发地出现。
  • I/O 多路复用程序：提供 select、epoll、evport、kqueue 的实现，会根据当前系统自动选择最佳的方式。负责监听多个套接字，当套接字产生事件时，会向文件事件分派器传送那些产生了事件的套接字。
  • 当多个文件事件并发出现时， I/O 多路复用程序会将所有产生事件的套接字都放到一个队列里面，然后通过这个队列，以有序、同步、每次一个套接字的方式向文件事件分派器传送套接字：当上一个套接字产生的事件被处理完毕之后，才会继续传送下一个套接字。
  • 文件事件分派器：接收 I/O 多路复用程序传来的套接字， 并根据套接字产生的事件的类型， 调用相应的事件处理器。
  • 事件处理器：事件处理器就是一个个函数， 定义了某个事件发生时， 服务器应该执行的动作。例如：建立连接、命令查询、命令写入、连接关闭等等。

    6. Redis在持久化时fork出一个子进程，这时已经有两个进程了，怎么能说是单线程呢？

    Redis是单线程的，主要是指Redis的网络IO和键值对读写是由一个线程来完成的。而Redis的其他功能，如持久化、异步删除、集群数据同步等，则是依赖其他线程来执行的。所以，说Redis是单线程的只是一种习惯的说法，事实上它的底层不是单线程的。

    Redis 过期时间

    1. 给缓存数据设置过期时间有啥用？

    一般情况下，我们设置保存的缓存数据的时候都会设置一个过期时间。为什么呢？
    因为内存是有限的，如果缓存中的所有数据都是一直保存的话，分分钟直接 Out of memory。
    Redis 自带了给缓存数据设置过期时间的功能，比如：
    127.0.0.1:6379> expire key  60 # 数据在 60s 后过期
(integer) 1
127.0.0.1:6379> setex key 60 value # 数据在 60s 后过期 (setex:[set] + [ex]pire)
OK
127.0.0.1:6379> ttl key # 查看数据还有多久过期
(integer) 56

注意：Redis 中除了字符串类型有自己独有设置过期时间的命令 **setex** 外，其他方法都需要依靠 **expire** 命令来设置过期时间 。另外， **persist** 命令可以移除一个键的过期时间：

过期时间除了有助于缓解内存的消耗，还有什么其他用么？
很多时候，我们的业务场景就是需要某个数据只在某一时间段内存在，比如我们的短信验证码可能只在 1 分钟内有效，用户登录的 token 可能只在 1 天内有效。
如果使用传统的数据库来处理的话，一般都是自己判断过期，这样更麻烦并且性能要差很多。

2. Redis 是如何判断数据是否过期的呢？

Redis 通过一个叫做过期字典（可以看作是 hash 表）来保存数据过期的时间。过期字典的键指向 Redis 数据库中的某个 key(键)，过期字典的值是一个 long long 类型的整数，这个整数保存了 key 所指向的数据库键的过期时间（毫秒精度的 UNIX 时间戳）。
过期字典是存储在 redisDb 这个结构里的：

typedef struct redisDb {
    ...

    dict *dict;     // 数据库键空间,保存着数据库中所有键值对
    dict *expires   // 过期字典,保存着键的过期时间
    ...
} redisDb;

3. 如何设计Redis的过期时间

  1. 热点数据不设置过期时间，使其达到“物理”上的永不过期，可以避免缓存击穿问题；

  2. 在设置过期时间时，可以附加一个随机数，避免大量的key同时过期，导致缓存雪崩。

    过期的数据的删除策略了解么？

    如果假设你设置了一批 key 只能存活 1 分钟，那么 1 分钟后，Redis 是怎么对这批 key 进行删除的呢？
    常用的过期数据的删除策略就两个（重要！自己造缓存轮子的时候需要格外考虑的东西）：

  3. 惰性删除 ：放任键过期不管，但是每次获取键时，都检査键是否过期，如果过期的话，就删除该键；如果没有过期，就返回该键。这样对 CPU 最友好，但是可能会造成太多过期 key 没有被删除。

  4. 定期删除 ： 每隔一段时间抽取一批 key 执行删除过期 key 操作。并且，Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。

定期删除对内存更加友好，惰性删除对 CPU 更加友好。两者各有千秋，所以 Redis 采用的是 定期删除+惰性删除。
但是，仅仅通过给 key 设置过期时间还是有问题的。因为还是可能存在定期删除和惰性删除漏掉了很多过期 key 的情况。这样就导致大量过期 key 堆积在内存里，然后就 Out of memory 了。
怎么解决这个问题呢？答案就是： Redis 内存淘汰机制。

Redis 内存淘汰机制了解么？

相关问题：MySQL 里有 2000w 数据，Redis 中只存 20w 的数据，如何保证 Redis 中的数据都是热点数据?

Redis 提供 6 种数据淘汰策略：

  1. volatile-lru（least recently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰。（仅对设置了过期时间的键采取LRU淘汰）
  2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
  3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
  4. allkeys-lru（least recently used）：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）（对所有的键都采取LRU淘汰）
  5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
  6. no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！

4.0 版本后增加以下两种：

  1. volatile-lfu（least frequently used）：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰
  2. allkeys-lfu（least frequently used）：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的 key

    lru：会根据使用情况调整位置，因为是最近使用 lfu：单纯根据使用次数排名即可

Redis 持久化机制(怎么保证 Redis 挂掉之后再重启数据可以进行恢复)

Redis支持RDB持久化、AOF持久化、RDB-AOF混合持久化这三种持久化方式。

1. RDB：

1.1 简介：

  • 在指定的时间间隔内生成内存中整个数据集的持久化快照。快照文件默认被存储在当前文件夹中，名称为dump.rdb，可以通过 dir 和 dbfilename 参数来修改默认值。
  • Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
  • 整个过程中，主进程是不进行任何的IO操作的，这就确保了极高的性能。
  • 是Redis默认采用的持久化方式

    fork的作用相当于复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

1.2 应用场景：

  • 数据备份
  • 可容忍部分数据丢失
  • 跨数据中心的容灾备份

1.3 如何触发RDB快照备份：

  1. 自动触发：通过配置选项，让服务器在满足指定条件时自动执行BGSAVE命令。

    save 900 1
save 300 10
save 60 10000

  2. 手动触发：通过SAVE或BGSAVE命令触发RDB持久化操作，创建“.rdb”文件

    • save：save时只管保存，其他不管，全部阻塞
    • bgsave：redis会在后台异步地进行快照操作，同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间

      其中，SAVE命令执行期间，Redis服务器将阻塞，直到“.rdb”文件创建完毕为止。而BGSAVE命令是异步版本的SAVE命令，它会使用Redis服务器进程的子进程，创建“.rdb”文件。BGSAVE命令在创建子进程时会存在短暂的阻塞，之后服务器便可以继续处理其他客户端的请求。总之，BGSAVE命令是针对SAVE阻塞问题做的优化，Redis内部所有涉及RDB的操作都采用BGSAVE的方式，而SAVE命令已经废弃！ BGSAVE命令的执行流程，如下图： Redis面试问题 - 图16 BGSAVE命令的原理，如下图： Redis面试问题 - 图17 Redis在BGSAVE时，用户与redis的交互能否保存在本次持久化的rdb中？ 不能 BGSAVE不是开启线程，而是Fork一个子进程。 Fork之后，子进程会把原来父进程的内存快照一份（先不考虑写时复制）。 然后子进程用自己的快照来遍历写入RDB。 至于你的新写入，操作的还是父进程的内存空间，与子进程无关。 因此RDB中没有新的写入。

  3. 通过flushall命令，也会产生dump.rdb文件，但是里面是空的，无意义。

  4. 通过shutdown命令，安全退出，也会生成快照文件（和异常退出形成对比，比如：kill杀死进程的方式）

1.4 如何恢复：

  1. 将备份文件（dump.rdb）移动到redis安装目录并启动服务即可
  2. 或者可以修改配置文件，指定备份文件的目录
    appendonly no
dbfilename dump.rdb
dir /var/lib/redis  #可以自行指定

设置 appendonly no，redis 启动时会把 /var/lib/redis 目录下的 dump.rdb 中的数据恢复。dir 和dbfilename 都可以设置。
1.5 优势：

  • 恢复数据的速度很快，适合大规模的数据恢复，而又对部分数据不敏感的情况
  • 对数据完整性和一致性要求不高
  • dump.db文件是一个压缩的二进制文件，文件占用空间小

1.6 劣势：

  • 在一定时间间隔做一次备份，当出现异常退出时，会丢失最后一次快照后的数据

  • 当fork的时候，内存的中的数据会被克隆一份，大致两倍的膨胀需要考虑。而且，当数据过大时，fork操作占用过多的系统资源，造成主服务器进程假死。

    2. AOF：

    2.1 简介：

  • 以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据（即根据日志文件的内容将写指令从前到后执行一次已完成数据的恢复工作）。RDB基于快照，AOF基于命令

  • AOF保存的是appendonly.aof文件
  • aof机制默认关闭，可以通过appendonly = yes参数开启aof机制，通过appendfilename = myaoffile.aof指定aof文件名称。
  • AOF（Append Only File），解决了数据持久化的实时性，是目前Redis持久化的主流方式。AOF以独立日志的方式，记录了每次写入命令，重启时再重新执行AOF文件中的命令来恢复数据。AOF的工作流程包括：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load），如下图：

Redis面试问题 - 图18
AOF默认不开启，需要修改配置项来启用它：

# aof持久化策略的配置（将命令从AOF缓冲写到AOF文件的频率）
appendfsync everysec

Redis面试问题 - 图19
2.2 重写策略

AOF采用文件追加的方式，文件会越来越大。为避免出现此情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

2.2.1 重写原理：

  • AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件再rename），遍历新进程的内存中的数据，每条记录有一条set语句。
  • 重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库命令用命令的方式重写了一个新的aof文件，这点和快照类似。

2.2.2 触发机制：

  • redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64mb时触发

2.2.3 相关配置：

  • 对于触发aof重写机制也可以通过配置文件来进行设置 ```yaml

    aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，

    即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。

    当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。

    auto-aof-rewrite-percentage 100

设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写

auto-aof-rewrite-min-size 64mb


- aof重写时会引发重写和持久化追加同时发生的问题，可以通过`no-appendfsync-on-rewrite no`进行配置
```yaml
no-appendfsync-on-rewrite no

在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间。

  • no-appendfsync-on-rewrite字段默认设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。
  • 如果对延迟要求很高的应用，这个字段可以设置为yes，设置为yes表示rewrite期间对新写操作不fsync，暂时存在内存中，不会造成阻塞的问题（因为没有磁盘竞争），等rewrite完成后再写入，这个时候redis可能会丢失数据。Linux的默认fsync策略是30秒。可能丢失30秒数据。
  • 因此，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no。

2.3 如何恢复：
正常恢复

  • 将文件放到dir指定的文件夹下，当redis启动的时候会自动加载数据，注意：aof文件的优先级比dump大。

异常恢复

  • 有些操作可以直接到 appendonly.aof 文件里去修改。
    eg：使用了flushall这个命令，此刻持久化文件中就会有这么一条命令记录，把它删掉就可以了
  • 写坏的文件可以通过 redis-check-aof --fix进行修复

2.4 优势：

  1. 与RDB持久化可能丢失大量的数据相比，AOF持久化的安全性要高很多。通过使用everysec选项，用户可以将数据丢失的时间窗口限制在1秒之内。
  2. 当文件太大时，会触发重写机制，确保文件不会太大。
  3. 文件可以简单的读懂

2.5 劣势：

  1. 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
  2. aof运行效率要慢于rdb，每秒同步策略较好，不同步效率和rdb相同

    3. RDB-AOF混合持久化：

    Redis数据持久化之RDB-AOF混合方式
    Redis从4.0开始引入RDB-AOF混合持久化模式，这种模式是基于AOF持久化构建而来的。用户可以通过配置文件中的“aof-use-rdb-preamble yes”配置项开启AOF混合持久化。Redis服务器在执行AOF重写操作时，会按照如下原则处理数据：
  • 像执行BGSAVE命令一样，根据数据库当前的状态生成相应的RDB数据，并将其写入AOF文件中；
  • 对于重写之后执行的Redis命令，则以协议文本的方式追加到AOF文件的末尾，即RDB数据之后。

通过使用RDB-AOF混合持久化，用户可以同时获得RDB持久化和AOF持久化的优点，服务器既可以通过AOF文件包含的RDB数据来实现快速的数据恢复操作，又可以通过AOF文件包含的AOF数据来将丢失数据的时间窗口限制在1s之内。

简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据 image.png 优点： 混合持久化结合了RDB持久化 和 AOF 持久化的优点, 由于绝大部分都是RDB格式，加载速度快，同时结合AOF，增量的数据以AOF方式保存了，数据更少的丢失。 缺点： 兼容性差，一旦开启了混合持久化，在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差

Redis 事务

1. Redis事务的概念

Redis的事务并不是我们传统意义上理解的事务，我们都知道 单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。

事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

总结：

  • Redis事务中如果有某一条命令执行失败，之前的命令不会回滚，其后的命令仍然会被继续执行。鉴于这个原因，所以说Redis的事务严格意义上来说是不具备原子性的。
  • Redis事务中所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
  • 在事务开启之前，如果客户端与服务器之间出现通讯故障并导致网络断开，其后所有待执行的语句都将不会被服务器执行。然而如果网络中断事件是发生在客户端执行EXEC命令之后，那么该事务中的所有命令都会被服务器执行。

当使用Append-Only模式时，Redis会通过调用系统函数write将该事务内的所有写操作在本次调用中全部写入磁盘。然而如果在写入的过程中出现系统崩溃，如电源故障导致的宕机，那么此时也许只有部分数据被写入到磁盘，而另外一部分数据却已经丢失。Redis服务器会在重新启动时执行一系列必要的一致性检测，一旦发现类似问题，就会立即退出并给出相应的错误提示。此时，我们就要充分利用Redis工具包中提供的Redis-check-aof工具，该工具可以帮助我们定位到数据不一致的错误，并将已经写入的部分数据进行回滚。修复之后我们就可以再次重新启动Redis服务器了。

全体连坐：

  • 输入命令过程中报错，整个事务无法执行。

Redis面试问题 - 图21

冤头债主：

  • 执行时某条命令报错不影响其他正常执行的命令。这里可以看出redis对事务的支持是部分支持，没有强一致性。

Redis面试问题 - 图22

2. Redis事务的三个阶段

  1. 开启：以multi开始一个事务
  2. 入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列中
  3. 执行：由exec命令触发事务

3. Redis事务相关命令

Redis事务功能是通过MULTI、EXEC、DISCARD和WATCH 四个原语实现的

  • MULTI命令用于开启一个事务，它总是返回OK。 MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。
  • EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。 当操作被打断时，返回空值 nil 。 通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务， 并且客户端会从事务状态中退出。
  • WATCH命令是一个乐观锁，可以为 Redis 事务提供 check-and-set （CAS）行为。 可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令。
  • UNWATCH命令可以取消watch对所有key的监控。

4. Redis事务支持隔离性吗?

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

5. Redis为什么不支持事务回滚？

  • Redis 命令只会因为错误的语法而失败，或是命令用在了错误类型的键上面，这些问题可以在入队时发现，这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中.
  • 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

6. Redis事务其他实现

  • 基于Lua脚本，Redis可以保证脚本内的命令一次性、按顺序地执行， 其同时也不提供事务运行错误的回滚，执行过程中如果部分命令运行错误，剩下的命令还是会继续运行完。
  • 基于中间标记变量，通过另外的标记变量来标识事务是否执行完成，读取数据时先读取该标记变量判断是否事务执行完成。但这样会需要额外写代码实现，比较繁琐。

缓存异常

1. 缓存穿透

1.什么是缓存穿透？
访问一个缓存和数据库都不存在的 key，此时会直接打到数据库上，并且查不到数据，没法写缓存，所以下一次同样会打到数据库上。此时，缓存起不到作用，请求每次都会走到数据库，流量大时数据库可能会被打挂。此时缓存就好像被“穿透”了一样，起不到任何作用。

2.缓存穿透情况的处理流程是怎样的？
用户的请求最终都要跑到数据库中查询一遍。
用户请求 -> 缓存中是否存在对应数据 -> 数据库中是否存在对应数据

3.有哪些解决办法？
1）参数校验
最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。

2）缓存无效 key
如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并设置过期时间（比如写空值），具体命令如下： SET key value EX 10086 。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求 key，会导致 Redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点比如 1 分钟。
另外，这里多说一嘴，一般情况下我们是这样设计 key 的： 表名:列名:主键名:主键值 。
如果用 Java 代码展示的话，差不多是下面这样的：

public Object getObjectInclNullById(Integer id) {
    // 从缓存中获取数据
    Object cacheValue = cache.get(id);
    // 缓存为空
    if (cacheValue == null) {
        // 从数据库中获取
        Object storageValue = storage.get(key);
        // 缓存空对象
        cache.set(key, storageValue);
        // 如果存储数据为空，需要设置一个过期时间(300秒)
        if (storageValue == null) {
            // 必须设置过期时间，否则有被攻击的风险
            cache.expire(key, 60 * 5);
        }
        return storageValue;
    }
    return cacheValue;
}

3）布隆过滤器
布隆过滤器是一个非常神奇的数据结构，通过它我们可以非常方便地判断一个给定数据是否存在于海量数据中。
具体是这样做的：把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。
加入布隆过滤器之后的缓存处理流程图如下。
Redis面试问题 - 图23

但是，需要注意的是布隆过滤器可能会存在误判的情况。总结来说就是： 布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。

为什么会出现误判的情况呢? 我们还要从布隆过滤器的原理来说！

我们先来看一下，当一个元素加入布隆过滤器中的时候，会进行哪些操作：

  1. 使用布隆过滤器中的（多个）哈希函数对元素值进行计算，得到哈希值（有几个哈希函数得到几个哈希值）。
  2. 根据得到的哈希值，在位数组中把对应下标的值置为 1。

我们再来看一下，当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行哪些操作：

  1. 对给定元素再次进行相同的哈希计算；
  2. 得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。

然后，一定会出现这样一种情况：不同的字符串可能哈希出来的位置相同。 （可以适当增加位数组大小或者调整我们的哈希函数来降低概率） 都为1 -> 判定存在 -> 可能不存在（位数组中为1可能是因为别的key某个hash出来的位置和这个key相同） 不都为1 -> 判定不存在 -> 一定不存在

更多关于布隆过滤器的内容可以看我的这篇原创：《不了解布隆过滤器？一文给你整的明明白白！》 ，强烈推荐，个人感觉网上应该找不到总结的这么明明白白的文章了。

2. 缓存击穿

1.什么是缓存击穿？
某一个热点 key，在缓存过期的一瞬间，同时有大量的请求打进来，由于此时缓存过期了，所以请求最终都会走到数据库，造成瞬时数据库请求量大、压力骤增，甚至可能打垮数据库。

2.有哪些解决办法？
1）加互斥锁
在并发的多个请求中，只有第一个请求线程能拿到锁并执行数据库查询操作，其他的线程拿不到锁就阻塞等着，等到第一个线程将数据写入缓存后，直接走缓存。
关于互斥锁的选择，网上看到的大部分文章都是选择 Redis 分布式锁（可以参考我之前的文章：面试必问的分布式锁，你懂了吗？），因为这个可以保证只有一个请求会走到数据库，这是一种思路。
但是其实仔细想想的话，这边其实没有必要保证只有一个请求走到数据库，只要保证走到数据库的请求能大大降低即可，所以还有另一个思路是 JVM 锁。

JVM 锁保证了在单台服务器上只有一个请求走到数据库，通常来说已经足够保证数据库的压力大大降低，同时在性能上比分布式锁更好。
需要注意的是，无论是使用“分布式锁”，还是“JVM 锁”，加锁时要按 key 维度去加锁。
我看网上很多文章都是使用一个“固定的 key”加锁，这样会导致不同的 key 之间也会互相阻塞，造成性能严重损耗。

使用 redis 分布式锁的伪代码，仅供参考：

public Object getData(String key) throws InterruptedException {
    Object value = redis.get(key);
    // 缓存值过期
    if (value == null) {
        // lockRedis：专门用于加锁的redis；
        // "empty"：加锁的值随便设置都可以
        if (lockRedis.set(key, "empty", "PX", lockExpire, "NX")) {
            try {
                // 查询数据库，并写到缓存，让其他线程可以直接走缓存
                value = getDataFromDb(key);
                redis.set(key, value, "PX", expire);
            } catch (Exception e) {
                // 异常处理
            } finally {
                // 释放锁
                lockRedis.delete(key);
            }
        } else {
            // sleep50ms后，进行重试
            Thread.sleep(50);
            return getData(key);
        }
    }
    return value;
}

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

3. 缓存雪崩

1.什么是缓存雪崩？
在某一时刻，缓存层无法继续提供服务，导致所有的请求直达存储层，造成数据库宕机。可能是缓存中有大量数据同时过期，也可能是Redis节点发生故障，导致大量请求无法得到处理。

举个例子 ：秒杀开始 12 个小时之前，我们统一存放了一批商品到 Redis 中，设置的缓存过期时间也是 12 个小时，那么秒杀开始的时候，这些秒杀的商品的访问直接就失效了。导致的情况就是，相应的请求直接就落到了数据库上，就像雪崩一样可怕。

2.有哪些解决办法？
1）针对 Redis 服务不可用的情况：

  • 采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用。
  • 限流，避免同时处理大量的请求。

2）针对热点缓存失效的情况：

  • 设置不同的失效时间比如随机设置缓存的失效时间。
  • 热点数据缓存永不失效。
  • 加互斥锁。该方式和缓存击穿一样，按 key 维度加锁，对于同一个 key，只允许一个线程去计算，其他线程原地阻塞等待第一个线程的计算结果，然后直接走缓存即可。

  • 启用降级和熔断措施：在发生雪崩时，若应用访问的不是核心数据，则直接返回预定义信息/空值/错误信息。或者在发生雪崩时，对于访问缓存接口的请求，客户端并不会把请求发给Redis，而是直接返回。。

    Redis为什么那么快

  • 内存存储：Redis是使用内存(in-memeroy)存储，没有磁盘IO上的开销。数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是O(1)。

  • 单线程实现：Redis使用单个线程处理请求，避免了多个线程之间线程切换和锁资源争用的开销。注意：单线程是指的是在核心网络模型中，网络请求模块使用一个线程来处理，即一个线程处理所有网络请求。
  • 非阻塞IO：Redis使用多路IO复用技术，将epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间。
  • 优化的数据结构：Redis有诸多可以直接应用的优化数据结构的实现，应用层可以直接使用原生的数据结构提升性能。
  • 使用底层模型不同：Redis直接自己构建了 VM (虚拟内存)机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

    Redis的VM(虚拟内存)机制就是暂时把不经常访问的数据(冷数据)从内存交换到磁盘中，从而腾出宝贵的内存空间用于其它需要访问的数据(热数据)。通过VM功能可以实现冷热数据分离，使热数据仍在内存中、冷数据保存到磁盘。这样就可以避免因为内存不足而造成访问速度下降的问题。Redis提高数据库容量的办法有两种：一种是可以将数据分割到多个RedisServer上；另一种是使用虚拟内存把那些不经常访问的数据交换到磁盘上。需要特别注意的是Redis并没有使用OS提供的Swap，而是自己实现。

Redis变慢的原因

快手面试官：Redis变慢了，如何快速排查？

  1. 使用复杂度高的命令，且执行这些命令时操作的数据量比较大

如sort、sunion、zunionstore（复杂度为o(n)），可以通过分析慢日志，查到是哪些命令引起的

  1. 存储大Key

Redis在写入数据时，需要为新的数据分配内存，当从Redis中删除数据时，它会释放对应的内存空间。如果一个key写入的数据非常大，Redis在分配内存时也会比较耗时。同样的，当删除这个key的数据时，释放内存也会耗时比较久。

  1. 集中过期（某个时间点突然出现延时）

如果有大量的key在某个固定时间点集中过期，在这个时间点访问Redis时，就有可能导致延迟增加。Redis的主动过期的定时任务，也是在Redis主线程中执行的，也就是说如果在执行主动过期的过程中，出现了需要大量删除过期key的情况，那么在业务访问时，必须等这个过期任务执行结束，才可以处理业务请求。此时就会出现，业务访问延时增大的问题。解决方案是，在集中过期时增加一个随机时间，把这些需要过期的key的时间打散即可。这样Redis在处理过期时，不会因为集中删除key导致压力过大，阻塞主线程。

  1. 实例内存达到上限

当Redis内存达到maxmemory后，每次写入新的数据之前，必须先踢出一部分数据，让内存维持在maxmemory之下。可以考虑拆分实例的方法来缓解，拆分实例可以把一个实例淘汰key的压力分摊到多个实例上，可以在一定程度降低延迟。

  1. fork耗时严重

如果你的Redis开启了自动生成RDB和AOF重写功能，那么有可能在后台生成RDB和AOF重写时导致Redis的访问延迟增大，而等这些任务执行完毕后，延迟情况消失。

  1. 使用Swap

我们知道，操作系统提供了Swap机制，目的是为了当内存不足时，可以把一部分内存中的数据换到磁盘上，以达到对内存使用的缓冲。但当内存中的数据被换到磁盘上后，访问这些数据就需要从磁盘中读取，这个速度要比内存慢太多！尤其是针对Redis这种高性能的内存数据库来说，如果Redis中的内存被换到磁盘上，对于Redis这种性能极其敏感的数据库，这个操作时间是无法接受

  1. 网卡负载过高

如果从某个时间点之后就开始变慢，并且一直持续。这时你需要检查一下机器的网卡流量，是否存在网卡流量被跑满的情况。网卡负载过高，在网络层和TCP层就会出现数据发送延迟、数据丢包等情况。Redis的高性能除了内存之外，就在于网络IO，请求量突增会导致网卡负载变高。

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

四种同步策略：

想要保证缓存与数据库的双写一致，一共有4种方式，即4种同步策略：

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

从这4种同步策略中，我们需要作出比较的是：

  1. 更新缓存与删除缓存哪种方式更合适？
  2. 应该先操作数据库还是先操作缓存？

    更新缓存还是删除缓存：

    下面，我们来分析一下，应该采用更新缓存还是删除缓存的方式。
  • 更新缓存

优点：每次数据变化都及时更新缓存，所以查询时不容易出现未命中的情况。
缺点：更新缓存的消耗比较大。如果数据需要经过复杂的计算再写入缓存，那么频繁的更新缓存，就会影响服务器的性能。如果是写入数据频繁的业务场景，那么可能频繁的更新缓存时，却没有业务读取该数据。

  • 删除缓存

优点：操作简单，无论更新操作是否复杂，都是将缓存中的数据直接删除。
缺点：删除缓存后，下一次查询缓存会出现未命中，这时需要重新读取一次数据库。
从上面的比较来看，一般情况下，删除缓存是更优的方案。

先操作数据库还是缓存：

下面，我们再来分析一下，应该先操作数据库还是先操作缓存。
首先，我们将先删除缓存与先更新数据库，在出现失败时进行一个对比：

1. 先删除缓存再更新数据库（异常情况）

Redis面试问题 - 图24
如上图，在出现失败时可能出现的问题：

  1. 进程A删除缓存成功；
  2. 进程A更新数据库失败；
  3. 进程B从缓存中读取数据；
  4. 由于缓存被删，进程B无法从缓存中得到数据，进而从数据库读取数据；
  5. 进程B从数据库成功获取数据，然后将数据更新到了缓存。

最终，缓存和数据库的数据是一致的，但仍然是旧的数据。而我们的期望是二者数据一致，并且是新的数据。

2. 先更新数据库再删除缓存（异常情况）

Redis面试问题 - 图25
如上图，在出现失败时可能出现的问题：

  1. 进程A更新数据库成功；
  2. 进程A删除缓存失败；
  3. 进程B读取缓存成功，由于缓存删除失败，所以进程B读取到的是旧的数据。

最终，缓存和数据库的数据是不一致的。
经过上面的比较，我们发现在出现失败的时候，是无法明确分辨出先删缓存和先更新数据库哪个方式更好，因为它们都存在问题。后面我们会进一步对这两种方式进行比较，但是在这里我们先探讨一下，上述场景出现的问题，应该如何解决呢？

重试机制

实际上，无论上面我们采用哪种方式去同步缓存与数据库，在第二步出现失败的时候，都建议采用重试机制解决，因为最终我们是要解决掉这个错误的。而为了避免重试机制影响主要业务的执行，一般建议重试机制采用异步的方式执行，如下图：
Redis面试问题 - 图26
这里我们按照先更新数据库，再删除缓存的方式，来说明重试机制的主要步骤：

  1. 更新数据库成功；
  2. 删除缓存失败；
  3. 将此数据加入消息队列；
  4. 业务代码消费这条消息；
  5. 业务代码根据这条消息的内容，发起重试机制，即从缓存中删除这条记录。

好了，下面我们再将先删缓存与先更新数据库，在没有出现失败时进行对比：

3. 先删除缓存再更新数据库（正常情况）

Redis面试问题 - 图27
如上图，在没有出现失败时可能出现的问题：

  1. 进程A删除缓存成功；
  2. 进程B读取缓存失败；
  3. 进程B读取数据库成功，得到旧的数据；
  4. 进程B将旧的数据成功地更新到了缓存；
  5. 进程A将新的数据成功地更新到数据库。

可见，进程A的两步操作均成功，但由于存在并发，在这两步之间，进程B访问了缓存。最终结果是，缓存中存储了旧的数据，而数据库中存储了新的数据，二者数据不一致。

延时双删：

上面我们提到，如果是先删缓存、再更新数据库，在没有出现失败时可能会导致数据的不一致。如果在实际的应用中，出于某些考虑我们需要选择这种方式，那有办法解决这个问题吗？答案是有的，那就是采用延时双删的策略，延时双删的基本思路如下：

  1. 删除缓存；
  2. 更新数据库；
  3. sleep N毫秒；
  4. 再次删除缓存。

阻塞一段时间之后，再次删除缓存，就可以把这个过程中缓存中不一致的数据删除掉。而具体的时间，要评估你这项业务的大致时间，按照这个时间来设定即可。

4. 先更新数据库再删除缓存（正常情况）

Redis面试问题 - 图28
如上图，在没有出现失败时可能出现的问题：

  1. 进程A更新数据库成功；
  2. 进程B读取缓存成功；
  3. 进程A删除缓存成功。

可见，最终缓存与数据库的数据是一致的，并且都是最新的数据。但进程B在这个过程里读到了旧的数据，可能还有其他进程也像进程B一样，在这两步之间读到了缓存中旧的数据，但因为这两步的执行速度会比较快，所以影响不大。对于这两步之后，其他进程再读取缓存数据的时候，就不会出现类似于进程B的问题了。（部分进程受到影响）
最终结论：
经过对比你会发现，先更新数据库、再删除缓存是影响更小的方案。如果第二步出现失败的情况，则可以采用重试机制解决问题。

采用读写分离的架构怎么办：

如果数据库采用的是读写分离的架构，那么又会出现新的问题，如下图：
Redis面试问题 - 图29
进程A先删除缓存，再更新主数据库，然后主库将数据同步到从库。而在主从数据库同步之前，可能会有进程B访问了缓存，发现数据不存在，进而它去访问从库获取到旧的数据，然后同步到缓存。这样，最终也会导致缓存与数据库的数据不一致。这个问题的解决方案，依然是采用延时双删的策略，但是在评估延长时间的时候，要考虑到主从数据库同步的时间。
第二次删除失败了怎么办？
如果第二次删除依然失败，则可以增加重试的次数，但是这个次数要有限制，当超出一定的次数时，要采取报错、记日志、发邮件提醒等措施。

高可用

1. 如何实现Redis的高可用？

实现Redis的高可用，主要有哨兵和集群两种方式。
哨兵：
Redis Sentinel（哨兵）是一个分布式架构，它包含若干个哨兵节点和数据节点。每个哨兵节点会对数据节点和其余的哨兵节点进行监控，当发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它就会与其他的哨兵节点进行协商，当多数哨兵节点都认为主节点不可达时，它们便会选举出一个哨兵节点来完成自动故障转移的工作，同时还会将这个变化实时地通知给应用方。整个过程是自动的，不需要人工介入，有效地解决了Redis的高可用问题！
一组哨兵可以监控一个主节点，也可以同时监控多个主节点，两种情况的拓扑结构如下图：
Redis面试问题 - 图30
哨兵节点包含如下的特征：

  1. 哨兵节点会定期监控数据节点、其他哨兵节点是否可达；
  2. 哨兵节点会将故障转移的结果通知给应用方；
  3. 哨兵节点可以将从节点晋升为主节点，并维护后续正确的主从关系；
  4. 哨兵模式下，客户端连接的是哨兵节点集合，从中获取主节点信息；
  5. 节点的故障判断是由多个哨兵节点共同完成的，可有效地防止误判；
  6. 哨兵节点集合是由多个哨兵节点组成的，即使个别哨兵节点不可用，整个集合依然是健壮的；
  7. 哨兵节点也是独立的Redis节点，是特殊的Redis节点，它们不存储数据，只支持部分命令。

集群：
Redis集群采用虚拟槽分区来实现数据分片，它把所有的键根据哈希函数映射到0-16383整数槽内，计算公式为slot=CRC16(key)&16383，每一个节点负责维护一部分槽以及槽所映射的键值数据。虚拟槽分区具有如下特点：

  1. 解耦数据和节点之间的关系，简化了节点扩容和收缩的难度；
  2. 节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区元数据；
  3. 支持节点、槽、键之间的映射查询，用于数据路由，在线伸缩等场景。

Redis集群中数据的分片逻辑如下图：
Redis面试问题 - 图31

2. 主从复制

主从复制：主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，master以写为主，slave以读为主
应用场景

  • 读写分离
  • 容灾恢复

1）一主二从
Redis面试问题 - 图32

  1. 修改配置文件（3个）
    • 拷贝多个redis.conf文件
    • 开启daemonize yes
    • 修改pid文件名
    • 指定启动端口（6379、6380、6381）
    • 修改log文件名
    • 修改dump.rdb文件名
  2. 启动redis服务 ```shell redis-server redis6379.conf redis-server redis6380.conf redis-server redis6381.conf

redis-cli -h 127.0.0.1 -p 6379 redis-cli -h 127.0.0.1 -p 6380 redis-cli -h 127.0.0.1 -p 6381


3. 增加主从关系
```shell
slaveof <主库ip> <主库port>

# 查看当前服务器状态 
info replication

master:
Redis面试问题 - 图33

slave:
Redis面试问题 - 图34

注意：

  • 主机写，从机读
  • 主机shutdowm后从机进入待机状态，等主机回来后，主机新增记录从机可以顺利复制
  • 从机shutdowm后，每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件
  • 从机复制到的数据，会被本机持久化。就算shutdown断开连接依然会有数据。
  • 重新连接或者变更master，会清除之前的数据，重新建立拷贝最新的数据

2）薪火相传

  • 指上一个Slave可以是下一个Slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master，可以有效减轻master的写压力，去中心化降低风险。

Redis面试问题 - 图35

  • 对于上面的三台机器：

    # 6379作为6380的master
slaveof 127.0.0.1 6379
# 6380作为6381的master(6380的角色依然是master)
slaveof 127.0.0.1 6380

  • 注意：

    • 中途变更转向：会清除之前的数据，重新建立拷贝最新的
    • 风险是一旦某个slaver宕机，后面的slaver都没法备份

3）哨兵模式

  • 能够后台监控Master库是否故障，如果故障了根据投票数自动将slave库转换为主库。一组sentinel能同时监控多个Master

Redis面试问题 - 图36

配置：

  • 在Master对应redis.conf同目录下新建sentinel.conf文件
  • 配置哨兵，在sentinel.conf文件中填入内容(可以配置多个)
    • 说明：最后一个数字1，表示主机挂掉后slave投票看让谁接替成为主机，得票数多少后成为主机。
    • sentinel monitor 被监控数据库名字 <ip> <port> 1
  • 启动哨兵模式(路径按照自己的需求进行配置)：redis-sentinel /myredis/sentinel.conf

注意：

  • 当master挂掉后，会通过选票进行选出下一个master。而且只有使用了sentinel.conf启动的才能开启选票
  • 原来的master回来后，很不幸变成了slave

复制原理

  • Slave启动成功连接到master后会发送一个sync命令

  • Master接到命令后启动后台的存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步

  • 全量复制：slave服务在接收到数据库文件数据后，将其存盘并加载到内存中

  • 增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步
  • 但是只要是重新连接master，一次完全同步（全量复制）将被自动执行

复制的缺点

  • 延时，由于所有的写操作都是在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使得这个问题更加严重

常用命令总结

命令 作用
slaveof 主库ip 主库端口 配置从库
info replication 查看redis主从复制的情况
slaveof no one 使当前数据库停止与其他数据库的同步，转成主数据库
sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1 配置哨兵，监视master
redis-sentinel /myredis/sentinel.conf 以哨兵模式启动redis

3. 请介绍Redis集群的实现方案

Redis集群的分区方案：
Redis集群采用虚拟槽分区来实现数据分片，它把所有的键根据哈希函数映射到0-16383整数槽内，计算公式为slot=CRC16(key)&16383，每一个节点负责维护一部分槽以及槽所映射的键值数据。虚拟槽分区具有如下特点：

  1. 解耦数据和节点之间的关系，简化了节点扩容和收缩的难度；
  2. 节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区元数据；
  3. 支持节点、槽、键之间的映射查询，用于数据路由，在线伸缩等场景。

Redis集群中数据的分片逻辑如下图：
Redis面试问题 - 图37
Redis集群的功能限制：
Redis集群方案在扩展了Redis处理能力的同时，也带来了一些使用上的限制：

  1. key批量操作支持有限。如mset、mget，目前只支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key由于执行mset、mget等操作可能存在于多个节点上所以不被支持。
  2. key事务操作支持有限。同理只支持多key在同一节点上的事务操作，当多个key分布在不同的节点上时无法使用事务功能。
  3. key作为数据分区的最小粒度，因此不能将一个大的键值对象（如hash、list等）映射到不同的节点。
  4. 不支持多数据库空间。单机下的Redis可以支持16个数据库，集群模式下只能使用一个数据库空间，即DB0。
  5. 复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。

Redis集群的通信方案：
在分布式存储中需要提供维护节点元数据信息的机制，所谓元数据是指：节点负责哪些数据，是否出现故障等状态信息。常见的元数据维护方式分为：集中式和P2P方式。
Redis集群采用P2P的Gossip（流言）协议，Gossip协议的工作原理就是节点彼此不断通信交换信息，一段时间后所有的节点都会知道集群完整的信息，这种方式类似流言传播。通信的大致过程如下：

  1. 集群中每个节点都会单独开辟一个TCP通道，用于节点之间彼此通信，通信端口号在基础端口号上加10000；
  2. 每个节点再固定周期内通过特定规则选择几个节点发送ping消息；
  3. 接收ping消息的节点用pong消息作为响应。

其中，Gossip协议的主要职责就是信息交换，而信息交换的载体就是节点彼此发送的Gossip消息，Gossip消息分为：meet消息、ping消息、pong消息、fail消息等。

  • meet消息：用于通知新节点加入，消息发送者通知接受者加入到当前集群。meet消息通信正常完成后，接收节点会加入到集群中并进行周期性的ping、pong消息交换。
  • ping消息：集群内交换最频繁的消息，集群内每个节点每秒向多个其他节点发送ping消息，用于检测节点是否在线和交换彼此状态信息。ping消息封装了自身节点和一部分其他节点的状态数据。
  • pong消息：当接收到meet、ping消息时，作为响应消息回复给发送方确认消息正常通信。pong消息内封装了自身状态数据，节点也可以向集群内广播自身的pong消息来通知整个集群对自身状态进行更新。
  • fail消息：当节点判定集群内另一个节点下线时，会向集群内广播一个fail消息，其他节点接收到fail消息之后把对应节点更新为下线状态。

虽然Gossip协议的信息交换机制具有天然的分布式特性，但它是有成本的。因为Redis集群内部需要频繁地进行节点信息交换，而ping/pong消息会携带当前节点和部分其他节点的状态数据，势必会加重带宽和计算的负担。所以，Redis集群的Gossip协议需要兼顾信息交换的实时性和成本的开销。

  • 集群里的每个节点默认每隔一秒钟就会从已知节点列表中随机选出五个节点，然后对这五个节点中最长时间没有发送过PING消息的节点发送PING消息，以此来检测被选中的节点是否在线。
  • 如果节点A最后一次收到节点B发送的PONG消息的时间，距离当前时间已经超过了节点A的超时选项设置时长的一半（cluster-node-timeout/2），那么节点A也会向节点B发送PING消息，这可以防止节点A因为长时间没有随机选中节点B作为PING消息的发送对象而导致对节点B的信息更新滞后。
  • 每个消息主要的数据占用：slots槽数组（2KB）和整个集群1/10的状态数据（10个节点状态数据约1KB）。

    4. 说一说Redis集群的应用和优劣势

    优势：
    Redis Cluster是Redis的分布式解决方案，在3.0版本正式推出，有效地解决了Redis分布式方面的需求。当遇到单机内存、并发、流量等瓶颈时，可以采用Cluster架构方案达到负载均衡的目的。
    劣势：
    Redis集群方案在扩展了Redis处理能力的同时，也带来了一些使用上的限制：
  1. key批量操作支持有限。如mset、mget，目前只支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key由于执行mset、mget等操作可能存在于多个节点上所以不被支持。
  2. key事务操作支持有限。同理只支持多key在同一节点上的事务操作，当多个key分布在不同的节点上时无法使用事务功能。
  3. key作为数据分区的最小粒度，因此不能将一个大的键值对象（如hash、list等）映射到不同的节点。
  4. 不支持多数据库空间。单机下的Redis可以支持16个数据库，集群模式下只能使用一个数据库空间，即DB0。
  5. 复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。

    如何利用Redis实现分布式Session？

    在web开发中，我们会把用户的登录信息存储在session里。而session是依赖于cookie的，即服务器创建session时会给它分配一个唯一的ID，并且在响应时创建一个cookie用于存储这个SESSIONID。当客户端收到这个cookie之后，就会自动保存这个SESSIONID，并且在下次访问时自动携带这个SESSIONID，届时服务器就可以通过这个SESSIONID得到与之对应的session，从而识别用户的身。如下图：
    Redis面试问题 - 图38
    现在的互联网应用，基本都是采用分布式部署方式，即将应用程序部署在多台服务器上，并通过nginx做统一的请求分发。而服务器与服务器之间是隔离的，它们的session是不共享的，这就存在session同步的问题了，如下图：
    Redis面试问题 - 图39
    如果客户端第一次访问服务器，请求被分发到了服务器A上，则服务器A会为该客户端创建session。如果客户端再次访问服务器，请求被分发到服务器B上，则由于服务器B中没有这个session，所以用户的身份无法得到验证，从而产生了不一致的问题。
    解决这个问题的办法有很多，比如可以协调多个服务器，让他们的session保持同步。也可以在分发请求时做绑定处理，即将某一个IP固定分配给同一个服务器。但这些方式都比较麻烦，而且性能上也有一定的消耗。更合理的方式就是采用类似于Redis这样的高性能缓存服务器，来实现分布式session。
    从上面的叙述可知，我们使用session保存用户的身份信息，本质上是要做两件事情。第一是保存用户的身份信息，第二是验证用户的身份信息。如果利用其它手段实现这两个目标，那么就可以不用session，或者说我们使用的是广义上的session了。
    具体实现的思路如下图，我们在服务端增加两段程序：
  • 第一是创建令牌的程序，就是在用户初次访问服务器时，给它创建一个唯一的身份标识，并且使用cookie封装这个标识再发送给客户端。那么当客户端下次再访问服务器时，就会自动携带这个身份标识了，这和SESSIONID的道理是一样的，只是改由我们自己来实现了。另外，在返回令牌之前，我们需要将它存储起来，以便于后续的验证。而这个令牌是不能保存在服务器本地的，因为其他服务器无法访问它。因此，我们可以将其存储在服务器之外的一个地方，那么Redis便是一个理想的场所。
  • 第二是验证令牌的程序，就是在用户再次访问服务器时，我们获取到了它之前的身份标识，那么我们就要验证一下这个标识是否存在了。验证的过程很简单，我们从Redis中尝试获取一下就可以知道结果。

Redis面试问题 - 图40