Redis学习笔记第二天

在这里插入图片描述

Redis配置文件相关

INCLUDES

  我们知道Redis只有一个配置文件,如果多个人进行开发维护,那么就需要多个这样的配置文件,这时候多个配置文件就可以在此通过 include /path/to/local.conf 配置进来,而原本的 redis.conf 配置文件就作为一个总闸。
另外需要注意的时,如果将此配置写在redis.conf 文件的开头,那么后面的配置会覆盖引入文件的配置,如果想以引入文件的配置为主,那么需要将 include 配置写在 redis.conf 文件的末尾。

NETWORK

  • 1.bind: 绑定redis服务器网卡IP,默认为127.0.0.1,即本地回环地址。 这样的话,访问redis服务只能通过本机的客户端进行访问,而无法通过远程连接。如果bind选项为空的话(即将bind这一行注释),那会接受所有来自于可用网络接口的连接。
    1. port: 指定redis的运行的端口,默认是6379。由于redis是单线程模型(redis6.0之前),所以当单机起多个redis服务的话,就需要修改端口。
    1. timeout: 设置客户端连接时的超时时间,单位为秒。当客户端在指定的时间内没有与服务器端进行交互,那么关闭该连接。默认为0,代表不关闭。
  • tcp-keepalive: 单位为秒,表示将周期性的使用SO_KEEPALIVE检测客户端是否还处于健康状态,避免服务器一直阻塞,官方给出的建议值是300s,如果设置为0则代表不进行检测。

GENERAL

  • 1.daemonize: 设置为yes表示指定Redis以守护进程的方式启动(后台启动),默认值为no。
  • 2.pidfile: 配置PID文件路径,当Redis作为守护进程运行的时候,它会把pid默认写到/var/run/redis_6379.pid文件里面
    1. loglevel: 定义日志级别。默认值为notice,有如下4种取值。
      • debug (纪录大量日志信息,适用于并发、测试阶段)
      • verbose (较多日志信息)
      • notice (适量日志信息,适用于生产环境)
      • warning (仅有部分重要、关键信息才会被纪录)
  • logfile: 配置log文件地址,默认打印在命令行终端的窗口上
  • databases: 设置数据库的数目。默认的数据库是DB 0, 可以在每个连接上使用 select 命令选择一个不同的数据库,dbid是一个介于0到databases-1之间的数值。默认值是16,也就是说默认Redis有16个库。

CLIENTS

  • 1.maxclients: 设置客户端最大并发连接数,默认无限制。Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数-32(redis server自身会使用一些)。如果设置maxclients为0,表示不做限制。当客户端连接数到达限制时,Redis会关闭新的连接并向客户端返回max number of clients reached错误信息。

MEMORY MANAGEMENT

  • 1.maxmemory: 设置Redis的最大内存,如果设置为0。表示不做限制,通常是配合下面介绍的maxmemory-policy参数一起使用。
  • 2.maxmemory-policy: 当内存使用达到maxmemory设置的最大值时,redis使用的内存清除策略。有以下几种可以选择:
    • 1) volatile-lru: 利用LRU算法移除设置过 过期时间的key(LRU:最近使用 Least Recently Used)
    • 2) allkeys-lru: 利用LRU算法移除任何key
    • 3) volatile-random: 移除设置过 过期时间的随机key
    • 4) allkeys-random 移除随机key
    • 5) volatile-ttl 移除即将过期的key (minor TTL)
    • 6) noeviction 不移除任何一个key,只是返回一个写错误,默认为此选项
    1. maxmemory-samples: LRU 和 minimal TTL 算法都不是精准的算法,但是相对精准的算法(为了节省内存)。redis默认选择3个样本进行检测,你可以通过maxmemory-samples进行设置样本数。

Redis持久化

众所周知,Redis是基于内存的非关系型数据库。即断电即失,那么出现意外情况如何保证数据的安全性呢?我们可以将内存的数据持久化到硬盘上面,因为硬盘断电之后并不会丢失数据。
Redis种,有两种持久化的方式,分别是RDB(Redis DataBase)和AOF(Append Only File)

