redis总结(手把手搭建redis集群)

redis集群

Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。
Redis 集群没有使用一致性hash, 而是引入了哈希槽的概念。

要让集群正常运作至少需要三个主节点，不过在刚开始试用集群功能时， 强烈建议使用六个节点： 其中三个为主节点， 而其余三个则是各个主节点的从节点。

首先， 让我们进入一个新目录， 并创建六个以端口号为名字的子目录， 稍后我们在将每个目录中运行一个 Redis 实例： 命令如下:
1、创建文件夹
mkdir redis-cluster-test

2、进入文件夹
cd redis-cluster-test

3、创建配置文件夹
mkdir 7000 7001 7002 7003 7004 7005

4、编写配置文件(最基础的配置)

文件名：redis-7000.conf

文件内容：

port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

文件中的 cluster-enabled 选项用于开实例的集群模式， 而 cluster-conf-file 选项则设定了保存节点配置文件的路径， 默认值为nodes.conf节点配置文件无须人为修改， 它由 Redis 集群在启动时创建， 并在有需要时自动进行更新。

复制五份，一一将其端口号和文件名改为7001 7002 7003 7004 7005，并分别放置在不同文件夹里。

5、将redis源码src目录下的redis-cli和redis-server拷贝到redis-cluster-test目录下

6、启动redis节点
进入到7000目录下，输入命令行：…/redis-server redis.conf(配置文件名)，其余节点依次开启。

此时集群还不可用

redis-cli -p 7000
set hello world

(error)CLUSTERDOWN The cluster is down
# 提示槽位没有分配

7、开启集群模式
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1

-replicas 表示进行身份授权
1 表示每个主节点，只有一个从节点
集群会自动分配主从关系
7000、7001、7002为主服务器master
7003、7004、7005为从服务器slave

从redis5.0开始，建议使用redis-cli作为创建集群的命令，不推荐再使用redis-trib.rb来创建集群了，毕竟使用redis-trib.rb还要安装Ruby程序，比redis-cli麻烦的多。

8、登录客户端
redis-cli -p 7000 -c

redis客户端任意访问一个redis实例，如果数据不在该实例中，通过重定向引导客户端访问所需要的redis实例

到这里基本就完成了。

9、查看集群状态
redis-cli -p 7000 cluster info

进入命令行，两条redis集群基本命令：
1.查看当前集群信息
cluster info

2.查看集群里有多少个节点
cluster nodes

Redis-集群搭建(cluster集群、集群创建、节点配置、节点添加、节点删除、槽位分配)

Redis-集群搭建

在连接Redis集群搭建之前首先具备的前置知识有Redis的安装，Redis持久化，Redis主从复制，若还没了解都可以通过阅读以下文章了解以下

Linux-安装Redis

Redis-主从复制(一主二从、主从复制原理、单哨兵模式、多哨兵模式)

Redis-持久化(RDB配置、RDB原理、AOF配置、AOF原理、混合持久化配置)

高可用集群

哨兵模式

其实对于一般的小型项目，利用哨兵模式+主从复制已经可以满足了，但是由于Redis是单线程应用所以在单主节点下理论上说Redis可以达到10W的并发，10W的并发对于大型互联网公司是远远不够用的

REDIS CLUSTER

所以在Redis 3.0后便多了一个REDIS CLUSTER配置，即Redis集群他可以突破3.0之前只能一主多从的限制，实现多主多从，这种集群没有中心节点，可水平扩展，据官方文档称可以线性扩展到上万个节点，当前配置性能和高可用都优与哨兵模式，且配置非常简单

集群模式搭建

这里我演示搭建的是一个3主3从的Redis集群

首先需要准备3台Liunx，并且在3台Liunx上都安装了Redis

配置文件

我们需要3主3从那边就需要6个Redis服务，首先我们用创建创建好不同端口Redis的文件夹，并且在每一个文件夹里面保存一个redis.conf配置文件

创建完毕后，逐个修改个个端口下的redis.conf文件，需修改内容如下，当前只拿8001端口举例其余端口以此类推，只是端口号不同

