• String(字符串)
• Hash(哈希)
  适合存储对象。
  
  
•  List (列表)
  

   按照插入顺序排序，允许重复元素。
  
• Set(集合)
  无序集合，没有重复元素。
  
• Zset(有序集合)
   集合中每个元素关联一个分数（score），根据分数升序排序，没有重复元素。

（2）Redis 和 Memcached 有什么区别？

• 共同点
  • 都是基于内存的数据库，一般都用来当做缓存使用。
  • 都有过期策略。
  • 两者的性能都非常高。
• 不同点
  • Redis 支持的数据类型更丰富（String、Hash、List、Set、ZSet），而 Memcached 只支持最简单的 key-value 数据类型；
  • Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用，而 Memcached 没有持久化功能，数据全部存在内存之中，Memcached 重启或者挂掉后，数据就没了；
  • Redis 原生支持集群模式，Memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；
  • Redis 支持发布订阅模型、Lua 脚本、事务等功能，而 Memcached 不支持。

二、Redis数据类型

• 普通字符串的基本操作：
  
  
• 批量操作——在命令前加"M"：
  
• 计数器（字符串的内容为整数的时候可以使用）：
  
  
• 过期（默认为永不过期）：
  
• 不存在就插入：
  
  

• 缓存对象
  如缓存学生对象的json数据：{"id":1,"name":"xiaolin", "age":18}。
• ★分布式锁——SET命令+Lua脚本
  SET 命令有个 NX 参数可以实现「key不存在时才插入」，可以用它来实现分布式锁：
  • 如果 key 不存在，则显示插入成功，可以用来表示加锁成功；
  • 如果 key 存在，则会显示插入失败，可以用来表示加锁失败。
  一般为了避免客户端异常无法释放锁，还会对分布式锁加上过期时间：

  SET lock_key unique_value NX PX 10000
  

  • lock_key：key 键；
  • unique_value：是客户端生成的唯一的标识；
  • NX：代表只在 lock_key 不存在时，才对 lock_key 进行设置操作；
  • PX 10000：表示设置 lock_key 的过期时间为 10s。
  解锁的过程就是将 lock_key 键删除，但要保证解锁客户端就是加锁的那个客户端(解铃还须系铃人)。所以解锁时要先判断锁的 unique_value 是否为加锁客户端，是的话，才能将 lock_key 键删除进行解锁。所以解锁有两个操作(判断value+删除key)，这时就需要用 Lua 脚本来保证解锁的原子性：

  // 释放锁时，先比较 unique_value 是否相等，避免锁的误释放
  if redis.call("get",KEYS[1]) == ARGV[1] then
      return redis.call("del",KEYS[1])
  else
      return 0
  end

• 共享 Session 信息
  通常我们会使用 Session 来保存用户的会话(登录)状态，这些 Session 信息会被保存在服务器中，但如果是分布式系统，就会出现Session数据不同步问题。
  造成数据不同步的原因是session都是保存在各自服务器中，可以用 Redis 对session进行统一存储，即将每个服务器的session都存到一个Redis中，以此来实现共享session信息(解决session数据不同步问题)。
  
  

（1）内部实现

• 如果列表元素个数小于 512 个（默认值，可由 list-max-ziplist-entries 配置），列表每个元素的值都小于 64 字节（默认值，可由 list-max-ziplist-value 配置），Redis 会使用压缩列表作为 List 类型的底层数据结构；
• 如果列表元素不满足上面的条件，Redis 会使用双向链表作为 List 类型的底层数据结构；

• 消息队列的三个需求
  消息队列在存取消息时，必须要满足按先进先出的顺序存取(消息保序)、能处理重复的消息、保证消息的可靠性。
• 消息保序——LPUSH + RPOP
  List 本身就是按先进先出的顺序对数据进行存取的，可以使用 LPUSH + RPOP （或者反过来 RPUSH+LPOP）命令实现消息队列。
  ★如何解决消费者读取数据时的性能风险？——阻塞读取(BRPOP)
  ——生产者往 List 中写入数据时，List 并不会主动地通知消费者有新消息写入，所以消费者想要及时处理消息，就要不停地调用 RPOP 命令（比如使用一个while(1)循环）。所以即使没有新消息写入List，消费者也要不停地调用 RPOP 命令，这就会导致消费者程序的 CPU 一直消耗在执行 RPOP 命令上，带来不必要的性能损失。
  ——为了解决这个问题，Redis提供了 BRPOP 命令(阻塞式读取)，它的作用是在没有读到队列数据时，会自动阻塞，直到有新数据写入队列，再开始读取新数据。这种方式更能节省CPU开销。
  