RDB (Redis DataBase)

RDB其实就是将数据以快照的形式持久化到硬盘。你可以理解为将当前时刻的数据拍成一张照片保存下来。

RDB机制是通过把某个时刻的所有数据生成一个快照来保存,那么就应该有相关的触发方式。对于RDB来说,提供了三种机制来触发持久化: save, bgsave, 自动化。

基本概念

指定的时间间隔内将内存中的数据集快照写入磁盘,也就是专业术语Snapshot快照,它恢复时是将快照文件直接读到内存里。

Redis会单独创建(fork)一个子进程来进行持久化,回先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能。
如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失

fork

学习过Linux系统编程的哥哥们应该知道这玩意,Fork的作用就是复制一个与当前进程一样的进程。 新进程的所有数据(变量、环境变量、程序计数器等)都与原进程一致,但是是一个全新的进程,而非原进程的子进程。

dump.rdb文件

即通过RDB方式持久化硬盘生成的二进制文件,当redis服务器端启动时,会从该文件中读取数据加载到内存。

save触发方式

当redis客户端键入命令save后,可直接阻塞当前redis服务器,让redis服务器进行数据的持久化。在此期间redis服务器不能处理其他客户端的请求,知道持久化到硬盘的动作完成才可以继续处理客户端的请求。

这种方式会阻塞其他客户端,当我们部署到生产环境的时候,这种方法显然会带来大量用户的卡顿,不建议使用。

bgsave触发方式

当redis客户端执行该条命令,Redis服务器端会在后台完成持久化操作。即会通过fork函数生成一个新的进程完成数据的持久化操作,不会阻塞原进程的服务。即其他客户端可以继续请求该Redis服务。

