Redis教程（操作、使用场景、ROB、AOF、常见机制问题、不好分类的暂存）

介绍

Redis 是一个开源的、支持网络、单进程单线程的、可基于内存、分布式、可选持久性的键值对(Key-Value)存储数据库.

Redis 与其他 key - value 缓存产品有以下三个特点：

1. Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。

• 与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
• Redis运行在内存中但是可以持久化到磁盘，所以在对不同数据集进行高速读写时需要权衡内存，因为数据量不能大于硬件内存。在内存数据库方面的另一个优点是，相比在磁盘上相同的复杂的数据结构，在内存中操作起来非常简单，这样Redis可以做很多内部复杂性很强的事情。同时，在磁盘格式方面他们是紧凑的以追加的方式产生的，因为他们并不需要进行随机访问。

2. Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作
3. Redis支持数据的备份，即master-slave模式的数据备份
4. 原子性，Redis的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来。

数据类型和底层

redis对象

• String: 字符串。 redis 的 string 可以包含任何数据。比如jpg图片或者序列化的对象。string 类型是 Redis最基本的数据类型，string 类型的值最大能存储 512MB。

• Hash: 散列。和String的区别在于，Hash中可以存多个字段， hash 是一个 string 类型的 field（字段） 和 value（值） 的映射表，hash 特别适合用于存储对象。

• List: 列表 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。

• Set: 集合 Set是 string 类型的无序集合。集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。

• Sorted Set: 有序集合（即zset） 区别在于可以通过给元素设置权重的方式改变集合的顺序。

• 高级数据类型：
  HyperLogLog、Geo、Pub/Sub

• Redis Module:
  BloomFilter，RedisSearch，Redis-ML

redis底层数据结构

看另一篇文章

Redis 哈希和字符串的区别 ——为什么字符串也可实现hash功能 还要用hash

假设我们要存一个学校的计算机信息的redis
使用字符串的方法：KEY为电脑信息前缀+学校名称+设备标识，value为具体信息json
使用字符串+序列化的方法 key是正常的 value是序列化后的 但是序列化和反序列化有一定的开销，同时每次更新属性都需要把全部数据取出进行反序列化，更新后再序列化到Redis中
使用hash的方法：KEY为电脑信息前缀+学校名称，哈希里面的key再分 设备标识

使用hash散列的优势

• 使用hash可以将数据放在同一个地方方便管理，而不必用字符串将数据放在整个数据库，而且还可以避免误操作。
• 使用hash散列既可以减少创建键的数量又可以避免键名冲突。
• 使用hash散列比使用字符串键更节约内存。因为在数据库中创建key都有数据库附加的管理信息（比如键的类型，最后一次访问时间等等），所以keys越多，服务器在存储附加管理信息方面消耗的内存就越多，同时花在管理数据库中key的cpu也会越多。而且redis本事也会对hash的存储做一些底层的优化，内存消耗更少。
• 某些redis可视化工具对hash友好 而且可以实现类似多层hash的结果
  

缺点
-大key问题 hash中元素很多会造成大key。
但是似乎读取单个不会影响。
由于redis单线程，可是如果getall 或者删除的时候 会造成阻塞！

但是字符串也有好处

• 使用过期功能
  因为redis的过期功能只能对键进行操作而不能对散列键的field进行操作。
• 对二进制存储的命令
  因为redis目前只支持对字符串键进行setbit,getbit,bitop等二进制相关的命令操作。

redis 命令、操作与使用场景

命令

详见菜鸟教程 https://www.runoob.com/redis/redis-data-types.html

• String: SET、GET GETSET MGET MSET SETEX SETNX INCR incrby decrby
• Hash:HSET、HGET、GETALL
  注：根据Redis 4.0.0，HMSET被视为已弃用。请在新代码中使用HSET。在之前，HSET仅能一次性加一个 而HMSET可以一次加多个
• List：RPUSH、LPUSH BLPOP、BRPOP 主要是是否阻塞
• SET SADD key member1 [member2]
• ZSET: ZADD key score1 member1 [score2 member2]、ZRANGEBYSCORE

setex = setnx + exppire的原子操作

通用的

• EXPIRE key 设置过期时间 ： 如果对锁延期可以用这个命令

使用场景

String 类型的应用场景：缓存对象、常规计数、分布式锁、共享 session 信息等。
List 类型的应用场景：可以实现栈 队列 以及 消息队列（但是有两个问题：1. 生产者需要自行实现全局唯一 ID；2. 不能以消费组形式消费数据）等。
Hash 类型：缓存对象、购物车等。
Set 类型：聚合计算（并集、交集、差集）场景，比如点赞、共同关注、共同感兴趣的tag、抽奖活动等。
Zset 类型：排序场景，比如排行榜、电话和姓名排序等。以及延时队列

Redis 后续版本又支持四种数据类型，它们的应用场景如下：

BitMap（2.2 版新增）：二值状态统计的场景，比如签到、判断用户登陆状态、连续签到用户总数等；
HyperLogLog（2.8 版新增）：海量数据基数统计的场景，比如百万级网页 UV 计数等；
GEO（3.2 版新增）：存储地理位置信息的场景，比如滴滴叫车；
Stream（5.0 版新增）：消息队列，相比于基于 List 类型实现的消息队列，有这两个特有的特性：自动生成全局唯一消息ID，支持以消费组形式消费数据。

string

• 普通缓存
• 计数器：经常可以被用来做计数器，如微博的评论数、点赞数、分享数，抖音作品的收藏数，京东商品的销售量、评价数等。
• 限速器：如验证码接口访问频率限制，用户登陆时需要让用户输入手机验证码，从而确定是否是用户本人，但是为了短信接口不被频繁访问，会限制用户每分钟获取验证码的频率，例如一分钟不能超过5次。
• 分布式ID：由于Redis自增自减的操作是原子性的因此也经常在分布式系统中用来生成唯一的订单号、序列号等。
• 分布式锁
• 分布式系统共享session

哈希hash

购物车
计数器 如当日访问量等

列表list

lpush+lpop=Stack（栈）
lpush+rpop=Queue（队列）
lpush+ltrim=Capped Collection（有限集合）
lpush+brpop=Message Queue（消息队列）

集合

因此集合类型比较适合用来数据去重和保障数据的唯一性，还可以用来统计多个集合的交集、错集和并集等，当我们存储的数据是无序并且需要去重的情况下，比较适合使用集合类型进行存储。

标签系统

集合类型比较典型的使用场景是标签（tag）。

给用户添加标签。

sadd user:1:tags tag1 tag2 tag5
sadd user:2:tags tag2 tag3 tag5
...
sadd user:k:tags tag1 tag2 tag4
...