• 处理重复消息——全局唯一 ID
  消费者要实现重复消息的判断，需要满足每个消息都有一个全局ID，并且消费者要能记录已经处理过的消息的ID。
  但是 List 不会自动为每个消息生成一个 ID，所以我们需要自己为每个消息生成一个全局唯一ID，在用把消息插入 List 时，要在消息中包含这个全局唯一 ID。(自行生成，插入包含)
  
• 保证消息可靠性——BRPOPLPUSH 留存消息
  当消费者从 List 中读取一条消息后，List 就不会再留存这条消息了（阅完既焚）。所以如果消费者没处理完消息就宕机了，当消费者再次启动后，就没法再次从 List 中读取该消息了。
  为了留存消息，可以用 BRPOPLPUSH 命令，它的作用是从 List 中读取消息的同时，再把这个消息插入到另一个 List（备份 List）中留存。
  

• 如果哈希类型元素个数小于 512 个（默认值，可由 hash-max-ziplist-entries 配置），所有值小于 64 字节（默认值，可由 hash-max-ziplist-value 配置）的话，Redis 会使用压缩列表作为 Hash 类型的底层数据结构；
• 如果哈希类型元素不满足上面条件，Redis 会使用哈希表作为 Hash 类型的底层数据结构。

（2）常用命令

• 缓存对象
  Hash 类型的 （key，field， value） 的结构与对象的（对象id， 属性， 值）的结构相似，也可以用来存储对象。我们以用户信息为例，它在关系型数据库中的结构是这样的：
  
  可以使用如下命令，将用户对象的信息存储到 Hash 类型：
  
  对应的Redis Hash 存储其结构如下图：
  
  

• List 可以存储重复元素，Set 不能存储重复元素；
• List 是按照元素的先后顺序存储元素的，而 Set 则是无序的。

（1）内部实现

• 如果集合中的元素都是整数且元素个数小于 512 （默认值，set-maxintset-entries配置）个，Redis 会使用整数集合作为 Set 类型的底层数据结构；
• 如果集合中的元素不满足上面条件，则 Redis 使用哈希表作为 Set 类型的底层数据结构。

（2）常用命令

• 常用操作命令
  
• 运算命令
  

• 点赞文章——同一个用户只能点赞一次
• 抽奖——保证每个用户只能中一次奖

5.Zset

        

（1）内部实现

• 如果有序集合的元素个数小于 128 个，并且每个元素的值小于 64 字节时，Redis 会使用压缩列表作为 Zset 类型的底层数据结构；
• 如果有序集合的元素不满足上面的条件，Redis 会使用跳表作为 Zset 类型的底层数据结构；

        在 Redis 7.0 中，压缩列表数据结构已经废弃了，交由 listpack(紧凑列表) 来实现了。

（2）常用命令

• 常用操作：
  
• 运算操作：
  
  

• 通过遍历的方式来统计字符串长度，因此时间复杂度为 O(n)；
• 字符串的结尾是以 “\0” 字符标识，字符串里面不能包含有 “\0” 字符，因此不能保存二进制数据；
• 字符串操作函数不高效且不安全，比如有缓冲区溢出的风险，有可能会造成程序运行终止。

• len，记录了字符串长度。这样获取字符串长度的时候，只需要返回这个成员变量值就行，时间复杂度只需要 O(1)。
• alloc，分配给字符数组的空间长度。这样在修改字符串的时候，可以通过 alloc - len 计算出剩余的空间大小，可以用来判断空间是否满足修改需求，如果不满足的话，就会自动将 SDS 的空间扩展至执行修改所需的大小，然后才执行实际的修改操作，所以使用 SDS 既不需要手动修改 SDS 的空间大小，也不会出现前面所说的缓冲区溢出的问题。
• flags，用来表示不同类型的 SDS。一共有 5 种类型的sds，分别是 sdshdr5、sdshdr8、sdshdr16、sdshdr32 和 sdshdr64。
• buf[]，字符数组，用来保存实际数据。不仅可以保存字符串，也可以保存二进制数据。

