always,每修改一次执行保存，

everysec,每秒执行保存，

no,不执行保存

aof持久化

每秒同步。异步

每修改同步，最安全

日志文件append追加，不破坏之前的日志文件

文件过大，重写机制

格式清晰的日志文件，修改操作

aof比rdb文件大。

变成yes

重启：

删除删除数据库命令，还原根据文件

AOF持久化（每修改持久化）：

优势：

带来更高的数据安全性

日志为append形式

日志过大，redis自动启动重写机制

格式清晰，日志文件容易理解，有助于完成数据重建

劣势：

文件大

运行效率低

配置：

redis.conf 

appendonly yes

appendSync always（每修改一次就写入到硬盘中）

重启redis

flushall 清空数据库

AOF持久化：

优势：

1、这种机制可以带来更高的数据安全性，redis提供了三种同步策略：

①每秒同步： 是异步完成的，效率非常高，缺点是如果系统一旦宕机，系统这1秒钟修改的数据就会丢失

②每修改同步 ：可视为同步持久化，每一次数据发生变化都会被记录到磁盘中，这种效率是最低的，但是它是最安全的

③不同步

2、日志文件写入操作采取的是append模式，在写入过程中即使出现宕机的情况，也不会破坏我们日志文件中已经存在的内容；输入数据写入一半出现系统宕机，在redis下次启动之前，可以通过redis-check-aof工具帮助解决数据一致性的问题

3、如果日志过大，redis可以自动启动重写日志机制，redis以apped方式不断的将修改数据写入老的磁盘中，同时创建一个新的文件记录此期间产生的修改命令被执行了。

4、包含一个格式清晰、易于理解的日志文件，用于记录所有的修改操作，通过此文件可以完成数据的重建。

劣势：

1、在相同数量的数据集下，AOF比RDB文件大一些。

2、根据同步策略不同，AOF比RDB效率低。

AOF

    优势：

        这种机制可以带来更多的数据安全性。

        同步操作，每发生一次数据库操作，都会将该操作写入到磁盘中的日志文件中。

        即使出现宕机，也可以通过日志文件进行恢复（数据重建）。

        重启可以恢复到用户出现错误操作之前的状态

        redis-check-aof 解决数据一致性问题

        如果数据过大，Redis将会启动重写机制。

    缺点：

        运行效率低于RDB

        日志文件相对于.rdb文件大小较大。

333333333

看最后的命令：启动redis

看最后的命令：关闭REDIS

AOF优势：

• 更高的数据安全性（redis提供三种同步策略：每秒同步、每修改同步、不同步）

• 记录所做的修改

• 包含一个格式清晰、易于理解的日志（可基于此完成数据重建）
  

AOF劣势：

• 文件要比RDB的大些

• 运行效率也相对低

AOF配置：

默认RDB形式：

保存修改、重新启动

清空数据库  flushall

appendonly是aof持久化方式的一些设置

AOF效率较低，但数据安全性较好

Redis 同步策略 ：

    AOF:每次修改持久化 或选择每秒持久化

    RDB :每间隔一段时间向硬盘写，缺点是宕机可能出现数据丢失

------------------------------

--AOF方式

------------------------------

数据安全性

日志写入操作,如果执行一半,可以使用自带的工具解决半途宕机

如果日志过大,自动启用可以新建日志文件

日志文件记录所有日志操作,可以完成数据重建

劣势

文件要大,同步策略不同,效率高低不同低于RDB

redis.windows.conf配置

appendonly no -是否开启 yes

appendfilename "appendonly.aof" --文件名

# appendfsync always --修改一次就同步

appendfsync everysec --每秒同步

# appendfsync no --不同步

redis-server redis.windows.conf

优势：

1、更高的数据安全性

同步策略：每秒同步，每修改同步、不同步

每秒同步：异步完成，效率高，系统出现宕机，那么这一秒中修改的数据就会丢失

每修改同步：可以看作同步持久化，么一次发生数据的变化，都会立即写到磁盘当中，效率低，但是最安全

2、对日志文件的写入操作，采用的是追加模式（append），因此在写入过程中，即使出现了宕机的情况，也不会破坏日志文件中已经存在的内容。如果本次写入进行到一半就出现宕机，那么这种方式也不必担心，redis在下一次启动之前，可以通过redis-check-aof这个工具，帮助我们解决数据一致性的问题

3、如果日志过大，redis可以自动启动重写机制，redis以append模式不断的将修改的数据写入到老的磁盘文件当中，同时redis会创建一个新的文件，用于记录此期间产生的哪些修改命令被执行。因此，在进行重写切换的时候，可以更好的去保证数据的安全性

4、AOF包含一个格式清晰易于理解的日志文件用于记录所有的修改操作，也可以通过这个文件完成数据的重建

劣势

1、对于相同数量的数据集而言，AOF的文件要比RDB的文件大一些

2、根据同步策略的不同，AOF在效率上往往低于RDB

AOF持久化

redis提供了三种同步策略：

1、每秒同步：当服务器宕机，那一秒内修改的数据将丢失

2、每修改同步：效率最低，但最安全

3、不同步

劣势：