给标签添加用户

sadd tag1:users user:1 user:3
sadd tag2:users user:1 user:2 user:3
...
sadd tagk:users user:1 user:2
...

使用sinter命令，可以来计算用户共同感兴趣的标签

sinter user:1:tags user:2:tags

这种标签系统在电商系统、社交系统、视频网站，图书网站，旅游网站等都有着广泛的应用。例如一个用户可能对娱乐、体育比较感兴趣，另一个用户可能对历史、新闻比较感兴趣，这些兴趣点就是标签。有了这些数据就可以得到喜欢同一个标签的人，以及用户的共同喜好的标签，这些数据对于用户体验以及增强用户黏度比较重要。例如一个社交系统可以根据用户的标签进行好友的推荐，已经用户感兴趣的新闻的推荐等，一个电子商务的网站会对不同标签的用户做不同类型的推荐，比如对数码产品比较感兴趣的人，在各个页面或者通过邮件的形式给他们推荐最新的数码产品，通常会为网站带来更多的利益。

抽奖系统

Redis集合的 SPOP(随机移除并返回集合中一个或多个元素) 和 SRANDMEMBER(随机返回集合中一个或多个元素) 命令可以帮助我们实现一个抽奖系统

如果允许重复中奖，可以使用SRANDMEMBER 命令

//添加抽奖名单
127.0.0.1:6379> SADD lucky:1 Tom
(integer) 1
127.0.0.1:6379> SADD lucky:1 Jerry
(integer) 1
127.0.0.1:6379> SADD lucky:1 John
(integer) 1
127.0.0.1:6379> SADD lucky:1 Marry
(integer) 1
127.0.0.1:6379> SADD lucky:1 Sean
(integer) 1
127.0.0.1:6379> SADD lucky:1 Lindy
(integer) 1
127.0.0.1:6379> SADD lucky:1 Echo
(integer) 1

//抽取三等奖3个
127.0.0.1:6379> SRANDMEMBER lucky:1 3
1) "John"
2) "Echo"
3) "Lindy"
//抽取二等奖2个
127.0.0.1:6379> SRANDMEMBER lucky:1 2
1) "Sean"
2) "Lindy"
//抽取一等奖1个
127.0.0.1:6379> SRANDMEMBER lucky:1 1
1) "Tom"    

如果不允许重复中奖，可以使用 SPOP 命令

//添加抽奖名单
127.0.0.1:6379> SADD lucky:1 Tom
(integer) 1
127.0.0.1:6379> SADD lucky:1 Jerry
(integer) 1
127.0.0.1:6379> SADD lucky:1 John
(integer) 1
127.0.0.1:6379> SADD lucky:1 Marry
(integer) 1
127.0.0.1:6379> SADD lucky:1 Sean
(integer) 1
127.0.0.1:6379> SADD lucky:1 Lindy
(integer) 1
127.0.0.1:6379> SADD lucky:1 Echo
(integer) 1

//抽取三等奖3个
127.0.0.1:6379> SPOP lucky:1 3
1) "John"
2) "Echo"
3) "Lindy"
//抽取二等奖2个
127.0.0.1:6379> SPOP lucky:1 2
1) "Sean"
2) "Marry"
//抽取一等奖1个
127.0.0.1:6379> SPOP lucky:1 1
1) "Tom"   

有序集合

排行榜系统
电话号码(姓名)排序与筛选

redis事务

看另一篇文章

集群——如何实现高可用

主从复制
哨兵模式
切片集群

主从模式

主从模式：无法实现强一致性保证（主从数据时时刻刻保持一致），数据不一致是难以避免的。

第一次同步

后续同步

主从服务器在完成第一次同步后，双方之间就会维护一个 TCP 连接。

这个连接是长连接的，目的是避免频繁的 TCP 连接和断开带来的性能开销。

从库的从库

主服务器是可以有多个从服务器的，如果从服务器数量非常多，而且都与主服务器进行全量同步的话，就会带来两个问题：

由于是通过 bgsave 命令来生成 RDB 文件的，那么主服务器就会忙于使用 fork() 创建子进程，如果主服务器的内存数据非大，在执行 fork() 函数时是会阻塞主线程的，从而使得 Redis 无法正常处理请求；
传输 RDB 文件会占用主服务器的网络带宽，会对主服务器响应命令请求产生影响。
这种情况就好像，刚创业的公司，由于人不多，所以员工都归老板一个人管，但是随着公司的发展，人员的扩充，老板慢慢就无法承担全部员工的管理工作了。

要解决这个问题，老板就需要设立经理职位，由经理管理多名普通员工，然后老板只需要管理经理就好。

Redis 也是一样的，从服务器可以有自己的从服务器，我们可以把拥有从服务器的从服务器当作经理角色，它不仅可以接收主服务器的同步数据，自己也可以同时作为主服务器的形式将数据同步给从服务器，组织形式如下图：

那具体怎么做到的呢？

其实很简单，我们在「从服务器」上执行下面这条命令，使其作为目标服务器的从服务器：

replicaof <目标服务器的IP> 6379
此时如果目标服务器本身也是「从服务器」，那么该目标服务器就会成为「经理」的角色，不仅可以接受主服务器同步的数据，也会把数据同步给自己旗下的从服务器，从而减轻主服务器的负担。

网络波动后的增量复制

网络总是不按套路出牌的嘛，说延迟就延迟，说断开就断开。

如果主从服务器间的网络连接断开了，那么就无法进行命令传播了，这时从服务器的数据就没办法和主服务器保持一致了，客户端就可能从「从服务器」读到旧的数据。

那么问题来了，如果此时断开的网络，又恢复正常了，要怎么继续保证主从服务器的数据一致性呢？

在 Redis 2.8 之前，如果主从服务器在命令同步时出现了网络断开又恢复的情况，从服务器就会和主服务器重新进行一次全量复制，很明显这样的开销太大了，必须要改进一波。

所以，从 Redis 2.8 开始，网络断开又恢复后，从主从服务器会采用增量复制的方式继续同步，也就是只会把网络断开期间主服务器接收到的写操作命令，同步给从服务器。

主要有三个步骤：

从服务器在恢复网络后，会发送 psync 命令给主服务器，此时的 psync 命令里的 offset 参数不是 -1；
主服务器收到该命令后，然后用 CONTINUE 响应命令告诉从服务器接下来采用增量复制的方式同步数据；
然后主服务将主从服务器断线期间，所执行的写命令发送给从服务器，然后从服务器执行这些命令。
那么关键的问题来了，主服务器怎么知道要将哪些增量数据发送给从服务器呢？

答案藏在这两个东西里：