4.链表

• 获取某个节点的前置节点或后置节点的时间复杂度只需O(1)；
• list 结构因为提供了表头指针 head 和表尾节点 tail，所以获取链表的表头节点和表尾节点的时间复杂度只需O(1)；
• list 结构因为提供了链表节点数量 len，所以获取链表中的节点数量的时间复杂度只需O(1)；
• listNode 链表节使用 void* 指针保存节点值，并且可以通过 list 结构的 dup、free、match 函数指针为节点设置该节点类型特定的函数，因此链表节点可以保存各种不同类型的值；

• 链表每个节点之间的内存都是不连续的，意味着无法很好利用 CPU 缓存。能很好利用 CPU 缓存的数据结构就是数组，因为数组的内存是连续的，这样就可以充分利用 CPU 缓存来加速访问。
• 保存一个链表节点的值都需要一个链表节点结构头的分配，内存开销较大。因此，Redis 3.0 的 List 对象在数据量比较少的情况下，会采用「压缩列表」作为底层数据结构的实现，它的优势是节省内存空间，并且是内存紧凑型的数据结构。

5.压缩列表

• 查找复杂度高
  查找元素时只能逐个查找，此时的复杂度就是 O(N) 了，因此压缩列表不适合保存过多的元素。
• ★连锁更新(类似多米诺骨牌)
  压缩列表新增或修改某个元素时，如果空间不够，压缩列表占用的内存空间就需要重新分配。当这个元素较大时，可能会导致后续元素的 prevlen(记录了前一个节点的长度) 占用空间都发生变化，从而引起「连锁更新」问题，导致每个元素的空间都要重新分配，造成访问压缩列表性能的下降。这种在特殊情况下产生的连续多次空间扩展操作就叫做「连锁更新」。
  

• 给「哈希表 2」 分配空间，一般是「哈希表 1」的 2 倍；
• 将「哈希表 1 」的数据迁移到「哈希表 2」 中；
• 迁移完成后，「哈希表 1 」的空间会被释放，并把「哈希表 2」 设置为「哈希表 1」，然后在「哈希表 2」 新创建一个空白的哈希表，为下次 rehash 做准备。（角色互换）

• 整数集合升级有什么好处呢？
          如果要让一个数组同时保存 int16_t、int32_t、int64_t 类型的元素，可以直接使用 int64_t 类型的数组，但当元素都是 int16_t 类型的，就会造成内存浪费的情况。因此，整数集合升级的好处是节省内存资源。
• 整数集合支持降级操作吗？
          不支持，一旦升级，即使删除大间隔元素，也不会降级。
  

• 跳表节点的数据结构如下：
  
  Zset 需要同时保存元素和元素的权重，每个跳表节点都有一个指向前一个节点的指针，方便从跳表的尾节点开始访问节点(倒序查找)。
  跳表是一个带有层级关系的链表，而且每一层级可以包含多个节点，每一个节点通过指针连接起来，实现这一特性就是靠跳表节点结构体中的zskiplistLevel 结构体类型的 level 数组。level 数组中的每一个元素代表一层，定义了指向下一个跳表节点的指针和两个节点间的跨度。
  
• 跳表的结构体：
  跳表的结构体定义了跳表的头节点和尾节点，以及跳表的长度和最大层数。
  
  

• 如果当前节点的权重＜要查找的权重时，跳表就会继续遍历该层的下一个节点。
• 如果当前节点的权重 = 要查找的权重且当前元素＜要查找的数据时，跳表就会继续访问该层的下一个节点。

        如果上面两个条件都不满足，或者下一个节点为空时，跳表会跳到下一层继续查找。

（3）跳表每层节点数量设置

• 怎样才能维持相邻两层的节点数量的比例为 2 : 1 呢？
  Redis 跳表在创建节点的时候，会随机生成每个节点的层数，并没有严格维持相邻两层的节点数量比例为 2 : 1 。具体的做法是，跳表在创建节点时候，会生成范围为[0-1]的一个随机数，如果这个随机数小于 0.25（相当于概率 25%），那么层数就增加 1 层，然后继续生成下一个随机数，直到随机数的结果大于 0.25 结束，最终确定该节点的层数。这样做相当于每增加一层的概率不超过 25%，层数越高，概率越低，层高最大限制是 64。

