一、Redis.conf详解

容量单位

1、配置大小单位，开头定义了一些基本的度量单位，只支持bytes，不支持bit,不区分大小写，G和GB有区别
2、对 大小写 不敏感

可以使用 include 组合多个配置问题

网络配置

bind 127.0.0.1      # 绑定的ip
protected-mode yes  # 保护模式,远程时需要关闭
port 6379           # 默认端口

 指定多个ip 访问 ip 用空格 隔开

通用 GENERAL

daemonize yes  # 默认情况下，Redis不作为守护进程运行。需要开启的话，改为 yes
supervised no  # 可通过upstart和systemd管理Redis守护进程
pidfile /var/run/redis_6379.pid  #  以后台进程方式运行redis，则需要指定pid 文件
loglevel notice # 日志级别。可选项有：# debug（记录大量日志信息，适用于开发、测试阶段）；  # verbose（较多日志信息）；  # notice（适量日志信息，使用于生产环境）；# warning（仅有部分重要、关键信息才会被记录）。logfile ""      # 日志文件的位置，当指定为空字符串时，为标准输出
databases 16    # 设置数据库的数目。默认的数据库是DB 0
always-show-logo yes  # 是否总是显示logo

数据库的数量

# Set the number of databases. The default database is DB 0， you can select
# a different one on a per-connection basis using SELECT <dbid> where
# dbid is a number between 0 and 'databases'-1
databases 16#设置数据库个数。默认数据库为“DB 0”，可选择
#在每个连接上使用SELECT where
# dbid是一个介于0和'databases'-1之间的数字
databases 默认的数据库数量 16 个

 快照 SNAPSHOTTING

持久化数据 因为 Redis是内存数据库 如果断电等因素 会失去数据 所以我们需要在一定时间里 持久化数据

# 900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化）
save 900 1
# 300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化）
save 300 10
# 60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化）
save 60 10000
stop-writes-on-bgsave-error yes  # 持久化出现错误后，是否依然进行继续进行工作
rdbcompression yes   # 使用压缩rdb文件 yes：压缩，但是需要一些cpu的消耗。no：不压
缩，需要更多的磁盘空间
rdbchecksum yes      # 是否校验rdb文件，更有利于文件的容错性，但是在保存rdb文件的时
候，会有大概10%的性能损耗
dbfilename dump.rdb  # dbfilenamerdb文件名称
dir ./    # dir 数据目录，数据库的写入会在这个目录。rdb、aof文件也会写在这个目录

 安全 SECURITY

requirepass xxxxx 设置redis 登录密码

# Require clients to issue AUTH <PASSWORD> before processing any other
# commands. This might be useful in environments in which you do not trust
# others with access to the host running redis-server.
#
# This should stay commented out for backward compatibility and because most
# people do not need auth (e.g. they run their own servers).
#
# Warning： since Redis is pretty fast an outside user can try up to
# 150k passwords per second against a good box. This means that you should
# use a very strong password otherwise it will be very easy to break.
#
# requirepass foobared

  访问密码的查看，设置和取消

# 启动redis
# 连接客户端
# 获得和设置密码
config get requirepass
config set requirepass "123456"
#测试ping，发现需要验证
127.0.0.1:6379> ping
NOAUTH Authentication required.
# 验证
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> ping
PONG

限制 CLIENTS

maxclients 10000   # 设置能连上redis的最大客户端连接数量
maxmemory <bytes>   # redis配置的最大内存容量
maxmemory-policy noeviction   # maxmemory-policy 内存达到上限的处理策略#volatile-lru：利用LRU算法移除设置过过期时间的key。#volatile-random：随机移除设置过过期时间的key。#volatile-ttl：移除即将过期的key，根据最近过期时间来删除（辅以TTL）#allkeys-lru：利用LRU算法移除任何key。#allkeys-random：随机移除任何key。#noeviction：不移除任何key，只是返回一个写错误。

aof配置 APPEND ONLY MODE

 appendonly no   # 是否以append only模式作为持久化方式，默认使用的是rdb方式持久化，这种
方式在许多应用中已经足够用了
appendfilename "appendonly.aof"   # appendfilename AOF 文件名称
appendfsync everysec  # appendfsync aof持久化策略的配置# no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。# always表示每次写入都执行fsync，以保证数据同步到磁盘。# everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。

• # appendfsync always // 每修改一个key都会执行 sync，消耗性能
• appendfsync everysec // 每一秒执行一次 sync，可能会丢失这1s的数据
• # appendfsync no // 不执行 sync，这个时候操作系统会自己同步数据速度是最快的

二、Redis持久化

 Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以 Redis 提供了持久化功能！

redis持久化的几种方案

• RDB (Redis Database)
• AOF (Append Only File)
• No persistence:
• RDB + AOF

2.1RDB (Redis DataBase)

在指定时间间隔后，将内存中的数据集快照写入数据库 ；在恢复时候，直接读取快照文件，进行数据的恢复 ； 默认情况下， Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中。文件名可以在配置文件中进行自定义。

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。 

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性

不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

触发机制#

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

save#

使用 save 命令，会立刻对当前内存中的数据进行持久化 ,但是会阻塞，也就是不接受其他操作了；

