Redis 补充 2

Redis. conf

reids 的配置文件在 etc/redis 目录下

单位：

单位大小写不敏感

配置文件：

可以包含多个配置文件（这些文件导入到主配置文件 Redis. conf 中）

网络：

bind 0.0.0.0 # IP（默认127.0.0.1）
protected-mode no # 保护模式（默认yes）
port 6379 # 端口设置（默认6379）

通用：

daemonize yes # 以守护进程方式运行，即后台运行（默认no）
 
pidfile /var/run/redis_6379.pid # 如果以后台运行，必须指定一个pid文件
 
# 日志
# Specify the server verbosity level.
# This can be one of:
# debug (大量信息, 使用于测试或开发阶段)
# verbose (许多很少有用的信息，但不像调试级别那样混乱)
# notice (比较冗长，你可能想在生产环境中使用)
# warning (只有非常重要/关键的消息被记录下来)
loglevel notice # 默认notice
logfile "" # 日志的文件位置名
 
databases 16 # 数据库的数量（默认16）
always-show-logo yes # 是否开启 logo （默认yes）

持久化：持久化，在规定时间内，执行了多少次操作，会被持久化到文件(.rdb，.aof)

save 900 1 # 900秒内（15分钟），如果至少有1个Key进行修改，我们就进行持久化操作
save 300 10 # 300秒内（5分钟），如果至少有10个Key进行修改，我们就进行持久化操作
save 60 10000 # 60秒内（1分钟），如果至少有10000个Key进行修改，我们就进行持久化操作
 
stop-writes-on-bgsave-error yes # 持久化如果出错，是否还需要继续工作（默认yes）
 
rdbcompression yes # 是否压缩rdb文件（默认yes），会消耗一些CPU资源
 
rdbchecksum yes # 保存rdb文件时，进行错误检查检验
 
dir ./ # rdb文件保存的目录

安全：

# requirepass 123456 # 设置密码（默认被注释着需要自己解开注释）

命令行配置密码（临时，服务重启失效）：

config get requirepass # 查看当前密码

config set requirepass 123456 # 设置当前密码为123

(error) NOAUTH Authentication required # 需要验证密码的报错信息提示
auth 123456 # 验证密码

客户端限制：

# maxclients 10000 # 限制最多10000哥客户端访问（默认注释）

内存管理：

 
# maxmemory <bytes> # 最大内存设置（默认注释）
 
# maxmemory-policy noeviction # 内存达到上限之后的处理策略（默认noeviction）
# 1、volatile-lru：只对设置了过期时间的key进行LRU（默认值）
# 2、allkeys-lru ： 删除lru算法的key
# 3、volatile-random：随机删除即将过期key
# 4、allkeys-random：随机删除
# 5、volatile-ttl ： 删除即将过期的
# 6、noeviction ： 永不过期，返回错误

APPEND ONLY MODE (AOF 配置)：

appendonly no # 默认是不开启aof的，默认使用rdb方式持久化
appendfilename "appendonly.aof" # 持久化的文件名
 
# appendfsync always # 每次修改都会同步，销耗性能
appendfsync everysec # 每秒执行一次同步，可能会丢失这1秒的数据
# appendfsync no # 不同步，操作系统自己同步数据，速度最快

Redis 持久化

详情： redis持久化详解_简述redis持久化_醺泽的博客-CSDN博客

什么是Redis持久化

redis 是基于内存的数据库。

优点是 cpu 读取内存速度快，一秒钟可以进行数十万次，可以直接和 cpu 速度相近，读取极快。缺点是基于内存，存在断电数据丢失的情况。

为了防止其数据断电丢失，就需要将数据存入硬盘中，这样在断电后也可以访问到数据库当中的数据。

这个将内存的数据写入到磁盘中，防止服务器宕机内存数据丢失，就是 redis 的持久化。

redis提供两种持久化机制：RDB和AOF（redis的默认持久化方式是RDB）

RDB (Redis DataBase，快照)

RDB 持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是 fork 一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。保存文件格式 dump.rdb

生成快照的方式--->

客户端方式：

BGSAVE：客户端可以使用 BGSAVE 命令来创建一个快照，当接收到客户端的 BGSAVE 命令时，redis 会创建一个子进程，子进程负责将快照写入磁盘中，而父进程继续处理命令请求。（在子进程创建之初，父子进程共享相同内存，知道父进程或子进程对内存进行了写之后，对于被写入的内存的共享就会结束服务）
SAVE：客户端使用 SAVE 命令创建一个快照，接收到 SAVE 命令的 redis 服务器在快照创建完毕之前将不再响应任何其他的命令。