# 修改为后台启动
daemonize yes
# 修改端口号
port 8001
# 指定数据文件存储位置
dir /usr/local/redis-app/8001/
# 开启集群模式
cluster-enabled yes
# 集群节点信息文件配置
cluster-config-file nodes-8001.conf
# 集群节点超时间
cluster-node-timeout 15000
# 去掉bind绑定地址
# bind 127.0.0.1 -::1 (这里没写错就是家#注释掉bind配置)
# 关闭保护模式
protected-mode no
# 开启aof模式持久化
appendonly yes
# 设置连接Redis需要密码123（选配）
requirepass 123456
# 设置Redis节点与节点之间访问需要密码123（选配）
masterauth 123456

启动Redis

修改完毕后，逐个启动Reids服务，启动成功后我们可以从ps -ef中看到启动的Redis进程于普通的Redis进程不同之处在于后面的[cluster]表示当前进程是集群模式启动的

集群创建

在任意一台机器上执行如下命令，即可创建集群，执行如下命令后Redis会随机分配主从机器，并且在分配的时Redis是不会让主节点与从节点在同一台机器上的

# -a 密码认证，若没写密码无效带这个参数
# --cluster create 创建集群实例列表 IP:PORT IP:PORT IP:PORT
# --cluster-replicas 复制因子1（即每个主节点需1个从节点）
./bin/redis-cli -a 123456 --cluster create --cluster-replicas 1 192.168.100.101:8001 192.168.100.101:8002 192.168.100.102:8003 192.168.100.102:8004 192.168.100.103:8005 192.168.100.103:8006

执行命令后会让你确认配置，输入yes确认

集群验证

连接集群

# -a 密码认证
# -c 连接集群
# -h 集群中任意一个Redis节点IP
# -p 集群中任意一个Redis节点端口
./bin/redis-cli -a 123456 -c -h 192.168.100.101 -p 8001

查看集群信息

# 登录redis-cli后执行如下命令
CLUSTER INFO

查看节点信息

# 登录redis-cli后执行如下命令
CLUSTER NODES

集群操作

主节点添加

服务启动

我们对当前的3主3从进行扩容成4主4从，首先在准备多一台Liunx，并且在上面安装好Redis配置好2个Redis服务的配置文件，并且启动2个服务

添加节点

# 使用如下命令即可添加节点将一个新的节点添加到集群中
# -a 密码认证(没有密码不用带此参数)
# --cluster add-node 添加节点 新节点IP:新节点端口 任意存活节点IP:任意存活节点端口
./bin/redis-cli -a 123456 --cluster add-node 192.168.100.104:8007 192.168.100.101:8001

使用cluster nodes命令查看集群信息表，可以看到8007已经被添加到了新的集群中了，但是8007并且没有任何的槽位信息，这时就需要迁移槽位

槽位迁移

# 使用如下命令将其它主节点的分片迁移到当前节点中
# -a 密码认证(没有密码不用带此参数)
# --cluster reshard 槽位迁移 从节点IP:节点端口，中迁移槽位到当前节点中
./bin/redis-cli --cluster reshard 192.168.100.101:8002

输入完成后会打印一片执行计划给你看，输入yes就会把槽位与数据全部迁移到新节点了

迁移完毕后再查看集群信息可以看到8007已经添加了槽位了

从节点添加

添加节点

添加从节点首先需要先把节点添加到集群中

# 使用如下命令即可添加节点将一个新的节点添加到集群中
# -a 密码认证(没有密码不用带此参数)
# --cluster add-node 添加节点 新节点IP:新节点端口 任意存活节点IP:任意存活节点端口
./bin/redis-cli -a 123456 --cluster add-node 192.168.100.104:8008 192.168.100.101:8001

通过节点信息可以查看到8008节点已经添加进去了，但是任何的节点添加都是主节点，那么接下来我们需要把8008改成从节点

配置节点

我们需要使用客户端命令连接到刚刚新添加的8008节点的上，并且为他设置一个主节点，设置完毕后再次查看节点信息，可以看到8008已经是8007的从节点了