repl_backlog_buffer，是一个「环形」缓冲区，用于主从服务器断连后，从中找到差异的数据；
replication offset，标记上面那个缓冲区的同步进度，主从服务器都有各自的偏移量，主服务器使用 master_repl_offset 来记录自己「写」到的位置，从服务器使用 slave_repl_offset 来记录自己「读」到的位置。

那 repl_backlog_buffer 缓冲区是什么时候写入的呢？

在主服务器进行命令传播时，不仅会将写命令发送给从服务器，还会将写命令写入到 repl_backlog_buffer 缓冲区里，因此 这个缓冲区里会保存着最近传播的写命令。

网络断开后，当从服务器重新连上主服务器时，从服务器会通过 psync 命令将自己的复制偏移量 slave_repl_offset 发送给主服务器，主服务器根据自己的 master_repl_offset 和 slave_repl_offset 之间的差距，然后来决定对从服务器执行哪种同步操作：

如果判断出从服务器要读取的数据还在 repl_backlog_buffer 缓冲区里，那么主服务器将采用增量同步的方式；
相反，如果判断出从服务器要读取的数据已经不存在 repl_backlog_buffer 缓冲区里，那么主服务器将采用全量同步的方式。
当主服务器在 repl_backlog_buffer 中找到主从服务器差异（增量）的数据后，就会将增量的数据写入到 replication buffer 缓冲区，这个缓冲区我们前面也提到过，它是缓存将要传播给从服务器的命令。

repl_backlog_buffer 缓行缓冲区的默认大小是 1M，并且由于它是一个环形缓冲区，所以当缓冲区写满后，主服务器继续写入的话，就会覆盖之前的数据。因此，当主服务器的写入速度远超于从服务器的读取速度，缓冲区的数据一下就会被覆盖。

那么在网络恢复时，如果从服务器想读的数据已经被覆盖了，主服务器就会采用全量同步，这个方式比增量同步的性能损耗要大很多。

因此，为了避免在网络恢复时，主服务器频繁地使用全量同步的方式，我们应该调整下 repl_backlog_buffer 缓冲区大小，尽可能的大一些，减少出现从服务器要读取的数据被覆盖的概率，从而使得主服务器采用增量同步的方式。

哨兵模式

在使用 Redis 主从服务的时候，会有一个问题，就是当 Redis 的主从服务器出现故障宕机时，需要手动进行恢复。

为了解决这个问题，Redis 增加了哨兵模式（Redis Sentinel），因为哨兵模式做到了可以监控主从服务器，并且提供主从节点故障转移的功能。

哨兵模式详细看https://xiaolincoding.com/redis/cluster/sentinel.html
下面只摘录一些比较重要的点

需要注意的是
哨兵节点主要负责三件事情：监控、选主、通知。

• 哨兵节点是如何监控节点的？又是如何判断主节点是否真的故障了？
• 根据什么规则选择一个从节点切换为主节点？
• 怎么把新主节点的相关信息通知给从节点和客户端呢

哨兵一般推荐三个及以上的奇数个，否则可能会因为自身网络问题而产生误判
而且在主从切换的过程中，还需要在哨兵集群中选出一个 leader，让 leader 来执行主从切换。

主从故障转移操作包含以下四个步骤：

第一步：在已下线主节点（旧主节点）属下的所有「从节点」里面，挑选出一个从节点，并将其转换为主节点。
第二步：让已下线主节点属下的所有「从节点」修改复制目标，修改为复制「新主节点」；
第三步：将新主节点的 IP 地址和信息，通过「发布者/订阅者机制」通知给客户端；
第四步：继续监视旧主节点，当这个旧主节点重新上线时，将它设置为新主节点的从节点；

哨兵集群终于完成主从切换的工作，那么新主节点的信息要如何通知给客户端呢？

这主要通过 Redis 的发布者/订阅者机制来实现的。每个哨兵节点提供发布者/订阅者机制，客户端可以从哨兵订阅消息。

切片集群（也叫集群模式）

当 Redis 缓存数据量大到一台服务器无法缓存时，就需要使用 Redis 切片集群（Redis Cluster ）方案，它将数据分布在不同的服务器上，以此来降低系统对单主节点的依赖，从而提高 Redis 服务的读写性能。

Redis Cluster 方案采用哈希槽（Hash Slot），来处理数据和节点之间的映射关系。在 Redis Cluster 方案中，一个切片集群共有 16384 个哈希槽，这些哈希槽类似于数据分区，每个键值对都会根据它的 key，被映射到一个哈希槽中

• 分区的优势

通过利用多台计算机内存的和值，允许我们构造更大的数据库。
通过多核和多台计算机，允许我们扩展计算能力；通过多台计算机和网络适配器，允许我们扩展网络带宽。

• 分区的不足

redis的一些特性在分区方面表现的不是很好：
涉及多个key的操作通常是不被支持的。举例来说，当两个set映射到不同的redis实例上时，你就不能对这两个set执行交集操作。
涉及多个key的redis事务不能使用。
当使用分区时，数据处理较为复杂，比如你需要处理多个rdb/aof文件，并且从多个实例和主机备份持久化文件。
增加或删除容量也比较复杂。redis集群大多数支持在运行时增加、删除节点的透明数据平衡的能力，但是类似于客户端分区、代理等其他系统则不支持这项特性。然而，一种叫做presharding的技术对此是有帮助的。

• 分区的类型 范围分区 哈希分区 一致性哈希分区

可见:https://www.jianshu.com/p/528ce5cd7e8f

分区类型
Redis 有两种类型分区。 假设有4个Redis实例 R0，R1，R2，R3，和类似user:1，user:2这样的表示用户的多个key，对既定的key有多种不同方式来选择这个key存放在哪个实例中。也就是说，有不同的系统来映射某个key到某个Redis服务。

范围分区
最简单的分区方式是按范围分区，就是映射一定范围的对象到特定的Redis实例。

比如，ID从0到10000的用户会保存到实例R0，ID从10001到 20000的用户会保存到R1，以此类推。

这种方式是可行的，并且在实际中使用，不足就是要有一个区间范围到实例的映射表。这个表要被管理，同时还需要各 种对象的映射表，通常对Redis来说并非是好的方法。

哈希分区
另外一种分区方法是hash分区。这对任何key都适用，也无需是object_name:这种形式，像下面描述的一样简单：

用一个hash函数将key转换为一个数字，比如使用crc32 hash函数。对key foobar执行crc32(foobar)会输出类似93024922的整数。
对这个整数取模，将其转化为0-3之间的数字，就可以将这个整数映射到4个Redis实例中的一个了。93024922 % 4 = 2，就是说key foobar应该被存到R2实例中。注意：取模操作是取除的余数，通常在多种编程语言中用%操作符实现。