• 从内存占用上来说，跳表比平衡树更灵活一些。平衡树每个节点包含 2 个指针（分别指向左右子树），而跳表每个节点包含的指针数目平均为 1/(1-p)，具体取决于参数 p 的大小。如果像 Redis里的实现一样，取 p=1/4，那么平均每个节点包含 1.33 个指针，比平衡树更有优势。
• 在做范围查找的时候，跳表比平衡树操作要简单。在平衡树上，我们找到指定范围的小值之后，还需要以中序遍历的顺序继续寻找其它不超过大值的节点。而在跳表上进行范围查找就非常简单，只需要在找到小值之后，对第 1 层链表进行若干步的遍历就可以找到其他不超过大值的节点。
• 从算法实现难度上来说，跳表比平衡树要简单得多。平衡树的插入和删除操作可能导致子树的调整，逻辑复杂；而跳表的插入和删除只需要修改相邻节点的指针，操作简单又快速。

• listpack 采用了压缩列表的很多优秀的设计，比如还是用一块连续的内存空间来紧凑地保存数据，并且为了节省内存的开销，listpack 节点会采用不同的编码方式保存不同大小的数据。
• quicklist 虽然通过控制 quicklistNode 结构里的压缩列表的大小或者元素个数，来减少连锁更新带来的性能影响，但是由于 quicklistNode 还是用了压缩列表来保存元素，所以 quicklist 并没有完全解决连锁更新的问题。
  压缩列表因为保存了前一个节点的长度字段，所以会有连锁更新的隐患。而 listpack 最大的特点是每个节点不再包含前一个节点的长度了

• Redis 是先执行写操作命令后，才将该命令记录到 AOF 日志里，为什么这样做？
  • ①避免额外的检查开销。如果先将写操作命令记录到 AOF 日志里，再执行该命令的话，如果当前的命令语法有问题，那么如果不进行命令语法检查，该错误的命令记录到 AOF 日志里后，Redis 在使用日志恢复数据时，就可能会出错。而如果先执行写操作命令再记录日志的话，只有在该命令执行成功后，才将命令记录到 AOF 日志里，这样就不用额外的检查开销，保证记录在 AOF 日志里的命令都是可执行并且正确的。
  • ②先写后记录，不会阻塞当前写操作的执行。
• AOF的缺陷？
  • ①执行写操作和记录日志是两个过程，如果执行了写操作但没来得及写入硬盘Redis就挂了，就会导致数据的丢失。
  • ②执行写操作和记录日志都是由主线程完成的，因此虽然不会阻塞当前写操作的执行，但可能阻塞下一条命令的执行。比如写入磁盘的速度太慢，下一条命令就迟迟执行不了。

（2）三种写回策略

• Always：表示每次写操作命令执行完后，同步将 AOF 日志数据写回硬盘；
• Everysec：每秒，表示每次写操作命令执行完后，先将命令写入到 AOF 文件的内核缓冲区，然后每隔一秒将缓冲区里的内容写回到硬盘；
• No：表示由操作系统决定何时将缓冲区内容写回硬盘。

• 如果想要高可靠，最大程度的保证数据不丢失，就选always，但是这可能阻塞主线程；
• 如果想要高性能，就选no，但是这可能导致数据丢失；
• Everysec就属于折中策略了。

• 这三种策略是通过控制 fsync() 函数的调用时机来实现的：
  • Always 策略就是每次写入 AOF 文件数据后，就执行 fsync() 函数；
  • Everysec 策略就会创建一个异步任务来执行 fsync() 函数；
  • No 策略就是永不执行 fsync() 函数

（3）AOF重写机制

（4）AOF后台重写

• AOF重写交给后台子进程的好处？
  • 由后台子进程执行重写操作，主进程可以继续处理其他命令，从而避免阻塞主进程；
  • ★交给后台子进程而不是线程，这是因为使用线程的话多线程之间会共享内存，在修改共享内存数据时需要加锁来保证数据的安全，这样就会降低性能；而使用子进程，父子进程会以只读的方式共享内存数据，当父子任意一方修改了共享数据，就会发生写时复制，不用加锁来保证数据安全。