# 连接需设为从节点的Redis服务
./bin/redis-cli -a 123456 -p 8008
# 将当前节点分配为 8cf44439390dc9412813ad27c43858a6bb53365c 的从节点
CLUSTER REPLICATE 8cf44439390dc9412813ad27c43858a6bb53365c

删除主节点

主节点删除就那么首先需要对槽进行迁移，如当前需要移除8007节点，那么首先需要把8007的节点槽位移动到别的节点中，才能删除

移完后可以看到8002的槽位增加了，8007的槽位已经没有哦

# 执行如下命令删除节点
# -a 密码认证(没有密码不用带此参数)
# --cluster del-node 连接任意一个存活的节点IP:连接任意一个存活的节点端口 要删除节点ID 
./bin/redis-cli -a 123456 --cluster del-node 192.168.100.101:8002 8cf44439390dc9412813ad27c43858a6bb53365c

删除从节点

从节点删除比较简单，直接删除即可，现在要删除8008节点

# -a 密码认证(没有密码不用带此参数)
# --cluster del-node 连接任意一个存活的节点IP:连接任意一个存活的节点端口 要删除节点ID 
./bin/redis-cli -a 123456 --cluster del-node 192.168.100.104:8008 71cb4fe842e83252f0ffabdc2b31eddb98fd4c89

删除删除成功后可以看到8008节点已经在集群中消失了

重新分配槽位

重新分配槽位慎用！！！，该功能可以让着集群的槽位重新平均分配但是由于涉及到槽位大量迁移会导致整个Redis阻塞停止处理客户端的请求

# -a 密码认证(没有密码不用带此参数)
# --cluster rebalance 重新分配集群中的槽位
./bin/redis-cli -a 123456 --cluster rebalance 192.168.100.101:8002

分配完成后可以看到所有的主节点的槽位都被重新分配了

使用Jedis连接集群

集群搭建成功后，使用Jedis连接集群并且测试

依赖引入

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
</dependency>

代码编写

可以看到在使用set于get方法于普通的Redis使用并不差异

且测试

依赖引入

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
</dependency>

Redis-主从复制(一主二从、主从复制原理、单哨兵模式、多哨兵模式)

 

Redis主从复制

简介

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器，前者称为主节点（master），后者成为从节点（slave），数据的复制是单向的，只能由主节点到从节点，Master以写为主，Slave以读为主

主从复制作用

1. 数据冗余：主从复制实现了数据的热备份，是持久化以外的一种数据冗余方式
2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复
3. 负载均衡：在主从复制达到基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务，分担服务器负载，尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提示Redis服务的并发
4. 高可用基石：主从复制还是哨兵和集群的基础，因此说主从复制是Redis高可用的基础

一般来说，要将Redis运用于项目中，只使用一台Redis是会出现如下问题

1. 单Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载压力较大
2. 单Redis服务器内存容量有限，就算一台Redis服务器内存256G，也不能所有内存用作Redis内存一般来说，单Redis最大使用内存不超过20G
3. 因为80%情况下都是进行读操作，主从复制读写分离可以大大减轻服务器的压力，一般情况下都是一主二从

环境配置

只配置从库，不用配置主库（Redis每一个服务默认是主库）

使用info replication 查看当前Redis信息

拷贝多份conf文件

cp redis.conf redis6379.conf

使用cp拷贝多份conf文件 6401于6402是从机

编辑主机配置文件

#端口6379 主机配置文件
vim redis6379.conf
#修改log文件输出名称和rdb文件输出名称，不改会冲突
logfile "6379.log"
dbfilename dump6379.rdb

编辑从机配置文件

#端口6401 从机配置文件
vim redis6401.conf
#修改端口6401
port 6401
#pidfile修改成于端口对应
pidfile /var/run/redis_6401.pid
#修改log文件输出名称和rdb文件输出名称
logfile "6401.log"
dbfilename dump6401.rdb


#端口6402 从机配置文件
vim redis6402.conf
#修改端口6402
port 6402
#pidfile修改成于端口对应
pidfile /var/run/redis_6402.pid
#修改log文件输出名称和rdb文件输出名称
logfile "6402.log"
dbfilename dump6402.rdb

