Redis 的优点和缺点

优点

• 读写性能优异
• 支持数据的持久化，支持 RDB 和 AOF 两种持久化方式
• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离
• 支持丰富的数据结构，支持 String,List,Set,Zset(有序集合),Hash 五种数据结构

缺点

• Redis 不具备自动容错和恢复功能。主机，从机的宕机都会导致读写请求失败，需要等待机器重启才能恢复
• 主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后还会引入数据不一致的问题，降低了系统的可用性

Redis 持久化机制

持久化数据：也就是将内存中的数据写入到硬盘里面，大部分原因是为了之后重用数据（比如重启机器、机器故障之后恢复数据），或者是为了防止系统故障而将数据备份到一个远程位置。Redis 的持久化方式： RDB 和 AOF

RDB 快照持久化

Redis 可以通过创建快照来获得存储在内存里面的数据。创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本( Redis 主从结构，主要用来提高 Redis 性能)，还可以将快照留在原地以便重启服务器的时候使用

RDB 快照持久化方式

快照持久化是 Redis 默认采用的持久化方式，在 redis.conf 配置文件中默认有此下配置

# 在 900 秒(15分钟)之后，如果至少有 1 个 key 发生变化，Redis 就会自动触发 BGSAVE 命令创建快照
save 900 1     
# 在 300 秒(5分钟)之后，如果至少有 10 个 key 发生变化，Redis 就会自动触发 BGSAVE 命令创建快照      
save 300 10 
# 在 60 秒(1分钟)之后，如果至少有 10000 个 key 发生变化，Redis 就会自动触发 BGSAVE命令创建快照         
save 60 10000        

RDB 快照持久化优点

• RDB 是一个非常紧凑的文件，它保存了某个时间点的数据集，非常适用于数据集的备份，比如你可以在每个小时保存一下过去 24 小时内的数据，同时每天保存过去 30 天的数据，这样即使出了问题你也可以根据需求恢复到不同版本的数据集
• RDB 是一个紧凑的单一文件，很方便传送到另一个远端数据中心或者亚马逊的 S3 (可能加密)，非常适用于灾难恢复
• 与 AOF 相比，在恢复大的数据集的时候，RDB 方式会更快一些

RDB 快照持久化缺点

• 耗时、耗性能
• 不可控、丢失数据

AOF 持久化

与快照 RDB 持久化相比，AOF 持久化的实时性更好，因此已成为主流的持久化方案

默认情况下 Redis 没有开启 AOF 方式的持久化，可以通过 appendonly 参数开启

# 开启 AOF 持久化
appendonly yes       

开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令，Redis 就会将该命令写入硬盘中的 AOF 文件。AOF 文件的保存位置和 RDB 文件的位置相同，都是通过 dir 参数设置的，默认的文件名是 appendonly.aof

AOF 的运行原理-创建

AOF 的运行原理-恢复

AOF 快照持久化方式

在 Redis 的配置文件中存在三种不同的 AOF 持久化方式，它们分别是

# 每次有数据修改发生时都会写入 AOF 文件，速度缓慢但是最安全
appendfsync always    
# 每秒钟同步一次，显示地将多个写命令同步到硬盘。AOF 默认使用的
appendfsync everysec  
# 让操作系统决定何时进行同步，速度最快
appendfsync no        

为了兼顾数据和写入性能，用户可以考虑 appendfsync everysec 选项（AOF 默认使用） ，让 Redis 每秒同步一次 AOF 文件，Redis 性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度

RDB 与 AOF 的对比选择

redis持久化机制

redis提供了两种持久化机制：

• 快照（snapshot）：保存某一时刻的数据状态
• AOF（appen only file）：将写命令记录到日志文件中

快照

• 默认的持久化机制
• 保存以.rdb结尾的文件，于是也被称为RDB方式

快照生成方式

• 客户端执行BGSAVE、SAVE指令

• 服务器配置自动触发

  900 1

  300 10

  60 10000

BGSAVE

当接收到客户端的BGSAVE指令后，redis会调用fork来创建一个子进程，然后子进程负责将快照写入磁盘中，而父进程则继续处理命令请求。

fork：当一个进程创建子进程的时候，底层操作系统会创建该进程的一个副本。在类UNIX系统中，创建子进程的操作会被优化：刚开始的时候，父子进程共享同一份内存，只有在父或子进程对内存进行了写操作后，共享才会结束

SAVE

整个进程都会进行创建快照的操作，在创建快照完成之前redis处于阻塞状态

AOF

• 开启AOF持久化，修改 appendonly yes
• 修改appendfilename "appendonly.aof"指定生成文件名称

日志追加频率

always 【谨慎使用】

• 每个redis写命令都同步到硬盘。
• 如果同一时间内大量涌入写命令，会引发严重的写入放大问题（向硬盘写入大量小文件导致硬盘寿命缩减等问题）

everysec 【推荐】

• 每秒执行一次同步。最多只会丢失1秒内的数据

no 【不推荐】

• 由操作系统决定何时同步。看命，如果一次性堆积大量写操作然后同步，也会导致redis处于阻塞状态

set a 100 执行一万次，即使最终的结果只有一条，但是aof文件中却会保存所有指令。所以日久天长，aof文件可能越来越大，所以就有了AOF重写

AOF重写

• 客户端方式触发重写

  执行BGREWRITEAOF命令 不会阻塞redis服务

• 服务器配置方式自动触发

  修改redis.conf中的两个选项：

  • auto-aof-rewrite-percentage 100

  • auto-aof-rewrite-min-size 64mb

  如果这么设置，当启用了AOF持久化时，当AOF文件体积＞64MB，且上一次重写之后体积增加了100%时，就自动重写一次

  如果重写过于频繁，则可以将auto-aof-rewrite-percentage设置大一些

AOF重写原理

AOF重写，并没有读取旧有的aof文件，而是将整个内存中的数据库用命令的方式写成一个新的aof文件，用来替换就有的aof文件。

重写流程：

1、redis调用fork，产生子进程，子进程生成快照，将快照中的数据信息以写入命令的方式存入临时文件

2、父进程继续处理来自客户端的请求，并将这些请求中所有写命令存入旧aof中的同时，再存入一份到缓存中

3、子进程将快照中的内容以命令形式全部写入临时文件后，通知父进程，然后父进程将刚才缓存的新命令追加到临时文件

4、父进程将临时文件替换旧有的aof文件。后面收到的命令也开始向新的aof文件中追加

redis持久化机制的原理

一、两种实现redis持久化的机制，RDB模式和AOF模式

①RDB模式

1.有三种具体的实现方式，save，bgsave,修改redis.conf配置
2.save方式会占用redis的进程，在save期间redis不可以处理其他的命令会造成redis拥堵，会替换掉老的dump.rdb文件
3.bgsave会fork出redis的一个子进程，在后台异步进行快照操作，并不会造成redis的拥堵，会替换掉老的dump.rdb文件
4.自动同步，即修改redis.conf中的配置数据
 eg:save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。

#####②AOF模式

1.将redis的写命令记录在AOF的文件中
2.AOF有三种机制
  2.1 always：当redis数据发生变化时即同步
  2.2 everysec : 每秒钟同步，无论数据有无更改
  2.3 no:从不同步

RDB和AOF的优缺点

1.RDB优点：适合大数据集的回复，fork子进程不会造成进程拥堵
2.RDB缺点：RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据
3.AOF优点：AOF每隔一秒同步一次数据，最多只会丢失1s钟的数据
4.AOF缺点：aof文件要比rdb文件要大

###RDB和AOF如何选择

一起来学习Golang吧