脑裂与数据丢失

先来理解集群的脑裂现象，这就好比一个人有两个大脑，那么到底受谁控制呢？

那么在 Redis 中，集群脑裂产生数据丢失的现象是怎样的呢？

在 Redis 主从架构中，部署方式一般是「一主多从」，主节点提供写操作，从节点提供读操作。 如果主节点的网络突然发生了问题，它与所有的从节点都失联了，但是此时的主节点和客户端的网络是正常的，这个客户端并不知道 Redis 内部已经出现了问题，还在照样的向这个失联的主节点写数据（过程A），此时这些数据被旧主节点缓存到了缓冲区里，因为主从节点之间的网络问题，这些数据都是无法同步给从节点的。

这时，哨兵也发现主节点失联了，它就认为主节点挂了（但实际上主节点正常运行，只是网络出问题了），于是哨兵就会在「从节点」中选举出一个 leader 作为主节点，这时集群就有两个主节点了 —— 脑裂出现了。

然后，网络突然好了，哨兵因为之前已经选举出一个新主节点了，它就会把旧主节点降级为从节点（A），然后从节点（A）会向新主节点请求数据同步，因为第一次同步是全量同步的方式，此时的从节点（A）会清空掉自己本地的数据，然后再做全量同步。所以，之前客户端在过程 A 写入的数据就会丢失了，也就是集群产生脑裂数据丢失的问题。

总结一句话就是：由于网络问题，集群节点之间失去联系。主从数据不同步；重新平衡选举，产生两个主服务。等网络恢复，旧主节点会降级为从节点，再与新主节点进行同步复制的时候，由于会从节点会清空自己的缓冲区，所以导致之前客户端写入的数据丢失了。

再来举个例子。

假设我们将 min-slaves-to-write 设置为 1，把 min-slaves-max-lag 设置为 12s，把哨兵的 down-after-milliseconds 设置为 10s，主库因为某些原因卡住了 15s，导致哨兵判断主库客观下线，开始进行主从切换。

同时，因为原主库卡住了 15s，没有一个从库能和原主库在 12s 内进行数据复制，原主库也无法接收客户端请求了。

这样一来，主从切换完成后，也只有新主库能接收请求，不会发生脑裂，也就不会发生数据丢失的问题了。

解决方案

当主节点发现从节点下线或者通信超时的总数量小于阈值时，那么禁止主节点进行写数据，直接把错误返回给客户端。

在 Redis 的配置文件中有两个参数我们可以设置：

min-slaves-to-write x，主节点必须要有至少 x 个从节点连接，如果小于这个数，主节点会禁止写数据。
min-slaves-max-lag x，主从数据复制和同步的延迟不能超过 x 秒，如果超过，主节点会禁止写数据。
我们可以把 min-slaves-to-write 和 min-slaves-max-lag 这两个配置项搭配起来使用，分别给它们设置一定的阈值，假设为 N 和 T。

这两个配置项组合后的要求是，主库连接的从库中至少有 N 个从库，和主库进行数据复制时的 ACK 消息延迟不能超过 T 秒，否则，主库就不会再接收客户端的写请求了。

即使原主库是假故障，它在假故障期间也无法响应哨兵心跳，也不能和从库进行同步，自然也就无法和从库进行 ACK 确认了。这样一来，min-slaves-to-write 和 min-slaves-max-lag 的组合要求就无法得到满足，原主库就会被限制接收客户端写请求，客户端也就不能在原主库中写入新数据了。

等到新主库上线时，就只有新主库能接收和处理客户端请求，此时，新写的数据会被直接写到新主库中。而原主库会被哨兵降为从库，即使它的数据被清空了，也不会有新数据丢失。

这是ap异步同步模型和zookeeper cp同步同步模型的很大的区别

数据的持久化与备份

持久化快照ROB

所谓内存快照，顾名思义就是给内存拍个照，在某个时刻把内存中的数据记录下来，以文件的形式保存到硬盘上，这样即使宕机，数据依然存在。在服务器重启后只需要把“照片”中的数据恢复即可。

自动触发与手动触发

RDB持久化就是把当前进程的数据在某个时刻生成快照(一个压缩的二进制文件)保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。

手动触发分别对应save和bgsave命令：

• save命令会阻塞当前Redis服务器，直到RDB过程完成为止。在服务器进程阻塞期间，服务器不能处理任何命令请求。因此，当save命令正在执行时，客户端发送的所有命令都会被拒绝，知道save命令执行完毕。
  Redis的单线程模型就决定了，我们要尽量避免所有会阻塞主线程的操作，由于Save命令执行期间阻塞服务器进程，对于内存比较大的实例会造成长时间阻塞，因此线上环境不建议使用。
• bgsave命令会派生出一个子进程(而不是线程)，由子进程进行RDB文件创建，而父进程继续处理命令。所以不会阻塞。
  • 在bgsave命令执行的时候，为了避免父进程与子进程同时执行两个rdbSave的调用而产生竞争条件，客户端发送的save命令会被服务器拒绝。
  • 如果bgsave命令正在执行，bgrewriteaof（aof重写）命令会被延迟到bgsave命令之后执行，如果bgrewriteaof命令正在执行，那么客户端发送的bgsave命令会被服务器拒绝。
  • 虽然bgsave命令是由子进程进行RDB文件的生成，但是fork()创建子进程的时候会阻塞父进程（详情请往下看）。

因为bgsave命令可以在不阻塞服务器进程的情况下保存，所以redis可以通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次bgsave命令。如：我们向服务器设置如下配置(这也是redis默认的配置):

save 900 1
save 300 10
save 60  10000

那么只要满足如下条件中的一个bgsave命令就会被执行：

服务器在900秒内对数据库进行了至少1次修改
服务器在300秒内对数据库进行了至少10次修改
服务器在60秒内对数据库进行了至少10000次修改

RDB文件的载入

在Redis启动的时候，只要检测到RDB文件的存在，就会自动加载RDB文件。需要注意的是

因为AOF文件的更新频率通常比RDB文件的更新频率高,所以口如果服务器开启了AOF持久化功能,那么服务器会优先使用AOF文件来还原数据库状态。

只有在AOF持久化功能处于关闭状态时,服务器才会使用RDB文件来还原数据库状态。

注意:服务器在载入RDB文件期间,会一直处于阻塞状态,直到载入工作完成为止

内存快照的问题

了解了什么是Redis的RDB持久化，我们来思考两个问题。

后台快照的时候数据可以修改吗——写时复制技术

Redis RDB持久化是对某一时刻的内存中的全量数据进行拍照。这让我们不得不思考，快照的时候数据可以修改吗？