同等数据量下AOF的文件要大于RDB

根据同步策略的不同 AOF在运行效率上往往低于RDB

vim redis.conf

appendonly no

默认AOF不打开，默认使用RDB

AOF 

数据保存方式

1. 每秒同步 //数据可能丢失

2. 数据修改时同步 //最安全

3. 不同步

1 更高安全性

2. 不会破坏已有内容

3. 日志过大时自动启动重写机制，除了会在日志文件追加记录，还会额外记录在此期间执行的操作日志

4. 日志文件格式清晰，易理解

劣势

1. 相同数据集的两种方式，aof文件比rdb要大

2. 运行效率低于rdb 

配置

redis.conf

appendonly no //默认不打开aof方式

appendfilename "appendonly.aof"

#appendfsync always

appendfsync everysec

#appendfsync no

flushall //清空数据库

redis会自动从aof文件恢复所有执行过的操作(可以去掉aof中的flushall还原所有数据)

redis同步方式：

1、每秒同步：当服务器宕机，那一秒内修改的数据没有记录

2、每修改同步：效率最低，但是最安全

3、不同步

修改配置文件后，重启redis

flushall ：清空数据库

appendonly no

默认情况下AOF这种方式没打开

AOF

优势：

1、更高的数据安全性

同步策略：每秒同步，每修改同步、不同步

每秒同步：异步完成，效率高，系统出现宕机，那么这一秒中修改的数据就会丢失

每修改同步：可以看作同步持久化，么一次发生数据的变化，都会立即写到磁盘当中，效率低，但是最安全

2、对日志文件的写入操作，采用的是追加模式（append），因此在写入过程中，即使出现了宕机的情况，也不会破坏日志文件中已经存在的内容。如果本次写入进行到一半就出现宕机，那么这种方式也不必担心，redis在下一次启动之前，可以通过redis-check-aof这个工具，帮助我们解决数据一致性的问题

3、如果日志过大，redis可以自动启动重写机制，redis以append模式不断的将修改的数据写入到老的磁盘文件当中，同时redis会创建一个新的文件，用于记录此期间产生的哪些修改命令被执行。因此，在进行重写切换的时候，可以更好的去保证数据的安全性

4、AOF包含一个格式清晰易于理解的日志文件用于记录所有的修改操作，也可以通过这个文件完成数据的重建

劣势

1、对于相同数量的数据集而言，AOF的文件要比RDB的文件大一些

2、根据同步策略的不同，AOF在效率上往往低于RDB

aof方式：
优势：1.带来更高的数据安全性。有三种同步策略。每秒同步、每修改同步、不同步。
2.AOF 文件是一个只进行追加操作的日志文件，因此在写入过程中即使出现宕机现象也不影响之前已经存在的内容。
3.如果日志过大，redis可以启动重写机制。在重写过程中产生的对数据库操作记录会保存在一个新文件中，等到重写完成后再追加到现有的文件中。
4.AOF 文件有序地保存了对数据库执行的所有写入操作

劣势：1.对于相同数量的数据集而言，文件比rdb方式要大。
2.效率比rdb低

AOF 优势： 1.同步： a.每秒同步：异步完成，效率高，一旦系统宕机，修改的数据丢失 b.每修改同步：同步持久化，每分钟发生的变化记录到磁盘中，效率低，安全 c.不同步 2.日志写入操作追加模式append a.系统宕机，不影响存在的内容 b.写入一半数据，若系统崩溃，下次启动redis，redis-check-aof工具解决数据一致性 3.如果日志过大，自动重写机制，修改的数据写入到到磁盘文件，创建新文件，记录产生的修改命令，重写切换时，保证数据安全 4.格式清晰的日志文件，完成数据的重建 劣势： 1.对于相同数据文件，相比RDB，AOF文件较大 2.效率低 配置： vim  redis.conf 默认： appendonly no #AOF方式默认关闭   appendfilename appendonly.aof #配置文件 #appendfsync always #每修改一次，同步到磁盘上 appendsync everysec 每秒同步到磁盘一次 #appensync no 不同步 实践打开AOF： appendonly yes appendfsync always 终端2：先断开redis ./bin/redis-cli shutdown 启动redis： ./bin/redis-server ./redis.conf 终端1：set name 100 终端2：产生appendonly.aof文件 终端1：flushall 清空数据库 终端2： ./bin/redis-cli shutdown vim appendonly.aof 删除flushall ./bin/redis-server ./redis.conf ./bin/redis-cli keys * 数据还原

Redis持久化 

重启redis

Redis持久化

修改 appendonly.aof

删除flushall

Redis持久化

启动后

插入一些数据后，通过flushall清空数据库

然后关闭redis，重新启动redis之前，修改某配置文件，将最后一行的flushAll删除，并保存

然后重启redis

输入keys *

可以看到，之前插入的数据，都加载进了内存中

这就是AOF持久化的方式

Redis持久化

重新启动Redis 注意添加 ./redis.condif

Redis持久化

同步策略的设置::appendfsync always

Redis持久化

AOF配置

redis.config 509行

appendonly yes

Redis持久化

AOF优势、劣势、配置