自建wordpress主题廊坊seo排名公司

1，持久化

        Redis的持久化是必须的，当Redis服务宕机后，如果没有持久化，重启服务后redis中的数据都将丢失，所有的数据操作都将直连数据库，系统性能会大幅降低，所以在使用Redis做缓存服务时必须持久化Redis数据。Redis持久化有三种方式：RDB(默认，不推荐)、AOF(可用但不推荐)、混合持久化方式(推荐)。

        1.1，RDB（snapshot-快照模式）

        RDB的快照模式是指：达到redis服务设定的某个条件（如60s内有1000次数据增/删/该操作）或redis服务器内存使用率达到指定阈值时，将当前内存中所有redis数据写入名为dump.rdb的文件中，做为当前时刻数据快照。

        1.1.1，开启方式

        redis的RDB持久化方式不需要显试开启，默认就使用该持久化方式，如果想关闭RDB持久化方式，只需注释所有的save触发条件（见1.1.2的触发条件）即可。

        1.1.2，触发条件和文件存储位置

        触发条件的配置如下，达到任意一个即触发生成dump.rdb。可添加自定义条件。

save 900 1              // 900秒内至少有 1 次数据变化

save 300 10            // 300秒内至少有 10 次数据变化

save 60 10000        // 60秒内至少 10000 次数据变化

dbfilename dump.rdb      // 持久化文件名，可手动修改

dir /var/lib/redis               // 持久化数据文件存放位置，可修改

         1.1.3，生成快照方式及原理

        同步：等同于调用【save】命令。使用redis数据操作（存取）线程将当前时刻内存数据写入dump.rdb文件中，会阻塞数据操作；

        异步：等同于调用【bgsave】命令。创建一个子进程，将当前时刻内存数据写入dump.rdb文件，不影响父进程执行数据存取。如果已经有一个后台保存正在运行，或者有另一个非后台保存进程正在运行，特别是正在进行的 AOF 重写，则会返回错误。

        注意：在子进程生成快照的同时，父进程有增删改的操作数据，将会采用写时复制机制（Copy-On-Write, COW）保证这段时间的数据同步至RDB文件。原理是bgsave期间父进程的数据修改，将会被复制一份数据副本，bgsvae在写完rdb后再同步数据副本。

        1.1.4，RDB模式问题

        RDB的生成必须满足触发阈值，生产中不可能设置过于频繁的触发阈值，因为每次生成的RDB都是触发时刻内存中的所有数据。所以当未达到触发阈值时，如果redis服务宕机，则这段时间内的所有操作数据都将丢失。

1.2，AOF（append-only file）

        AOF是优于RDB的持久化方式，将redis数据变化的每一条指令记录到文件appendonly.aof中。实际并非直接写入aof文件，先写入服务器缓存，每隔一段时间调用fsync()将数据同步到磁盘文件。

        1.2.1，开启方式

        redis.conf中有AOF的开启参数，默认为no，开启直接改为yes即可。如果AOF和RDB同时打开，则两种文件（RDB、AOF）都会存在。

appendonly yes             

appendfilename "appendonly.aof"        // 生成的文件名，可手动修改名称

        1.2.2，触发条件 

        同RDB方式一样，AOF也有自己的触发条件

appendfsync no                   // 不主动发起同步，由操作系统决定何时同步。快，但不安全

appendfsync always            // 每个修改数据的命令都同步至AOF文件中。慢，但安全

appendfsync everysec        // 默认。每秒发起一次同步。若同步前redis宕机则丢失1秒数据

        1.2.3，AOF文件解析 

        RDB文件是数据二进制文件，打开时内容如同乱码，如图：

        AOF是将修改数据指令存入文件，如图：

 

        1.2.4，AOF优化策略：AOF重写

        通过上面的文件解析可知，AOF恢复数据的方式是依次执行AOF文件中的命令。但实际情况下，AOF中有很多冗余的命令，如下方场景：

        为某篇文章累加阅读量。假如阅读量累加到5时，redis宕机，此时恢复数据不需依次累加，实则只需执行 set readcount-article1 5即可。基于类似数据场景，AOF提供了内置的优化机制：

AOF重写：达到重写的触发条件后，redis将根据当前内存数据，重新生成AOF文件。

触发条件配置：

auto-aof-rewrite-percentage 100          // aof文件自上次重写后，文件大小增长100%则触发再次重写

auto-aof-rewrite-min-size 64mb           // aof文件达到64M时重写

        使用命令【BGREWRITEAOF】手动触发一次重写，查看上述累加重写前后文件内容：

         注意：重写时，AOF模式采用类似RDB的【bgsave】方式，新建一个子进程重写AOF文件，故重写是不会影响主进程的redis数据操作。

        1.2.4，AOF模式问题

        如果redis运行时间很长，AOF文件将会巨大无比，即便使用了AOF重写，恢复数据时仍旧可能会非常缓慢。

        1.3，混合持久化方式

        RDB持久化方式，数据文件小（二进制数据），恢复数据快，缺点是容易丢失数据。AOF持久化方式，虽然安全但数据文件较大，恢复数据慢。混合持久化整合了两种方式的优点，混合持久化的AOF数据文件由两部分组成：[RDB file] 和 [AOF tail]。

        具体原理：当数据量未达到AOF重写阈值时，数据已redis命令方式写入AOF文件，当触发AOF重写时，当前时刻的数据将以RDB数据格式写入新的aof文件（RDB file），重写过程中的redis数据操作仍旧已命令方式追加写入该文件（AOF tail）。当重写完成后，新AOF文件替换旧的AOF文件。混合持久化文件内容如下：

         1.3.1，开启方式

        redis.conf中有混合持久化的开启参数，默认为no，开启混合持久化方式，需先开启AOF方式，再将下述参数改为yes即可。

aof-use-rdb-preamble yes        

        开启后，重写AOF，重写前的AOF参考1.2.3，重写后AOF如下，

        1.3.2，触发条件

        使用AOF方式的触发机制。tip：当使用混合持久化方式时，可关闭RDB持久化方式。

2，数据恢复

        恢复redis数据非常容易，只需将对应的数据文件放入redis.conf中配置的数据文件目录里即可。如上述案例中，数据文件的存储位置为：

        只需将待恢复数据的文件：dump.rdb或appendonly.aof文件放入该目录，重启reids时会自动恢复文件中数据。

         注意：虽然本章实现了数据的持久化，但当Redis宕机，如果数据操作量巨大，相当于出现【缓存穿透】现象，将极大降低系统性能。故生产中使用Redis一般都会使用主从架构，将在下章讲解。