Redis重要知识点总结三

Redis

一、持久化（RDB、AOF）

Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。

1、RDB

RDB持久化是把进程数据生成快照保存到硬盘中，触发RDB持久化过程分为手动触发和自动触发。

触发机制(手动触发(save(阻塞，废弃了)、bgsave)、自动触发)

• 1、手动触发
  手动触发分别对应save和bgsave命令
  save命令：
  阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。
  bgsave命令：
  Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

  显然bgsave命令是针对save阻塞问题做的优化。因此Redis内部所有的涉及RDB的操作都采用bgsave的方式，而save命令已经废弃。

• 2、自动触发
  1）使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。
  2）如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
  3）执行debug reload命令重新加载Redis时，也会自动触发save操作。
  4）默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave。

流程说明

• 1）执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回。
• 2）父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats命令查看latest_fork_usec选项，
  可以获取最近一个fork操作的耗时，单位为微秒。
• 3）父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令。
• 4）子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的
  时间，对应info统计的rdb_last_save_time选项。
• 5）进程发送信号给父进程表示完成，父进程更新统计信息，具体见info Persistence下的rdb_*相关选项。

RDB文件处理

保存：
RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定。可以通过执行config set dir{newDir}和config set dbfilename{newFileName}
运行期动态执行，当下次运行时RDB文件会保存到新目录。

当遇到坏盘或磁盘写满等情况时，可以通过config set dir{newDir}在线修改文件路径到可用的磁盘路径，之后执行bgsave进行磁盘切换，同样适用 于AOF持久化文件。

压缩：
Redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可以通过参数config set rdbcompression{yes|no}动态修改。
运维提示
虽然压缩RDB会消耗CPU，但可大幅降低文件的体积，方便保存到硬盘或通过网络发送给从节点，因此线上建议开启。

RDB文件的优缺点

优点(加载速度快)

RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。

Redis加载RDB恢复数据远远快于AOF的方式。

缺点(不能实时持久化，因为要fork子线程)：

• 1、RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
• 2、RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。

针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方法。

2、AOF(文件格式，RDB是二进制，解决了数据持久化的实时性)

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

1、使用AOF

开启AOF功能需要设置配置：appendonly yes，默认不开启。AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。
保存路径同RDB持久化方式一致，通过dir配置指定。
AOF的工作流程操作：

• 命令写入 （append）
• 文件同步（sync）
• 文件重写（rewrite）
• 重启加载 （load）

• 1）所有的写入命令会追加到aof_buf（缓冲区）中。
• 2）AOF缓冲区根据对应的策略向硬盘做同步操作。
• 3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
• 4）当Redis服务器重启时，可以加载AOF文件进行数据恢复。

2、执行流程

命令写入

AOF命令写入的内容直接是文本协议格式。例如set hello world这条命令，在AOF缓冲区会追加如下文本：
*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n
Redis协议格式具体说明见4.1客户端协议小节，这里不再赘述，下面介绍关于AOF的两个疑惑：

• 1、AOF为什么直接采用文本协议格式？可能的理由如下：
  文本协议具有很好的兼容性。
  开启AOF后，所有写入命令都包含追加操作，直接采用协议格式，避免了二次处理开销。
  文本协议具有可读性，方便直接修改和处理。
• 2、AOF为什么把命令追加到aof_buf中？
  Redis使用单线程响应命令，如果每次写AOF文件命令都直接追加到硬盘，那么性能完全取决于当前硬盘负载。
  先写入缓冲区aof_buf中，还有另一个好处，Redis可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡。

文件同步

Redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制，不同值的含义如表5-1所示。
系统调用write和fsync说明：

• 1、write操作会触发延迟写（delayed write）机制。Linux在内核提供页缓冲区用来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步硬盘操作依赖于系统调度机制，例如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
• 2、fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞直到写入硬盘完成后返回，保证了数据持久化。
• 3、配置为always时，每次写入都要同步AOF文件，在一般的SATA硬盘上，Redis只能支持大约几百TPS写入，显然跟Redis高性能特性背道而驰， 不建议配置。
• 4、配置为no，由于操作系统每次同步AOF文件的周期不可控，而且会加大每次同步硬盘的数据量，虽然提升了性能，但数据安全性
  无法保证。
• 5、·配置为everysec，是建议的同步策略，也是默认配置，做到兼顾性能和数据安全性。理论上只有在系统突然宕机的情况下丢失
  1秒的数据。（严格来说最多丢失1秒数据是不准确的，5.3节会做具体介绍到。）

重写机制

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。
重写后的AOF文件为什么可以变小？
有如下原因：

• 1、进程内已经超时的数据不再写入文件。
• 2、旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set a111、set a222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。
• 3、多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。

AOF重写降低了文件占用空间，除此之外，另一个目的是：更小的AOF文件可以更快地被Redis加载。

AOF重写过程可以手动触发和自动触发：
·手动触发：直接调用bgrewriteaof命令。
·自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
·auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认为64MB。
·auto-aof-rewrite-percentage：代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值。

