redis配置文件&持久化存储

redis配置文件

• 配置文件中对于单位的大小写不敏感

• incloud /path/to/other.conf引入其他配置文件

• bind 127.0.0.1 限定访问的IP

• protected-mode yes保护模式

• port 6379 设置启动端口

• daemonize yes 以守护进程的方式运行

• pidfile /var/run/redis_6379.pid 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定

• loglevel notice 指定默认级别 从低到高 分别是 specify debug verbose notice（默认，生产环境配置）warn

• logfile "" 日志文件位置。为空时不生成日志文件

• databases 16 数据库数量默认是16

• always-show-logo yes 是否总是显示logo

• 持久化，在规定时间内，执行了多少次操作，则会持久到文件中。

  save 900 1 #如果900s内有1个key发生变化。执行save操作.将数据同步到磁盘
  save 300 10 # 如果300s内有10个key发生变化。执行save操作.将数据同步到磁盘
  save 60 10000# 如果60s内有10000个key发生变化。执行save操作.将数据同步到磁盘
  

• 安全

  # requirepass foobared 配置连接密码。配置后需要先验证才能正常访问
  127.0.0.1:6379> ping # 正常访问
  PONG
  127.0.0.1:6379> config set requirepass 123456 # 设置密码
  OK
  ###退出客户端重新登录
  127.0.0.1:6379> ping #无法正常访问。提示需要权限验证
  NOAUTH Authentication required.
  
  127.0.0.1:6379> AUTH 123456 # 验证密码
  OK
  127.0.0.1:6379> ping  # 验证密码后正常访问
  PONG
  127.0.0.1:6379>
  
  

• maxclient 10000 默认允许10000个客户端同时连接

• maxmemory redis最大占用内存单位 byte

• maxmemory-policy noeviction 内存到达上限后的处理策略

  1、volatile-lru： 只对设置了过期时间的key进行LRU（默认值）

  2、allkeys-lru ： 删除lru算法的key

  3、volatile-random： 随机删除即将过期key

  4、allkeys-random： 随机删除

  5、volatile-ttl ： 删除即将过期的

  6、noeviction ： 永不过期，返回错误

redis的持久化存储

快照机制 RDB

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb

• 触发快照方式：

• 手动执行save命令（属于同步操作会阻塞线程，其他的都是bgsave 。会创建fork进程来执行快照存储。不会阻塞进程）

• 服务器关闭

• 清空数据库（flushall）

• 配置文件里面的 save num1 num2 命令 当在 num2（秒）时间内有num2个数据发生变化会自动触发save操作。

• rdb相关配置参数

• **stop-writes-on-bgsave-error ：**默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了

• rdbcompression : 默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。

• rdbchecksum ： 默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

• dbfilename ： 设置快照的文件名，默认是 dump.rdb

• dir： 设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。

• save和bgsave的比较：
  

RDB的优缺点

• 优点
• 全量备份。恢复速度快
• 子进程执行保存操作。主进程不会与磁盘产生io操作
• 劣势
• 不是实时更新。需要条件触发。如果突然宕机。可能会导致数据丢失。
• 如果数据量较大。在fork子进程时会有短暂的停止服务。

AOF存储

AOF持久化存储会记录每一次对服务器的写操作。当服务器重启是会重新执行这些命令来回复原始数据。AOF命令以Redis协议追加保存每一次写的操作到文件末尾。Redis还能对AOF文件进行后台重写。使得AOF文件不会太大。

当RDB和AOF都开启时。优先使用AOF。因为AOF数据更全。更新更及时。

• 文件重写原理：

• 当命令越来越多。AOF文件会越来越大。为了节省空间。redis提供了bgrewriteaod命令将内存中的数据以命令的方式保存到临时文件中。同时会fork出一条新的进程来将文件进行重写。

• 重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

• 追加AOF文件触发机制：

  • always 每次写操作都会同步到磁盘(io开销太大)
  • everysec 每秒同步到磁盘一次。（会丢失1s的数据）
  • no 不同步

• 性能建议：

• 因为rdb文件只做备份使用。所以只保留 save 900 1 这一个策略即可

• 如果使用了AOF存储。持续IO将不可避免。需要精良减少AOF的rewrite的频率。

• 可以使用ms来避免数据丢失，但是当所有机器都同时宕机。那么只能用RDB进行恢复。会丢失数据。

优缺点

• 优点

• 尽可能保证数据不会丢失 everysec策略下最多丢失1s的数据。

• AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。

• AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。

• AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

• 缺点

• 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大

• AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

• 以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。

• 比较