由于 save 命令是同步命令，会占用Redis的主进程。若Redis数据非常多时，save命令执行速度会非常慢，阻塞所有客户端的请求。

flushall命令#

flushall 命令也会触发持久化 ；

触发持久化规则 满足配置条件中的触发条件 ；

可以通过配置文件对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动进行数据集保存操作。

bgsave#

bgsave 是异步进行，进行持久化的时候，redis 还可以将继续响应客户端请求 ；

 

LASTSAVE：获取最近一次RDB的时间戳

 总结如何触发RDB快照

• 配置文件中默认的快照配置，建议多用一台机子作为备份，复制一份 dump.rdb

• 命令save或者是bgsave

  • save 时只管保存，其他不管，全部阻塞
  • bgsave，Redis 会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。
• 执行flushall命令，也会产生 dump.rdb 文件，但里面是空的，无意义 !
• 退出的时候也会产生 dump.rdb 文件！
• 主从复制时，主节点自动触发

如何恢复

1、将备份文件（dump.rdb）移动到redis安装目录并启动服务即可
2、CONFIG GET dir 获取目录 

127.0.0.1:6379> CONFIG GET requirepass
1) "requirepass"
2) "123456"
127.0.0.1:6379> CONFIG GET save
1) "save"
2) "5 2"
127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/root/redis-dump"
127.0.0.1:6379> CONFIG GET dbfilename
1) "dbfilename"
2) "6379.rdb"
127.0.0.1:6379>

 RDB 优缺点

优点

1. 适合大规模的数据恢复
2. 对数据的完整性要求不高
3. RDB文件在内存中的加载速度比AOF快得多

缺点

RDB 修复命令

redis-check-rdb /root/redis-dump/dump6379.rdb

RDB禁用

• config set save “”，命令级别
• save “” ，配置文件（快照禁用）

RDB优化参数

1. stop-writes-on-bgsave-error：

   • 默认值：yes
   • 描述：当在执行BGSAVE（后台保存）操作时发生错误时，是否停止写入操作。如果设置为"yes"，则当BGSAVE操作失败时，Redis将拒绝写入操作；如果设置为"no"，则即使BGSAVE操作失败，Redis仍然可以接受写入操作。

2. rdbcompression：

   • 默认值：yes
   • 描述：是否对RDB文件进行压缩。启用压缩可以减小RDB文件的大小，但在保存和加载RDB文件时会增加CPU的使用量。

3. rdbchecksum：

   • 默认值：yes
   • 描述：是否在RDB文件中包含校验和。启用校验和可以确保RDB文件的完整性，但会增加一些额外的计算开销。

4. rdb-del-sync-files：

   • 默认值：no
   • 描述：是否在删除RDB文件时同步删除文件。启用此选项可以确保删除RDB文件时立即释放磁盘空间，但可能会降低性能。

2.2 AOF (Append Only File)

Aof保存的是 appendonly.aof 文件 

将我们所有的命令都记录下来，history，恢复的时候就把这个文件全部再执行一遍

 

以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取

该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

配置

appendonly no   # 是否以append only模式作为持久化方式，默认使用的是rdb方式持久化，这
种方式在许多应用中已经足够用了
appendfilename "appendonly.aof"   # appendfilename AOF 文件名称
appendfsync everysec  # appendfsync aof持久化策略的配置# no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。# always表示每次写入都执行fsync，以保证数据同步到磁盘。# everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。
No-appendfsync-on-rewrite #重写时是否可以运用Appendfsync，用默认no即可，保证数据安
全性
Auto-aof-rewrite-min-size # 设置重写的基准值
Auto-aof-rewrite-percentage #设置重写的基准值

默认是没有开启的 我们需要的话需要手动开启 把 appendonly no 改为 appendonly yes

如果Aof文件受损了Redis启动不起来 我们可以通过 redis-check-aof --fix 来修复aof文件

 AOF 持久化工作流程

AOF 缓冲区三种写回策略

• always 同步写回，每个写命令执行完立刻同步地将日志写回磁盘
• everysec (默认)每秒写回，每个写命令执行完，只是先把日志写到AOF缓冲区，每隔1s把缓存区地数据写入磁盘
• no操作系统控制写回，只是将日志先写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

优化参数

优缺点

优点

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

缺点

1. 相对于数据文件来说，aof远远大于rdb，修复速度比rdb慢！
2. Aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化

AOF重写机制（Log rewriting）

AOF 文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename），遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，这点和快照有点类似！

触发机制：

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的已被且文件大于64M的触发。

2.3RDB+AOF混合

AOF默认是关闭的，当两者共存时，AOF的优先级高

同时开启两种持久化方式

• 当redis 重启时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
• RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。
  • 那要不要只使用AOF呢
    • 安特雷兹建议不要
    • 因为RDB更适合用于备份数据库（AOF不断变化不好备份），留着AOF作为一个万一的手段

2.4纯缓存模式

同时关闭RDB + AOF

• save “”
  • 禁用rdb
  • 禁用db持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件
• appendonly no
  • 禁用aof
  • 禁用aof持久化模式下，我们仍然可以使用命令 bgrewriteaof生成aof文件

2.5总结

• RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储
• AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
• 只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化