启动3个Redis服务

./bin/redis-server redis6379.conf 
./bin/redis-server redis6401.conf 
./bin/redis-server redis6402.conf 

配置成一主二从

我们可以看到默认情况下3台Redis都是主机

使用SLAVEOF 127.0.0.1 6379

配置2台从机器指定127.0.0.1:6379为主机

当然通过命令行的方式来配置主机，只是临时配置，如果要从Redis启动时就配置好需连接的主机，就需要修改配置文件，的主从配置中的replicaof即可

我们在主机中set一个值，然后这值会被复制到从机中

如果我们尝试在从机中写入会报错

主从复制原理

Slave启动成功连接到Master后会发送一个sync同步命令

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

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

增量复制：Master继续将新的所有收集的修改命令依次传给slave，完成同步

只要重新连接master，一次完成同步（全量复制）将被自动执行

宕机手动设置主机

入主机在生产环境中突然宕机，我们查看2太从机的配置，我们会发现2台从机没有任何变化，还是连接的主机，问题是现在主机宕机了从机又不能执行写入命令，那么如何解决呢

手动执行SLAVEOF no one命令就可以将来我们的一台从机，切换为master主机

存在问题：如果master连接上了，那从机也不会变回去了，又需要手动把从机器配置上

哨兵模式

哨兵作用

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器
• 当哨兵基础到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他从服务器，修改配置文件让它们切换主机

单哨兵

主从切换技术方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这需要人工干预，还会造成一段时间内服务不可用，Redis从2.8开始正式提供了Sentinel（哨兵模式）来解决这个问题

主从切换自动版，Redis提供一个哨兵的命令，哨兵是一个独立的进程，独立运行的，哨兵会通过发送命令，等待Redis服务器响应，从而接口运行中的多个Redis实例，如果主机宕机了，会根据投票票数最多的从机，将其自动切换为主机

多哨兵

单哨兵存在一个问题，如果最高哨兵死了呢，那么就没人进行监控了，所以在生产机中通常会存在多个哨兵同时监控Redis，并且多个哨兵也相互监控

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

部署多哨兵模式

#配置哨兵配置文件，文件名不要错，否则配置失败
vim sentinel.conf
#sentinel monitor [被监控的名称] [host] [port] [1]
sentinel monitor myredis 127.0.0.1 6379 1
#启动哨兵
./bin/redis-sentinel sentinel.conf

模拟宕机

将来主机宕机，观察哨兵的日志，以及2台从机的信息

那如果主机回来了会怎么样呢

主机回来只能归并到新的主机下，当从机

优缺点

优点：

1. 哨兵集群，基于主从复制模式，所有主从配置优点，它都有
2. 主从可以切换，故障可以转移，系统可用性就会更好
3. 哨兵模式是主从模式的升级，手动到自动，更加健壮

缺点：

1. Redis不好啊在线扩容，集群容量一旦达到上限，在线扩容十分麻烦
2. 实现哨兵模式的配置其实是很麻烦的，里面有很多选择

哨兵模式的配置文件

# Example sentinel.conf
 
# 哨兵sentinel实例运行的端口 默认26379
port 26379
 
# 哨兵sentinel的工作目录
dir /tmp
 
# 哨兵sentinel监控的redis主节点的 ip port 
# master-name  可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
  sentinel monitor mymaster 127.0.0.1 6379 2
 
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
 
 
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
 
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，
这个数字越小，完成failover所需的时间就越长，
但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
 
 
 
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面： 
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。  
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
 
# SCRIPTS EXECUTION
 
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
 
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，
这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，
一个是事件的类型，
一个是事件的描述。
如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
#通知脚本
# sentinel notification-script <master-name> <script-path>
  sentinel notification-script mymaster /var/redis/notify.sh
 
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。 
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
 sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

 

Redis-持久化(RDB配置、RDB原理、AOF配置、AOF原理、混合持久化配置)

Redis持久化