首先，如果我们使用save命令做持久化，那么由于Redis单线程模型的原因，在持久化的过程中会阻塞，是不能执行其它命令的。也许有人会说可以使用bgave命令，但使用bgsave就没有问题了吗？

我们在拍照的时候，通常摄影师是不让我们动的，因为一动可能照片就模糊了。在Redis 进行内存快照的时候也会如此。如果我们持久化的过程中，有些数据被修改了。那么就会破坏快照的正确性与完整性。

比如在t时刻,我们对内存进行快照，此时我们希望的是记录下来t时刻内存中所有的数据，假设我们的RDB操作需要10s的时间，而t+2s我们执行了一个修改操作把Key1的值由A修改成了B，而此时RDB操作却还没有把Key1的值写入磁盘。在t+5s的时候读取到key1的值写入磁盘。那么此次快照记录的Key1的值就是B，而不是t时刻的A。这样就破坏了RDB文件的正确性。

RDB文件的生成是需要时间的，如果快照执行期间数据不能被修改，对于业务系统来说不能接受的。那么Redis 是如何解决这个问题的呢？

Redis 借助了操作系统提供的写时复制技术（Copy-On-Write, COW），可以让在执行快照的同时，正常处理写操作。简单来说，bgsave fork子进程的时候，并不会完全复制主进程的内存数据，而是只复制必要的虚拟数据结构，并不为其分配真实的物理空间，它与父进程共享同一个物理内存空间。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。此时，如果主线程对这些数据也都是读操作，那么，主线程和 bgsave 子进程相互不影响。
但是，如果主线程要修改一块数据，此时会给子进程分配一块物理内存空间，把要修改的数据复制一份，生成该数据的副本到子进程的物理内存空间。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。

执行 bgsave 命令的时候，会通过 fork() 创建子进程，此时子进程和父进程是共享同一片内存数据的，因为创建子进程的时候，会复制父进程的页表，但是页表指向的物理内存还是一个。

只有在发生修改内存数据的情况时，物理内存才会被复制一份。

这样的目的是为了减少创建子进程时的性能损耗，从而加快创建子进程的速度，毕竟创建子进程的过程中，是会阻塞主线程的。

如果主线程（父进程）要修改共享数据里的某一块数据（比如键值对 A）时，就会发生写时复制，于是这块数据的物理内存就会被复制一份（键值对 A’），然后主线程在这个数据副本（键值对 A’）进行修改操作。与此同时，bgsave 子进程可以继续把原来的数据（键值对 A）写入到 RDB 文件。

就是这样，Redis 使用 bgsave 对当前内存中的所有数据做快照，这个操作是由 bgsave 子进程在后台完成的，执行时不会阻塞主线程，这就使得主线程同时可以修改数据。

细心的同学，肯定发现了，bgsave 快照过程中，如果主线程修改了共享数据，发生了写时复制后，RDB 快照保存的是原本的内存数据，而主线程刚修改的数据，是没办法在这一时间写入 RDB 文件的，只能交由下一次的 bgsave 快照。

所以 Redis 在使用 bgsave 快照过程中，如果主线程修改了内存数据，不管是否是共享的内存数据，RDB 快照都无法写入主线程刚修改的数据，因为此时主线程（父进程）的内存数据和子进程的内存数据已经分离了，子进程写入到 RDB 文件的内存数据只能是原本的内存数据。

如果系统恰好在 RDB 快照文件创建完毕后崩溃了，那么 Redis 将会丢失主线程在快照期间修改的数据。

另外，写时复制的时候会出现这么个极端的情况。

在 Redis 执行 RDB 持久化期间，刚 fork 时，主进程和子进程共享同一物理内存，但是途中主进程处理了写操作，修改了共享内存，于是当前被修改的数据的物理内存就会被复制一份。

那么极端情况下，如果所有的共享内存都被修改，则此时的内存占用是原先的 2 倍。

所以，针对写操作多的场景，我们要留意下快照过程中内存的变化，防止内存被占满了。

可以频繁进行快照操作吗

假设我们在t 时刻做了一次快照，然后又在 t+n 时刻做了一次快照，而在这期间，发生了数据修改。而此时宕机了，那么，只能按照 t 时刻的快照进行恢复。那么这n秒的数据就彻底丢失无法恢复了。

所以，要想尽可能恢复数据，就只能缩短快照执行的时间间隔，间隔的时间越小，丢失数据也就越少。那么可以频繁的执行快照操作吗？

我们知道bgsave 执行时并不阻塞主线程，但是这不代表可以频繁执行快照操作。

一方面，持久化是一个写入磁盘的过程，频繁将全量数据写入磁盘，会给磁盘带来很大压力，频繁执行快照也容易导致前一个快照还没有执行完，后一个又开始了，这样多个快照竞争有限的磁盘带宽，容易造成恶性循环。

再者，bgsave所fork出来的子进程执行操作虽然并不会阻塞父进程的操作，但是fork出子进程的操作却是由主进程完成的，会阻塞主进程，fork子进程需要拷贝进程必要的数据结构，其中有一项就是拷贝内存页表（虚拟内存和物理内存的映射索引表），这个拷贝过程会消耗大量CPU资源，拷贝完成之前整个进程是会阻塞的，阻塞时间取决于整个实例的内存大小，实例越大，内存页表越大，fork阻塞时间也就越久。

也许有人会想到是否可以做增量快照呢？也就是只对上一次快照之后的数据做快照。

首先思路肯定是可以，但是增量快照要求记住哪些数据上一次快照之后产生的。这就需要额外的元数据来记录这些信息，会引入额外的空间消耗。这对于内存资源宝贵的 Redis 来说，并不是一个很好的方案。

如果不能频繁执行快照操作，那么该如何解决两次快照之间的数据丢失的问题呢？Redis 还提供了另外一种持久化方式——AOF(append to file)日志。

AOF

除了RDB(快照snapshots，即“拍照”将内存中的内容直接复制到硬盘的模式)持久化功能以外，Redis还提供了AOF(Append Only File)持久化功能。与RDB持久化通过保存数据库中的键值对来记录数据库状态不同，AOF持久化是通过保存Redis所执行的写命令来记录数据库状态的。

用 AOF 日志的方式来恢复数据其实是很慢的，因为 Redis 执行命令由单线程负责的，而 AOF 日志恢复数据的方式是顺序执行日志里的每一条命令，如果 AOF 日志很大，这个「重放」的过程就会很慢了。

注意到是先执行写操作后再写入日志

先写内存再刷盘得好处与问题

好处

• 如果是在命令执行前进行写日志的操作，一旦命令语法是错误的，不进行检查的话就会导致写入到日志文件中的命令是错误的，在使用日志文件恢复数据的时候就会出错。而在命令执行后在进行日志的写入则不会有这个问题。
• 不会阻塞当前写操作命令的执行：因为当写操作命令执行成功后，才会将命令记录到 AOF 日志。