• AOF重写一定不会阻塞主进程吗？
  不一定。
  -- 当发生写时复制时，主线程需要拷贝物理内存，会阻塞主线程；
  -- 当主进程收到信号后，调用信号处理函数时，会阻塞主进程。

（5）★写时复制

• 执行了 save 命令，就会在主线程生成 RDB 文件，由于和执行操作命令在同一个线程，所以如果写入 RDB 文件的时间太长，会阻塞主线程；
• 执行了 bgsave 命令，会创建一个子进程来生成 RDB 文件，这样可以避免主线程的阻塞；

        RDB 文件的加载是在Redis服务器启动时自动加载的，Redis 没有提供专门用于加载 RDB 文件的命令。

（2）RDB快照的缺点

• 如果频繁执行快照，可能会对 Redis 性能产生影响。
• 如果执行快照的频率太低，服务器故障时，丢失的数据会更多。因此在服务器发生故障时，RDB 快照丢失的数据会比 AOF 持久化的方式更多，因为 RDB 快照是全量快照的方式，执行的频率不能太频繁，而 AOF 日志可以以秒级的方式记录操作命令，所以丢失的数据就相对较少。

（3）执行快照时，数据能被修改吗？

4.★Redis 中大key的影响？

• 大key对持久化的影响：
  • 大key会影响AOF写回硬盘。AOF有三种写回策略：
    • 当采用always写回时，写回操作由主进程执行，因此如果写入的是一个大key，主进程在执行fsync()写回硬盘时可能会长时间阻塞其他操作的执行；
    • 当采用everysec写回时，由于是异步调用fsync()写回硬盘，因此持久化一个大key不会影响主进程；
    • 当采用no写回时，不会调用fsync()，所以持久化一个大key也不会影响主进程。
  • 大key可能会触发AOF重写机制。
    当 AOF 日志写入了很多的大 Key，AOF 日志文件的大小会很大，那么很快就会触发 AOF 重写机制。AOF重写时主进程会fork一个子进程进行重写AOF，将主进程的页表复制给子进程，而如果Redis在内存中保存了很多大key，对应的页表也会很大，那么复制页表耗时就很长，也就是说主进程fork子进程会花较长的时间，因此会阻塞主进程。而且如果在重写过程中主进程修改了共享内存中的大key，那么就会发生写时复制，将大key的物理内存复制一份，这个过程也会大量耗时，主进程会再次阻塞。
    
  • 由于RDB在用bgsave执行快照时，也是通过主进程fork子进程来实现的，所以大key也会像上面影响AOF重写那样影响RDB快照。
• 大key对客户端和服务器的影响：
  由于 Redis 执行命令是单线程处理，由于操作大 key 会比较耗时，因此会阻塞 Redis，从而导致客户端或服务器的长时间阻塞。

• 创建好key之后为其设置过期时间
  • expire <key> <n>：设置 key 在 n 秒后过期，比如 expire key 100 表示设置 key 在 100 秒后过期；
  • pexpire <key> <n>：设置 key 在 n 毫秒后过期，比如 pexpire key2 100000 表示设置 key2 在 100000 毫秒（100 秒）后过期。
  • expireat <key> <n>：设置 key 在某个时间戳（精确到秒）之后过期，比如 expireat key3 1655654400 表示 key3 在时间戳 1655654400 后过期（精确到秒）；
  • pexpireat <key> <n>：设置 key 在某个时间戳（精确到毫秒）之后过期，比如 pexpireat key4 1655654400000 表示 key4 在时间戳 1655654400000 后过期（精确到毫秒）
• 创建key-value的同时设置TTL
  • set <key> <value> ex <n> ：等价于 setex <key> <n> <valule>，设置键值对的时候，同时指定过期时间（精确到秒）；
  • set <key> <value> px <n> ：设置键值对的时候，同时指定过期时间（精确到毫秒）；
• 查看某个key的TTL
          TTL <key>
• 取消某个key的过期时间
          PERSIST <key>
  

（3）Redis 使用的过期删除策略