重启加载

3、文件校验

加载损坏的AOF文件时会拒绝启动。
对于错误格式的AOF文件，先进行备份，然后采用redis-check-aof–fix命令进行修复，修复后使用diff-u对比数据的差异，找出丢失的数据，有些可以人工修改补全。
AOF文件可能存在结尾不完整的情况，比如机器突然掉电导致AOF尾部文件命令写入不全。Redis为我们提供了aof-load-truncated配置来兼容这种情况，默认开启。加载AOF时，当遇到此问题时会忽略并继续启动。

二、 复制

replication 英[ˌreplɪ’keɪʃ(ə)n]

1、建立复制(slaveof)

参与复制的Redis实例划分为主节点（master）和从节点（slave）。默认情况下，Redis都是主节点。每个从节点只能有一个主节点，而主节点可以 同时具有多个从节点。
配置方式：

• 1、在配置文件中加入slaveof{masterHost}{masterPort}随Redis启动生效。
• 2、在redis-server启动命令后加入–slaveof{masterHost}{masterPort}生效。
• 3、直接使用命令：slaveof{masterHost}{masterPort}生效。
  slaveof本身是异步命令，执行slaveof命令时，节点只保存主节点信息后返回，后续复制流程在节点内部异步执行。
  主从节点复制成功建立后，可以使用info replication命令查看复制相关状态。
  replication 英[ˌreplɪ’keɪʃ(ə)n] 复制

复制的数据流是单向的，只能由主节点复制到从节点。
slaveof是异步命令

2、断开复制(slaveof no one)

slaveof命令不但可以建立复制，还可以在从节点执行slaveof no one来断开与主节点复制关系。
断开复制主要流程：

• 1、断开与主节点复制关系。
• 2、从节点晋升为主节点。
  从节点断开复制后并不会抛弃原有数据，只是无法再获取主节点上的数据变化。

3、slaveof切主操作

通过slaveof命令还可以实现切主操作，所谓切主是指把当前从节点对主节点的复制切换到另一个主节点。执行slaveof{newMasterIp}
{newMasterPort}命令即可，例如把6380节点从原来的复制6379节点变为复制6381节点，

切主操作流程如下：

• 1、断开与旧主节点复制关系。
• 2、与新主节点建立复制关系。
• 3、删除从节点当前所有数据。
• 4、对新主节点进行复制操作。

默认情况下，从节点使用slave-read-only=yes配置为只读模式。由于复制只能从主节点到从节点，对于从节点的任何修改主节点都无法感知，修改从节点会造成主从数据不一致。因此建议线上不要修改从节点的只读模式。

4、复制的传输延时

主从节点一般部署在不同机器上，复制时的网络延迟就成为需要考虑的问题，Redis为我们提供了repl-disable-tcp-nodelay参数用于控制是否关闭TCP_NODELAY，默认关闭，说明如下：

• 1、当关闭时，主节点产生的命令数据无论大小都会及时地发送给从节点，这样主从之间延迟会变小，但增加了网络带宽的消耗。适用于主从之间的网络环境良好的场景，如同机架或同机房部署。
• 2、当开启时，主节点会合并较小的TCP数据包从而节省带宽。默认发送时间间隔取决于Linux的内核，一般默认为40毫秒。这种配置节省了带宽但增大主从之间的延迟。适用于主从网络环境复杂或带宽紧张的场景，如跨机 房部署

5、拓扑

Redis的复制拓扑结构可以支持单层或多层复制关系，根据拓扑复杂性可以分为以下三种：一主一从、一主多从、树状主从结构，下面分别介绍

1、一主一丛结构

并发量高时，在从节点开启AOF，主节点不开启，但是主节点关机数据全部丢失(因为主节点没开启AOF)，不能开机，开机前要slaveof no one，不然从节点数据也全部丢失。

当应用写命令并发量较高且需要持久化时，可以只在从节点上开启AOF，这样既保证数据安全性同时也避免了持久化对主节点的性能干扰。但需要
注意的是，当主节点关闭持久化功能时，如果主节点脱机要避免自动重启操作。因为主节点之前没有开启持久化功能自动重启后数据集为空，这
时从节点如果继续复制主节点会导致从节点数据 也被清空的情况，丧失了持久化的意义。安全的做法是在从节点上执行 slaveof no one断开与主节点的复制关系，再重启主节点从而避免这一问题。

2、一主多从（利用多个从节点实现读写分离）

一主多从结构（又称为星形拓扑结构）使得应用端可以利用多个从节点实现读写分离（见图6-5）。对于读占比较大的场景，可以把读命令发送到从节点来分担主节点压力。同时在日常开发中如果需要执行一些比较耗时的读命令，如：keys、sort等，可以在其中一台从节点上执行，防止慢查询对主节点造成阻塞从而影响线上服务的稳定性。对于写并发量较高的场景，多个从节点会导致主节点写命令的多次发送从而过度消耗网络带宽，同时也加重了主节点的负载影响服务稳定性。为了解决这个问题，有了下面的树状主从。