当然，这样做也会带来风险：

• 数据可能会丢失： 如果刚执行完一个命令，还没有来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险。如果此时 Redis 是用作缓存，还可以从后端数据库重新读入数据进行恢复，但是，如果 Redis 是直接用作数据库的话，此时，因为命令没有记入日志，所以就无法用日志进行恢复了。
• 可能阻塞其他操作：AOF 虽然避免了对当前命令的阻塞，但却可能会给下一个操作带来阻塞风险。因为，AOF 日志是在主进程中执行的，如果在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行了

回写策略

针对上面可能阻塞其他操作得问题，Redis提供了缓冲区的方式进行AOF日志的记录。
即Redis在执行完命令进行持久化的时候，并非直接写入磁盘日志文件，而是先写入AOF缓冲区内，之后再通过某种策略写到磁盘

Redis AOF 机制提供了三种回写磁盘的策略。

• Always(同步写回): 命令写入 AOF缓冲区后调用系统 fsync操作同步到AOF文件, fsync完成后线程返回
• Everysec(每秒写回): 命令写人 AOF缓冲区后调用系统 write操作, write完成后线程返回。fsync同步文件操作由专门线程每秒调用一次
• No(操作系统自动写回): 命令写入 AOF缓冲区后调用系统 write操作,不对AOF文件做 fsync同步,同步硬盘操作由操作系统负责,通常同步周期最长30秒

配置为 always时,每次写入都要同步AOF文件,硬盘的写入速度无法与内存相提并论,显然与 Redis髙性能特性背道而驰

配置为no,由于操作系统每次同步AOF文件的周期不可控,而且会加大每次同步硬盘的数据量,虽然提升了性能,但数据安全性无法保证。

配置为 everysec,是建议的同步策略,也是默认配置,虽然能做到兼顾性能和数据安全性。但极端情况下一会造成1秒内的数据丢失。

大家知道这三种策略是怎么实现的吗？

深入到源码后，你就会发现这三种策略只是在控制 fsync() 函数的调用时机。
如果想要应用程序向文件写入数据后，能立马将数据同步到硬盘，就可以调用 fsync() 函数，这样内核就会将内核缓冲区的数据直接写入到硬盘，等到硬盘写操作完成后，该函数才会返回。

• Always 策略就是每次写入 AOF 文件数据后，就执行 fsync() 函数；
• Everysec 策略就会创建一个异步任务来执行 fsync() 函数；
• No 策略就是永不执行 fsync() 函数;

AOF重写机制

是什么

选择了合适的回写策略，AOF这种持久化的方式还有其它问题吗？

因为AOF持久化是通过保存被执行的写命令来记录数据库状态的,所以随着时间的流逝,AOF文件中的内容会越来越多,文件的体积也会越来越大,过大的AOF文件不仅追加命令会变慢，而且可能对Redis服务器、甚至整个宿主计算机造成影响,并且AOF文件的体积越大,使用AOF文件来进行数据还原所需的时间就越多。

这个时候就要用到AOF重写机制了 当 AOF 文件的大小超过所设定的阈值后，Redis 就会启用 AOF 重写机制，来压缩 AOF 文件。

redis> set testKey testValue
OK
redis> set testKey testValue1
OK
redis> del testKey
OK
redis> set testKey hello
OK
redis> set testKey world
OK

AOF 文件是以追加的方式，逐一记录接收到的写命令的。当一个键值对被多条写命令反复修改时，AOF 文件会记录相应的多条命令。如上示例，我们执行完命令后，Redis会在AOF里面追加5条命令。但实际上只需要set testKey world一条命令就够了。

AOF 重写机制就是在重写时，Redis 根据数据库的现状创建一个新的 AOF 文件，也就是说，读取数据库中的所有键值对，然后对每一个键值对用一条命令记录它的写入。比如说，当读取了键值对“testkey”: “world”之后，重写机制会记录 set testkey world这条命令。这样，当需要恢复时，可以重新执行该命令，实现“testkey”: “world”的写入。

这样，重写后的日志，从5条变成了1条，而对于可能被修改过成百上千次的键值对来说，重写能节省的空间就更大了。

虽然 AOF重写后，日志文件会缩小，但是，要把整个数据库的最新数据的操作日志都写回磁盘，仍然是一个非常耗时的过程。这时，我们不得不关注：重写会不会导致阻塞？这就要看看AOF重写的过程是怎么样的

重写过程

因为AOF重写也是一个非常耗时的过程，又因为Redis单线程的特性，同内存快照一样，AOF重写的过程也是由父进程fork出bgrewriteaof子进程来完成的.

使用子进程（而不是开启一个线程）进行AOF重写虽然可以避免使用锁的情况下，保证数据安全性，但是会带来子进程和父进程一致性问题。
例如在开始重写之后父进程又接收了新的键值对此时子进程是无法知晓的，当子进程重写完成后的数据库和父进程的数据库状态是不一致的。

在T6时刻服务器进程有了4个键，而子进程却只有1个键

为了解决这种不一致性，Redis设置了一个AOF重写缓冲区。

在子进程执行AOF重写期间。服务器进程需要执行以下3个动作：

• 执行客户端命令
• 执行后追加到AOF缓冲区
• 执行后追加到AOF重写缓冲区
• 子进程完成AOF重写后，它向父进程发送一个信号，父进程收到信号后会调用一个信号处理函数，该函数把AOF重写缓冲区的命令追加到新AOF文件中然后替换掉现有AOF文件。父进程处理完毕后可以继续接受客户端命令调用，可以看出在AOF后台重写过程中只有这个信号处理函数会阻塞服务器进程。

下表是完整的AOF后台重写过程：

这样就可以保证重写日志期间的所有操作也都会写入新的AOF文件。

需要注意的是， T7 T8执行的任务会阻塞服务器处理命令。

总的来说，就是每次 AOF 重写时，Redis 会先fork出一个子进程用于重写；然后，使用两个日志保证在重写过程中，新写入的数据不会丢失。

RDB 和 AOF 合体

尽管 RDB 比 AOF 的数据恢复速度快，但是快照的频率不好把握：

如果频率太低，两次快照间一旦服务器发生宕机，就可能会比较多的数据丢失；
如果频率太高，频繁写入磁盘和创建子进程会带来额外的性能开销。
那有没有什么方法不仅有 RDB 恢复速度快的优点和，又有 AOF 丢失数据少的优点呢？

当然有，那就是将 RDB 和 AOF 合体使用，这个方法是在 Redis 4.0 提出的，该方法叫混合使用 AOF 日志和内存快照，也叫混合持久化。