• Redis 如何实现惰性删除？
  • Redis 的惰性删除策略由 db.c 文件中的 expireIfNeeded() 函数实现：
    
  • 在访问或者修改 key 之前，都会调用 expireIfNeeded 函数对key进行检查，判断其是否过期：
    -- 如果过期，则删除该 key。在 Redis4.0 提供了一个参数 lazyfree_lazy_expire，来决定是异步删除，还是同步删除，该参数为1则异步删除，反之同步删除，然后返回 null 给客户端；
    -- 如果没有过期，不做任何处理，然后返回正常的键值对给客户端；
• Redis 如何实现定期删除的？
  • 定期删除是每隔一段时间随机检查一定数量的key，那么这个间隔时间和随机抽查的数量如何确定？
    • 间隔时间：在 Redis 中，默认是每秒进行 10 次过期检查，可在 Redis 的配置文件 redis.conf 中进行配置 hz 参数。
    • 随机抽查数：定期删除的实现是在 expire.c 文件下的 activeExpireCycle() 函数中，随机抽查数是由 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 定义的，它是写死在代码中的，数值是 20。也就是说每次过期检查时，会从过期字典中随机选择20个key进行判断。同时定期删除是个循环的过程，在一次检查中如果过期key占随机抽取数的比例大于25%，就会再抽取20个重复进行，直到比例小于25%或超过循环时间上限25ms。

2.内存淘汰策略

（2）★Redis 内存淘汰策略有哪些？

• 不进行数据淘汰的策略

  • noeviction：是Redis3.0之后默认的内存淘汰策略，它表示当Redis运行内存超过最大设置内存时，不淘汰任何数据。这样如果有新数据写入，就会触发 OOM，但是只要没有新数据写入，只是单纯的查询或者删除操作的话，Redis 还是可以正常工作。
• 进行数据淘汰的策略
  又可以细分为在设置了过期时间的数据中进行淘汰和在所有数据范围内进行淘汰这两类策略。

  • 在设置了过期时间的数据中进行淘汰：

    • volatile-random：随机淘汰设置了过期时间的任意键值；
    • volatile-ttl：优先淘汰更早过期的键值；
    • volatile-lru（Redis3.0 之前，默认的内存淘汰策略）：淘汰设置了过期时间且最久未使用的键值；
    • volatile-lfu（Redis 4.0 后新增的内存淘汰策略）：淘汰设置了过期时间且最少使用的键值；
  • 在所有数据范围内进行淘汰：

    • allkeys-random：随机淘汰任意键值;
    • allkeys-lru：淘汰所有键值对中最久未使用的键值；
    • allkeys-lfu（Redis 4.0 后新增的内存淘汰策略）：淘汰所有键值中最少使用的键值。

• 通过命令设置：通过 config set maxmemory-policy <策略> 命令设置。它的优点是设置之后立即生效，不需要重启 Redis 服务，缺点是重启 Redis 之后，设置就会失效。
• 修改配置文件：在 Redis 配置文件中设置 maxmemory-policy <策略> ，它的优点是重启 Redis 服务后配置不会丢失，缺点是必须重启 Redis 服务，设置才能生效。

（3）★LRU 算法和 LFU 算法有什么区别？Redis 如何实现这两个算法？

        1）LRU 算法

• 用链表管理数据，会带来额外的空间开销；
• 刚被访问的数据需要移动到表头，如果有大量数据被访问，就会带来很多链表移动操作，会很耗时，从而会降低 Redis 缓存性能。

• 不再用链表管理数据，节省了内存空间的占用；
• 不用在每次数据访问时都移动链表项，提高了Redis的性能。

        但是 Redis 实现的 LRU 算法还有一个问题——无法解决缓存污染问题，比如应用一次读取了大量的数据，但这些数据只会被读取这一次，那么这些数据就会在 Redis 中保留很长一段时间，造成缓存污染。因此，在 Redis 4.0 之后引入了 LFU 算法来解决缓存污染问题。

        2）LFU 算法

• 在 LRU 算法中，lru 字段用来记录 key 的访问时间戳，因此在 LRU 模式下，Redis可以根据对象头中的 lru 字段来淘汰最久未被使用的 key。
• 在 LFU 算法中，lru 字段被分成两段：

  • 高 16bit 记录key的访问时间戳
  • 低 8bit 记录key的访问频率，值越小表示访问频率越低，就越容易被淘汰。每个新key的logc初始值都为5。