服务端方式：

服务器配置自动触发：服务器通过配置方式来满足自动触发快照进行持久化，管理员需要在 redis. conf 中设置 save 配置选项，redis 会在 save 选项条件满足之后自动触发一次 BGSAVE 命令，如果管理员设置了多个 save 配置选项，当任意 save 条件被满足，redis 都会触发一次 BGSAVE 命令。
shutdown 指令：当 redis 通过 shutdown 指令接受到关闭服务器的请求时，会触发一次 SAVE 命令，阻塞所有的客户端，不再执行客户端发送的任何命令，在 SAVE 命令执行完毕后关闭服务器。

AOF (Append Only File，追加日志文件)

将 redis 执行的所有写命令记录到日志文件中，将被执行的写命令写到 AOF 的文件末尾，当 redis 重启时，redis 会从头到尾执行一次 AOF 文件所包含的所有写命令，以此回复 AOF 文件的记录的数据集。

redis 默认配置中 AOF 持久化机制是不开启的，需要在配置中开启：

修改 appendonly yes 开启持久化
修改 appendfilename “appendonly.aof” 指定生成文件名称
修改 appendfsync everysec | always | no 修改同步频率

追加频率选项：

always：每个redis写命令都要同步写入硬盘，严重降低redis速度
everysec【推荐】：每秒执行一次的同步显示，将多个写命令同步到磁盘，通过每秒同步一次AOF文件，redis可以保证，即使系统崩溃，最多丢失一秒之内产生的数据。
no：由操作系统保证数据同步到磁盘(linux 默认30秒)，速度最快

AOF 重写：

AOF 文件是以追加的方式记录接收到的写命令的，不断的追加会导致 AOF 文件过大。AOF 文件过大时会触发自动重写, 重写后的新 AOF 文件包含了恢复当前数据集所需的最少的命令集合。
AOF 重写一定程度上减小 AOF 文件的体积，解决文件过大的问题。

重建：

客户端多次对同一个键 incr 时, 操作N次则会写入N条, 但实际上只需一条 set 命令就可以保存该值, 重建就是生成足够重建当前数据集的最少命令。

重写触发--->

Redis 运行时打开 AOF：

redis-cli> CONFIG SET appendonly yes

（仅当前实例生命周期内有效）

客户端方式触发重写：

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

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

配置 redis. conf 中的 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 选项
auto-aof-rewrite-min-size 64mb 表示 AOF 写入文件大小大于 64m 才能触发重写操作。
auto-aof-rewrite-percentage 100 中的 100 表示百分比，表示 AOF 文件的体积比上一次重写之后体积至少大了 “100%” 时会自动触发。

重写原理--->

重写 AOF 的时候，创建一个重写子进程，然后读取旧的 AOF 文件，压缩并写入到一个临时 AOF。
在此期间，主进程一边将接收到的指令累计到一个缓冲区中，一边将指令写入到旧的 AOF。

（这样的好处，保证 AOF 文件的可用性，避免写过程时出意外）

子进程写完后，向主进程发送一个信号量，主进程就将缓冲区中的指令追加到新 AOF。
用新的 AOF 替换旧的 AOF，之后的新指令就追加到新的 AOF。

相关配置参数：

############################# APPEND ONLY MODE ###############################
#默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。但是redis如果中途宕机，会导致可能有几分钟的数据丢失，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性。Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。
appendonly yes

#aof文件名, 保存目录由 dir 参数决定
appendfilename "appendonly.aof"

#aof持久化策略的配置
#no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
#always表示每次写入都执行fsync，以保证数据同步到磁盘。
#everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。
appendfsync everysec

# 在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。
no-appendfsync-on-rewrite no

#aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
#设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写
auto-aof-rewrite-min-size 64mb

#aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项（redis宕机或者异常终止不会造成尾部不完整现象。）出现这种现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。
aof-load-truncated yes

优点：

数据安全，AOF 持久化可以通过配置 appendfsync 属性，设置其记录频率。
通过 append 模式写文件，即使服务器宕机，也可以通过 redis-check-aof 工具解决数据一致问题。
更加灵活。AOF 机制的 rewrite 模式，AOF 文件没被 rewrite 之前（文件过大时回对命令进行合并重写），可以删除其中的某些命令。

缺点：

AOF 文件比 RDB 文件更大，且回复速度更慢。
数据集大时，AOF 比 RDB 启动效率低。

当 RDB 和 AOF 同时开启时，redis 数据恢复会优先选中 AOF 恢复。

Redis 补充2 | 青训营