如果想要开启混合持久化功能，可以在 Redis 配置文件将下面这个配置项设置成 yes：

aof-use-rdb-preamble yes

混合持久化工作在 AOF 日志重写过程。

当开启了混合持久化时，在 AOF 重写日志时，fork 出来的重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件，然后主线程处理的操作命令会被记录在重写缓冲区里，重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。

也就是说，使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据。

这样的好处在于，重启 Redis 加载数据的时候，由于前半部分是 RDB 内容，这样加载的时候速度会很快。

加载完 RDB 的内容后，才会加载后半部分的 AOF 内容，这里的内容是 Redis 后台子进程重写 AOF 期间，主线程处理的操作命令，可以使得数据更少的丢失。

混合持久化优点：

• 混合持久化结合了 RDB 和 AOF 持久化的优点，开头为 RDB 的格式，使得 Redis 可以更快的启动，同时结合 AOF 的优点，有减低了大量数据丢失的风险。

混合持久化缺点：

• AOF 文件中添加了 RDB 格式的内容，使得 AOF 文件的可读性变得很差；
• 兼容性差，如果开启混合持久化，那么此混合持久化 AOF 文件，就不能用在 Redis 4.0 之前版本了。

一些机制、原理与问题

缓存穿透 击穿 雪崩

• 缓存穿透（根本不存在的）：key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。
  简单的解决方案 对不存在的数据缓存 但是过期时间很短

• 缓存击穿（单个key过期的一瞬间大量请求）：key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
  解决方案 不过期或者对访问业务互斥锁 同一时间只能一个

• 缓存雪崩（同一时间大范围key短过期）：当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。一个简单方案就时讲缓存失效时间分散开

应对缓存穿透的方案，常见的方案有三种。

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

Redis的过期策略和内存淘汰机制

过期策略 定期删除+惰性删除

我们set key的时候，都可以给一个expire time，就是过期时间，指定这个key比如说只能存活1个小时，我们自己可以指定缓存到期就失效。

如果假设你设置一个一批key只能存活1个小时，那么接下来1小时后，redis是怎么对这批key进行删除的？

答案是：定期删除+惰性删除

定期删除

说法1
　　所谓定期删除，Redis会将所有设置了过期时间的key放入一个字典中，然后每隔一段时间从字典中随机一些key检查其是否过期，如果过期就删除。如果这次刚好超过25%的key过期，则重复。

注意，这里不是每隔100ms就遍历所有的设置过期时间的key，那样就是一场性能上的灾难。

实际上redis是每隔100ms随机抽取一些key来检查和删除的。

同时，为了保证不出现循环过度的情况，Redis还设置了扫描的时间上限，默认不会超过25ms。

惰性删除

但是，定期删除可能会导致很多过期key到了时间并没有被删除掉，所以就得靠惰性删除了。

这就是说，在你获取某个key的时候，redis会检查一下 ，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除，不会给你返回任何东西。

并不是key到时间就被删除掉，而是你查询这个key的时候，redis再懒惰的检查一下

通过上述两种手段结合起来，保证过期的key一定会被干掉。

但是实际上这还是有问题的，如果定期删除漏掉了很多过期key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？

如果大量过期key堆积在内存里，导致redis内存块耗尽了，怎么办？

答案是：走内存淘汰机制。

内存淘汰机制

如果redis的内存占用过多的时候，此时会进行内存淘汰，有如下一些策略：

• noeviction：当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧

• allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）

• allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key，这个一般没人用吧

• volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key（这个一般不太合适）

• volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key

• volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除

LRU 算法和 LFU 算法

LRU 全称是 Least Recently Used 翻译为最近最少使用，会选择淘汰最近最少使用的数据。
LFU 全称是 Least Frequently Used 翻译为最近最不常用的，LFU 算法是根据数据访问次数来淘汰数据的，它的核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”。

Redis 主从模式中，对过期键会如何处理？

当 Redis 运行在主从模式下时，从库不会进行过期扫描，从库对过期的处理是被动的。也就是即使从库中的 key 过期了，如果有客户端访问从库时，依然可以得到 key 对应的值，像未过期的键值对一样返回。

从库的过期键处理依靠主服务器控制，主库在 key 到期时，会在 AOF 文件里增加一条 del 指令，同步到所有的从库，从库通过执行这条 del 指令来删除过期的 key。

注意事项

1. DEL/SET/GETSET等命令会清除过期时间
   　　在使用 DEL、SET、GETSET 等会覆盖key对应value的命令操作一个设置了过期时间的key的时候，会导致对应的key的过期时间被清除。

2. INCR/LPUSH/HSET等命令则不会清除过期时间
   　　而在使用 INCR/LPUSH/HSET 这种只是修改一个key的value，而不是覆盖整个value的命令，则不会清除key的过期时间。

3. PERSIST命令会清除过期时间

4. 使用RENAME命令，老key的过期时间将会转到新key上
   　　例如： RENAME KEY A KEY B 命令将KEYA重命名为KEYB，不管KEYB有没有设置过期时间，新的key KEYB将会继承KEY_A的所有特性。

这里篇幅有限，我就不一一将keya重命名到keyb的各个情况列出来，大家可以在自己电脑上试一下keya设置了过期时间，keyb没设置过期时间这种情况。

5. 使用EXPIRE/PEXPIRE设置的过期时间为负数或者使用EXPIREAT/PEXPIREAT设置过期时间戳为过去的时间会导致key被删除

EXPIRE：

EXPIREAT：

6. EXPIRE命令可以更新过期时间

对一个已经设置了过期时间的key使用expire命令，可以更新其过期时间。

在Redis2.1.3以下的版本中，使用expire命令更新一个已经设置了过期时间的key的过期时间会失败。并且对一个设置了过期时间的key使用LPUSH/HSET等命令修改其value的时候，会导致Redis删除该key。

大key的影响以及多大合适

由于redis单线程 可能会阻塞
redis-cli 的bigkeys 命令，可以帮助我们找到这些大key
删除大key用 unlink 命令（Redis 4.0+）因为该命令的删除过程是异步的，不会阻塞主线程。

key的大小多少合适
由于⽹络的⼀次传输MTU最⼤为1500字节，所以为了保证⾼效的性能，建议单个k-v⼤⼩不超过1KB，⼀次 ⽹络传输就能完成，避免多次⽹络交互；k-v是越⼩性能越好

当 AOF 写回策略配置了 Always 策略（另外两个是异步的不会影响主进程），如果写入是一个大 Key，主线程在执行 fsync() 函数的时候，阻塞的时间会比较久，因为当写入的数据量很大的时候，数据同步到硬盘这个过程是很耗时的。