redis是内存数据库，如果不将内存的数据保存到硬盘，一旦服务器进程退出/崩溃，redis的中的数据就全部消失，所有redis提供了持久化功能

RDB（Redis DataBase）

在指定的时间间隔内将内存中的数据集快照写入磁盘中，类似于虚拟机VMware/VBox的快照，需要恢复时将快照文件直接读取到内存中

工作流程：redis会单独创建（fork）一个子进程进行持久化，会先将数据写入到一个临时文件中，待持久化结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作，这确保了极高的性能，如果需要进行大规模数据恢复，且对数据恢复完整性不是非常敏感，那rdb方式比aof方式更加的高效，rdb的缺点是最后一次持久化数据可能会丢失（redis默认是rdb，一般情况下不需要修改这个配置）

默认保存文件：dump.rdb

rdb配置

#设置60秒修改5个值就会保存rdb文件
save 60 5

rdb触发机制

1. save的规则满足的情况下，会自动触发rdb规则
2. 执行flushall命令，也会触发rdb规则
3. 退出redis，也会触发rdb规则

rdb触发后会在redis目录下生成一个 dump.rdb 文件

rdb文件恢复

使用CONFIG GET dir获取redis的目录位置

如果在该目录下存在dump.rdb文件就会读取并且自动恢复里面的数据

rdb优缺点

优点：

1. 适合大规模数据恢复
2. 对数据完整性要求不高推荐使用rdb

缺点：

1. 保存规则需要一定时间间隔，如果在未达到rdb规则时宕机，会丢失一部分数据
2. fork进程的适合，会占用一定的内存空间

AOF（Append Only File）

工作流程：以日志的形式记录每一个写操作，将Redis执行过程的所有指令记录下来（读操作不记录），并且把目录追加到文件的后面，redis启动时就会读取aof文件把里面的所有记录的指令全部执行一次，恢复数据

默认保存文件：appendonly.aof

aof配置

# 手动开启aof
appendonly yes
# 每秒都会保存一次
appendfsync everysec
# 写入aof文件，不等待磁盘同步，保证数据安全性
no-appendfsync-on-rewrite no
# 执行AOF重写时，当前AOF大小
auto-aof-rewrite-percentage 100
# 执行AOF重写时，文件的最小体积
auto-aof-rewrite-min-size 64mb

aof文件修复

tail appendonly.aof

我们可以看到aof文件其实保存的是操作指令

如果指令存在问题，redis启动时会无法启动

我们可以通过check-aof帮我们检测修复

aof优缺点

优点：

1. 每一次修改都同步，数据完整性更加好（appendfsync always）
2. 每秒同步一次，可能会丢失一秒的数据（appendfsync everysec）
3. 从不同步，效率最高（appendfsync no）

缺点：

1. 相对数据文件来说，aof远大于rdb
2. 如果大数据情况下，修复速度比rdb慢，因为aof需要执行里面所有命令

同步，效率最高（appendfsync no）

缺点：

1. 相对数据文件来说，aof远大于rdb
2. 如果大数据情况下，修复速度比rdb慢，因为aof需要执行里面所有命令

混合持久化（4.x）

重启Redis是，我们很少使用rdb恢复内存状态，因为会丢失大量数据，通常使用aof作为持久化，但是aof存在性能问题，如果Redis实例很大情况下，启动需要花费很长的事件，Redis4.0就解决了这个问题，并带来了一种新的持久化选项混合持久化

混合持久配置

#开启混合持久化
aof-use-rdb-preamble yes

混合持久化特点

混合持久化重要的特点就是AOF重写，由于AOF超级好的特性里面会保存着所以Redis执行过的指令，然后再Redis重启时把所有之前执行过的命令都保存下来，这样其实有好多重复命令是多余操作，AOF会定期根据内存的最新数据生成AOF文件时将重写，及重写一刻的AOF生成一个RDB快照，然后在生成RDB的时候也会有一些操作命令的，这些命令都会背拼接上在做快照时的新的命令都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，原子的覆盖原有的AOF文件，完成新旧两个AOF文件的替换