该方式会在fork时候由于需要基于内存拷贝数据,会有短暂的拒绝服务时间,且需要再生成一份快照到内存中(现在机器应该不会在乎这点内存。

自动化触发

# save <seconds> <changes>
我们可以配置配置文件,当在seconds秒后 有指定条key发生改变则会持久化到硬盘上面。
默认有如下三条纪录

1
2
3
save 900 1
save 300 10
save 60 10000

代表着当60秒后,若key改变的数目大于10000则直接持久化到硬盘,当300秒后有10条key发生改变则持久化硬盘。 我们可以发现,随着时间的变成 改变key的要求也越来越低,这符合我们实际的业务需求,因为当高平发的情况下,肯定在短时间内有大量的change操作。所以我们需要持久化。 当Redis服务处于空闲时 就没必要高频率的去进行持久化操作了。

取消自动化持久化操作。我们可以将所有的save指令注释,或者 save “” 。 或可以客户端执行指令 config set save ""来关闭Redis的持久化。

flushall

当将Redis的全部数据库进行清除时,也会立即生成一份dump.rdb文件.此时dump文件为空,没意义。

其他参数

  • stop-writes-on-bgsave-error : 默认值为yes 其代表当启用了RDB且最后一次后台保存数据失败,Redis是否停止接受数据。这会让用户意识到数据没有正确的持久化到硬盘上,否则没有人会注意到灾难发生了。

  • rdbcompression:默认值是 yes。 对于存储到磁盘的快照,可以设置是否进行压缩存储。 进行压缩存储会节省硬盘空间,但同时会占用少量的cpu资源。鱼和熊掌 根据业务抉择

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

  • dbfilename:设置到处快照的名字 默认dump.rdb

  • dir: 设置快照文件的存储位置。 该配置项一定是一个目录而不能是文件名。默认为当前目录下 即redis-server同级目录

save 与 bgsave比较

命令 save bgsave
IO类型 同步 异步
阻塞? 是(短暂的fork调用)
复杂度 O(n) O (n)
优点 不会消耗额外内存 不阻塞客户端命令
缺点 阻塞客户端命令 需要fork,消耗额外内存

RDB的优点与缺点

优点

  1. RDB文件紧凑,全量备份,非常适合于进行备份和灾难恢复。
  2. 生成RDB文件的时候,Redis主进程会fork一个新的进程进行持久化操作,Redis主进程不需要进行任何磁盘IO的操作。
  3. RDB在恢复大数据集时的速度比AOF的恢复速度要快。

缺点
RDB快照是一次全量备份,存储的是内存数据的二进制序列化形式,存储上非常紧凑。当进行快照持久化时候,会fork一个新的进程完成持久化操作,但是此时Redis进程如果对数据进行了更新,子进程并不会立刻觉察到,所以可能会导致部分数据不一致的情况。

AOF

全量备份总是耗时的,有时候我们提供一种更加高效的方式AOF,工作机制很简单,Redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。

基本概念

以日志的形式来纪录每个写操作。将Redis执行过的所有写指令纪录下来(读指令不纪录),只允许追加文件但不可以改写文件,Redis启动之初会读取该文件重新构建数据,换言之,Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

appendonly.aof文件

当客户端有写操作时,就会更新此备份文件。 当出现服务器宕机等灾难情况之后,重启Redis服务就会读取该备份文件,执行该文件的全部命令用来恢复数据。 如果同时开始了RDB和AOF两种持久化策略,则读取aof文件用来恢复!且不会读取dump.rdb文件 亲测

redis-check-rdb 与 redis-check-aof

redis-check-rdb file 可以检测file文件是否为一个正确的dump文件

redis-check-aof --fix file可以检测文件是否是一个正确的aof文件,如果不正确,可以键入命令y令其修改为正确的格式。

AOF的触发方式

我们可以修改配置文件,选择一种AOF持久化到硬盘的方式。Redis提供了三种AOF触发策略。

  • appendfsync always(每次修改进行持久化) 这种方式为同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好

  • appendfsync everysec(每秒钟进行一次持久化) 异步操作,每秒记录 如果一秒内宕机,有数据丢失

  • appendfsync no(不同步)

默认为每秒进行持久化

对比

命令 always everysec no
优点 不丢失数据 每秒一次fsync丢1秒数据 不用管
缺点 IO开销较大,一般的stat盘只有几百TPS 丢1秒的数据 不可控

Rewrite

因为AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof
AOF文件的持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进程的内存中数据,每条记录有一条set语句。 重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写一个新的aof文件,这点与快照类似。

Redis会纪录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64MB时触发

相关配置

  • appendonly:是否启动AOF 默认为no 启动改为yes
  • appendfilename: 持久化到硬盘的名字,默认为”appendonly.aof”
  • no-appendfsync-on-rewrite:重写时 是否启用Appendfsync,用默认的no即可,保证数据的安全性
  • auto-aof-rewrite-percentage: 设置重写百分比 默认为100 代表文件大小需要为上次的2倍
  • auto-aof-rewrite-min-size: 设置重写阈值 当大于等于该值才进行重写

AOF方式的优缺点

  • 优点

    • AOF由于纪录了每条写操作,可以更好的保护数据的安全性,默认情况下最多会丢失一秒的数据。
    • AOF日志文件没有任何磁盘寻址的开销,写入性能非常高,文件不容易出现损坏。
    • AOF日志文件即使过大的情况,出现后台重写操作,也不会影响客户端的读写。
    • AOF日志文件的命令通过非常可读的方式进行纪录,这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令,清空了所有数据,只要这个时候后台rewrite还没有发生,那么就可以立刻拷贝AOF文件,将最后一条flushall命令给删除,然后通过恢复机制即可恢复所有的数据。
  • 缺点

    • AOF文件保证了可读性及纪录了每一条写操作,所以日志文件通常比RDB文件更大
    • AOF开启后,支持的写QPS比RDB支持的写QPS低。因为AOF一般会配置成每秒fsync一次日志文件,所以有一定的性能损耗。
    • 以前AOF发生过BUG,就是通过AOF纪录的日志,进行数据恢复的时候,没有恢复出一模一样的数据

RDB与AOF对比

命令 RDB AOF
启动优先级
日志体积
恢复速度
数据安全性 丢数据 根据策略决定
轻重
-------------本文结束,感谢您的阅读!-------------