AOF 重写机制和 RDB 快照（bgsave 命令）的过程，都会分别通过 fork() 函数创建一个子进程来处理任务。会有两个阶段会导致阻塞父进程（主线程）：

• 创建子进程的途中，由于要复制父进程的页表等数据结构，阻塞的时间跟页表的大小有关，页表越大，阻塞的时间也越长；
• 创建完子进程后，如果父进程修改了共享数据中的大 Key，就会发生写时复制，这期间会拷贝物理内存，由于大 Key 占用的物理内存会很大，那么在复制物理内存这一过程，就会比较耗时，所以有可能会阻塞父进程。

大 key 除了会影响持久化之外，还会有以下的影响：

• 客户端超时阻塞。由于 Redis 执行命令是单线程处理，然后在操作大 key 时会比较耗时，那么就会阻塞 Redis，从客户端这一视角看，就是很久很久都没有响应。

• 引发网络阻塞。每次获取大 key 产生的网络流量较大，如果一个 key 的大小是 1 MB，每秒访问量为 1000，那么每秒会产生 1000MB 的流量，这对于普通千兆网卡的服务器来说是灾难性的。

• 阻塞工作线程。如果使用 del 删除大 key 时，会阻塞工作线程，这样就没办法处理后续的命令。

• 内存分布不均。集群模型在 slot 分片均匀情况下，会出现数据和查询倾斜情况，部分有大 key 的 Redis 节点占用内存多。

如何避免大 Key 呢？

最好在设计阶段，就把大 key 拆分成一个一个小 key。或者，定时检查 Redis 是否存在大 key ，如果该大 key 是可以删除的，不要使用 DEL 命令删除，因为该命令删除过程会阻塞主线程，而是用 unlink 命令（Redis 4.0+）删除大 key，因为该命令的删除过程是异步的，不会阻塞主线程。

redis keys和scan

使用keys指令可以扫出指定模式的key列表。

对方接着追问：如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？
这个时候你要回答Redis关键的一个特性：Redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

不过，增量式迭代命令也不是没有缺点的：举个例子， 使用 SMEMBERS 命令可以返回集合键当前包含的所有元素， 但是对于 SCAN 这类增量式迭代命令来说， 因为在对键进行增量式迭代的过程中， 键可能会被修改， 所以增量式迭代命令只能对被返回的元素提供有限的保证 。

线程机制

Redis 是单线程吗？

Redis 单线程指的是「接收客户端请求->解析请求 ->进行数据读写等操作->发送数据给客户端」这个过程是由一个线程（主线程）来完成的，这也是我们常说 Redis 是单线程的原因。

但是，Redis 程序并不是单线程的，Redis 在启动的时候，是会启动后台线程（BIO）的：

Redis 在 2.6 版本，会启动 2 个后台线程，分别处理关闭文件、AOF 刷盘这两个任务；
Redis 在 4.0 版本之后，新增了一个新的后台线程，用来异步释放 Redis 内存，也就是 lazyfree 线程。例如执行 unlink key / flushdb async / flushall async 等命令，会把这些删除操作交给后台线程来执行，好处是不会导致 Redis 主线程卡顿。因此，当我们要删除一个大 key 的时候，不要使用 del 命令删除，因为 del 是在主线程处理的，这样会导致 Redis 主线程卡顿，因此我们应该使用 unlink 命令来异步删除大key。
之所以 Redis 为「关闭文件、AOF 刷盘、释放内存」这些任务创建单独的线程来处理，是因为这些任务的操作都是很耗时的，如果把这些任务都放在主线程来处理，那么 Redis 主线程就很容易发生阻塞，这样就无法处理后续的请求了。

后台线程相当于一个消费者，生产者把耗时任务丢到任务队列中，消费者（BIO）不停轮询这个队列，拿出任务就去执行对应的方法即可。

关闭文件、AOF 刷盘、释放内存这三个任务都有各自的任务队列：

• BIO_CLOSE_FILE，关闭文件任务队列：当队列有任务后，后台线程会调用 close(fd) ，将文件关闭；
• BIO_AOF_FSYNC，AOF刷盘任务队列：当 AOF 日志配置成 everysec 选项后，主线程会把 AOF 写日志操作封装成一个任务，也放到队列中。当发现队列有任务后，后台线程会调用 fsync(fd)，将 AOF 文件刷盘，
• BIO_LAZY_FREE，lazy free 任务队列：当队列有任务后，后台线程会 free(obj) 释放对象 / free(dict) 删除数据库所有对象 / free(skiplist) 释放跳表对象

为什么单线程还这么快

之所以 Redis 采用单线程（网络 I/O 和执行命令）那么快，有如下几个原因：

Redis 的大部分操作都在内存中完成，并且采用了高效的数据结构，因此 Redis 瓶颈可能是机器的内存或者网络带宽，而并非 CPU，既然 CPU 不是瓶颈，那么自然就采用单线程的解决方案了；
Redis 采用单线程模型可以避免了多线程之间的竞争，省去了多线程切换带来的时间和性能上的开销，而且也不会导致死锁问题。
Redis 采用了 I/O 多路复用机制处理大量的客户端 Socket 请求，IO 多路复用机制是指一个线程处理多个 IO 流，就是我们经常听到的 select/epoll 机制。简单来说，在 Redis 只运行单线程的情况下，该机制允许内核中，同时存在多个监听 Socket 和已连接 Socket。内核会一直监听这些 Socket 上的连接请求或数据请求。一旦有请求到达，就会交给 Redis 线程处理，这就实现了一个 Redis 线程处理多个 IO 流的效果。

数据库和缓存如何保证一致性?先写缓存还是先写数据库

看另一篇博客

redis高级

如高级数据结构应用 布隆过滤器等
分布式锁等
消息队列等
redis分布式等
看另一篇博客

不太重要的功能

Redis 管道技术

Redis 管道技术可以在服务端未响应时，客户端可以继续向服务端发送请求，并最终一次性读取所有服务端的响应。

管道技术（Pipeline）是客户端提供的一种批处理技术，用于一次处理多个 Redis 命令，从而提高整个交互的性能。

普通命令模式，如下图所示：

管道模式，如下图所示：

使用管道技术可以解决多个命令执行时的网络等待，它是把多个命令整合到一起发送给服务器端处理之后统一返回给客户端，这样就免去了每条命令执行后都要等待的情况，从而有效地提高了程序的执行效率。

但使用管道技术也要注意避免发送的命令过大，或管道内的数据太多而导致的网络阻塞。

要注意的是，管道技术本质上是客户端提供的功能，而非 Redis 服务器端的功能。

乱七八糟不好分类的暂时放这里