• 第一阶段是建立链接、协商同步
  • 从服务器执行replicaof命令后，就会给主服务器发送psync命令要求同步数据，主服务器收到psync命令后，会用 FULLRESYNC 响应命令返回给从服务器，表示采用全量复制的进行数据同步。
    psync 命令包含两个参数，分别是主服务器的 runID 和复制进度 offset。
    • runID：每个 Redis 服务器在启动时都会自动生产一个随机的 ID 来唯一标识自己。当从服务器和主服务器第一次同步时，因为不知道主服务器的 runID，所以将其设置为 "?"。
    • offset：复制的进度，第一次同步时值为 -1。
    FULLRESYNC响应命令会带上主服务器的runID和当前复制进度offset。
• 第二阶段是主服务器将数据同步给从服务器
  • 主服务器会执行 bgsave 命令生成 RDB 文件，然后把文件发送给从服务器。从服务器收到 RDB 文件后，会先清空当前的数据，然后载入 RDB 文件。
  • ★由于主服务器是异步生成RDB文件，并未阻塞主进程，所以主进程仍可以处理写操作命令，但是这些写操作没有被写入RDB文件，这时主从数据就不一致了。Redis为了保证这种情况下的主从数据一致性，会将生成RDB文件、向从服务器发送RDB文件和从服务器加载RDB文件期间进行的写操作写入replication buffer缓冲区里。
• 第三阶段是主服务器将新的写操作命令发送给从服务器
  • 从服务器收到 RDB 文件，完成 RDB 的载入后，会回复一个确认消息给主服务器。主服务器会将 replication buffer 缓冲区里记录的写操作命令发送给从服务器来执行，这样主从服务器的数据就一致了。
• 至此，主从服务器的第一次同步就完成了。
  

• 由于是通过 bgsave 命令来生成 RDB 文件的，那么主服务器就会忙于 fork 子进程，如果主服务器的内存数据很大，在 fork 时会阻塞主线程；
• 传输 RDB 文件会占用主服务器的网络带宽，会对主服务器响应命令请求产生影响。

• 在 Redis 2.8 之前，如果主从服务器在命令同步时出现了网络断开又恢复的情况，主从服务器就会重新进行一次全量复制，很明显这样的开销太大了；
• 从 Redis 2.8 开始，网络断开又恢复后，主从服务器会采用增量复制的方式继续同步，只会把断开期间主服务器接收到的写操作命令同步给从服务器。

  • 在恢复网络后，从服务器会发送 psync 命令给主服务器，此时 offset 参数就不是 -1了；
  • 主服务器收到该命令后，然后用 CONTINUE 响应命令告诉从服务器接下来采用增量复制的方式同步数据；
  • 然后主服务将主从断线期间所执行的写命令发送给从服务器执行。
    

• 主服务器将写操作命令发送给从服务器时，还会将其写入repl_backlog_buffer 环形缓冲池。当网络恢复从服务器重新连上主服务器时，从服务器会通过 psync 命令将自己的复制偏移量 slave_repl_offset 发送给主服务器，主服务器将自己的复制偏移量  master_repl_offset 和从服务器复制偏移量进行比较判断从服务器要读的数据在不在 repl_backlog_buffer 中，来决定对从服务器执行全量同步还是增量同步：
  • 如果判断出从服务器要读取的数据还在 repl_backlog_buffer 缓冲区里，就会采用增量同步；
  • 如果判断出从服务器要读取的数据已经不在 repl_backlog_buffer 缓冲区里，就会采用全量同步。
• 当主服务器决定采用增量同步后，就会将增量数据写入到 replication buffer 复制缓冲区，然后将缓冲区里记录的写操作命令发送给从服务器来执行。
  

        ★主从复制常见面试题

• 1）选出新主节点
  从已下线主节点的所有从节点中，选择一个从节点，向其发送 SLAVEOF no one 命令(没有主节点了，你就是主节点！)，将这个从节点转换为主节点。
  从从节点中选的时候也不是随机选一个从节点，而是先过滤掉网络连接状态不好(与主节点断连超过10次)的从节点，再选择优先级高的从节点，如果优先级相同再选择复制进度高的从节点，再相同就选择id小的从节点。
  【tips】主节点知道所有从节点的信息，所以哨兵会每 10 秒向主节点发送 INFO 命令来获取从节点的信息。
  