总结：
读占比比较大的时候，可以把读命令发送到从节点来分担主节点压力。

3、树状主从结构（解决了一主多从的带宽问题）

树状主从结构（又称为树状拓扑结构）使得从节点不但可以复制主节点数据，同时可以作为其他从节点的主节点继续向下层复制。通过引入复制中间层，可以有效降低主节点负载和需要传送给从节点的数据量。如图6-6所示，数据写入节点A后会同步到B和C节点，B节点再把数据同步到D和E节 点，数据实现了一层一层的向下复制。当主节点需要挂载多个从节点时为了避免对主节点的性能干扰，可以采用树状主从结构降低主节点压力。

6、复制原理

复制过程大致分为6个过程：

• 1、保存主节点（master）信息
  执行slaveof后从节点只保存主节点的地址信息便直接返回，这时建立复制流程还没有开始，在从节点6380执行info replication可以看到如下信息：
  master_host:127.0.0.1
  master_port:6379
  master_link_status:down
  从统计信息可以看出，主节点的ip和port被保存下来，但是主节点的连接状态（master_link_status）是下线状态。
• 2、从节点（slave）内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接。从节点会建立一个socket套接字，例如图6-8中从节点建立了一个端口为24555的套接字，专门用于接受主节点发送的复制命令。从节点连接成功后 打印如下日志：
  Connecting to MASTER 127.0.0.1:6379
  MASTER <-> SLAVE sync started
  如果从节点无法建立链接，定时任务会无限重试直到连接成功或者执行slaveof no one取消复制。
• 3、发送ping命令
  连接建立成功后从节点发送ping请求进行首次通信，ping请求主要目的如下：
  检测主从之间网络套接字是否可用。
  检测主节点当前是否可接受处理命令。
• 4、权限验证
  如果主节点设置了requirepass参数，则需要密码验证，从节点必须配置masterauth参数保证与主节点相同的密码才能通过验证；
  如 果验证失败复制将终止，从节点重新发起复制流程。
• 5、同步数据集。
  主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分操作是耗时最长的步 骤。Redis在2.8版本以后采用新复制命令psync进行数据同步，原来的sync命 令依然支持，保证新旧版本的兼容性。新版
  同步划分两种情况：全量同步和 部分同步
• 6、命令持续复制。
  当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性

7、数据同步

全量复制

全量复制：一般用于初次复制场景，Redis早期支持的复制功能只有全量复制，它会把主节点全部数据一次性发送给从节点，当数据量较大时，会对主从节点和网络造成很大的开销。

部分复制

部分复制：用于处理在主从复制中因网络闪断等原因造成的数据丢失场景，当从节点再次连上主节点后，如果条件允许，主节点会补发丢失数据 给从节点。因为补发的数据远远小于全量数据，可以有效避免全量复制的过高开销

8、心跳

主从节点在建立复制后，它们之间维护着长连接并彼此发送心跳命令。

主从心跳判断机制：

• 1、主从节点彼此都有心跳检测机制，各自模拟成对方的客户端进行通信，通过client list命令查看复制相关客户端信息，主节点的连接状态为flags=M，从节点连接状态为flags=S。
• 2、主节点默认每隔10秒对从节点发送ping命令，判断从节点的存活性和连接状态。可通过参数repl-ping-slave-period控制发送频率。
• 3、从节点在主线程中每隔1秒发送replconf ack{offset}命令，给主节点上报自身当前的复制偏移量。replconf命令主要作用如下：
  1、实时监测主从节点网络状态。
  2、实现保证从节点的数量和延迟性功能，通过min-slaves-to-write、min-slaves-max-lag参数配置定义

9、异步复制

主节点不但负责数据读写，还负责把写命令同步给从节点。写命令的发送过程是异步完成，也就是说主节点自身处理完写命令后直接返回给客户端，并不等待从节点复制完成，所以是异步的。

• 同步：
  所谓同步，就是在发出一个功能调用时，在没有得到结果之前，该调用就不返回。也就是必须一件一件事做,等前一件做完了才能做下一件事。
  例如普通B/S模式（同步）：提交请求->等待服务器处理->处理完毕返回 这个期间客户端浏览器不能干任何事
• 异步：
  异步的概念和同步相对。当一个异步过程调用发出后，调用者不能立刻得到结果。实际处理这个调用的部件在完成后，通过状态、通知和回调来通知调用者.
  例如 ajax请求（异步）:
  请求通过事件触发->服务器处理（这是浏览器仍然可以作其他事情）->处理完毕

主节点复制流程：
1）主节点6379接收处理命令。
2）命令处理完之后返回响应结果。
3）对于修改命令异步发送给6380从节点，从节点在主线程中执行复制的命令。

由于主从复制过程是异步的，就会造成从节点的数据相对主节点存在延迟。具体延迟多少字节，我们可以在主节点执行info replication命令查看相关指标获得。