• 2）将从节点指向新主节点
  leader 向所有从节点发送 SLAVEOF 命令，让它们成为新主节点的从节点。
  
• 3）通知客户端
  客户端可以通过发布订阅机制从哨兵订阅消息，主从切换完成后，哨兵就会发布新主节点的 IP 地址和端口的消息，然后客户端就可以收到这条信息，用新主节点的 IP 地址和端口进行通信了。
  
• 4）旧主节点恢复成为从节点
  哨兵还会继续监视旧主节点，当旧主节点重新上线时，哨兵集群就会向它发送 SLAVEOF 命令，让它成为新主节点的从节点。

七、缓存雪崩、击穿、穿透问题

• 大量缓存同时过期
  • 均匀设置过期时间
            在给缓存数据设置过期时间时，要避免将大量缓存设置成同一过期时间。比如可以给过期时间加上一个随机数。
  • 设置互斥锁
            如果发现访问的数据不在 Redis 里，就加个互斥锁，保证同一时间内只能有一个请求访问数据库，再将数据缓存到 Redis，然后释放锁。这样其他请求就可以从Redis中读取数据，而不用访问数据库了。
    【tips】实现互斥锁的时候，最好设置超时时间。
    
  • 双 key 策略
            对同一个缓存数据两个 key，一个主 key 设置过期时间，另一个备用 key 不设置过期时间，二者的 value 值是一样的，相当于给缓存数据做了个副本。当访问不到主 key 的缓存数据时，就直接返回备用 key 的缓存数据，然后在更新缓存的时候，同时更新两个key的数据。
    
  • 后台更新缓存
            不给缓存设置过期时间，将更新缓存的工作交给后台线程，当由于内存紧张淘汰一些缓存时，业务线程访问不到这些缓存数据，就会通过消息队列通知后台线程访问数据库更新缓存。
    
• Redis宕机
  • 服务熔断或请求限流机制
            由于 Redis 宕机而导致缓存雪崩时，可以启动服务熔断机制，拦截一切对数据库的访问，直接返回错误，从而降低对数据库的访问压力，保证数据库系统的正常运行，但是这样做会导致全部业务都无法正常工作。为了减少对业务的影响，我们可以启用请求限流机制，只让一部分请求访问数据库，等到 Redis 恢复正常后，再解除限流。
  • 构建 Redis 缓存高可靠集群
            服务熔断或请求限流都是雪崩发生后的应对措施，我们可以搭建Redis集群，当一个Redis宕机后，可以让其他Redis节点继续提供缓存服务。
    

• 限制非法请求
          当大量恶意请求访问不存在的数据时，也会发生缓存穿透。因此在 API 入口处我们要判断求请求参数是否合理，请求参数是否含有非法值、请求字段是否存在，如果判断出是恶意请求就直接返回错误，避免进一步访问缓存和数据库。
• 缓存空值或者默认值
          可以针对查询的不存在的数据，在缓存中设置一个空值或者默认值，这样后续请求就可以从缓存中读取到空值或者默认值，就不用查询数据库了。
• 使用布隆过滤器快速判断数据是否存在，避免通过查询数据库来判断数据是否存在
          向数据库保存数据时，用布隆过滤器做个标记。这样大量请求只需要查询 Redis 和布隆过滤器即可，不会查询数据库，保证了数据库的正常运行。

（3）布隆过滤器相关知识

（1）先更新缓存再更新数据库

• 重试机制
  引入mq，将要删除的缓存数据加到mq中，如果删除缓存失败，可以从mq中重新读到数据，再次尝试删除，这就是重试机制。我们还可以设定重试次数，当重试超过一定次数后，就返回一个错误信息；如果删除缓存成功，就把数据从mq移除。
• 订阅 MySQL binlog，再操作缓存
  我们可以通过 Canal 订阅数据库的 binlog 日志，拿到具体要操作的数据，然后再执行缓存删除。
  

• Redis是基于内存的，采用单线程去操作性能更高；
• 采用单线程可以避免不必要的上下文切换和多线程间的资源竞争，减少了时间和性能上的消耗；
• Redis使用IO多路复用技术来监听多个socket连接客户端，这样单线程也能处理多个请求。