4、Redis配置文件

在哪里

redis-x.x.x/目录下的redis.conf文件
PS.对配置文件进行修改时，一定要先进行备份再进行修改

1、UNITS/单位

• 配置文件中的容量度量单位只支持bytes，不支持bit，并且给了单位换算示例

• 单词大小写不敏感

  
  Units

2、INCLUDES/包含

• 指定包含其他的配置文件

• 可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各实例又拥有自己的特定配置文件

  
  includes

3、GENERAL/通用

• daemonize

  • Redis 默认不是以守护进程的方式运行，可以通过该配置项修改，使用 yes 启用守护进程（Windows 不支持守护线程的配置为 no ）
  • 简单的说，设置yes，redis就在后台运行

• pidfile

  • 当 Redis 以守护进程方式运行时，Redis 默认会把 pid 写入 /var/run/redis.pid文件，也可以自行改动

• port

  • 指定 Redis 的监听端口，默认是6379，据说来源于某个意大利女歌手的名称啥的

• bind

  • 绑定指定ip可访问，0.0.0.0是不限制，配置多个ip例⼦：12.13.432.12 31.12.43.13，⽤空格隔开

• timeout

  • 设置客户端闲置几秒后会关闭连接，默认是0，代表关闭该功能

• tcp-backlog

  • 设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。
  • 在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值，所以需要确认增大somaxconn和tcp_max_syn_backlog两个值来达到想要的效果

• tcp-keepalive

  • keepalive监测时间，默认为0，不进行keepalive监测，建议设置为60

• loglevel

  • 指定日志的记录级别，Redis 总共支持四个级别：debug、verbose、notice、warning，默认为 notice

• logfile

  • 指定日志文件的名称，默认为空字符串+标准输出的方式；但是如果以守护进程的方式启动Redis，则会把日志输出到/dev/null中

• Syslog-enabled

  • 是否把日志输出到syslog中

• Syslog-ident

  • 指定syslog里的日志标志

• Syslog-facility

  • 指定syslog设备，值必须是USER或LOCAL0-LOCAL7

• Databases
  • 设置Reids的数据库数量，默认是16个，并且默认是连接第一个（索引为0），可以在redis-cli中使用select <dbid>切换当前连接的数据库

4、SNAPSHOTTING/快照

对内存数据持久化到磁盘的配置，这部分数据会根据配置的策略，默认保存到dump.rdb文件中。如果一些意外发生（比如redis挂了），那么再重启redis后，会自动从这个rdb文件把数据重新写入到内存中。

• RDB持久化的原理和异常场景
  Redis在保存内存数据到硬盘时，为了避免主进程假死导致无法处理正常的业务。此时它会在后台fork()一份主进程，然后在这个fork进程中完成内存数据保存到硬盘的操作。

  • 异常场景1：磁盘空间不足；假设此时内存数据很大，创建rdb文件需要10s。那么在这段时间内，如果创建rdb文件报错了（磁盘或内存满之类的）。默认情况下，redis会拒绝新的写入，无法进行set操作，抛异常（通过修改redis配置来无视这个错误，继续接受新的写入）
  • 异常场景2：内存空间不足；假设总内存是4GB，此时主进程如果用了2.1GB，那么fork进程也需要2.1GB，此时内存就不够，那么fork进程就会写入RDB文件失败，从而导致主进程会抛出异常，在redis日志中可能出现这种异常：Can’t save in background: fork: Cannot allocate memory（可以修改redis配置或者修改内核参数进行缓解，但并不能根本解决）

• 设置触发条件save <seconds> <changes>
  默认触发条件：

save 900 1  # 900秒/15分钟至少有1个key发生了改变，则触发快照
save 300 10 # 300秒/5分钟至少有10个key发生了改变，则触发快照
save 60 10000 # 60秒/1分钟至少有10000个key发生了改变，则触发快照

• 禁用save ""
  如果想禁用RDB持久化策略，那么只需要把save指令都注释掉，或者给save传个空字符串即可

• Stop-writes-on-bgsave-error
  简单来说，就是当rdb快照文件出错时，主进程的写入操作是否继续执行
  默认是yes，如果fork进程创建rdb快照文件出错， redis主进程的写入操作会立刻停止，也就是无法进行set操作，抛异常。
  如果设置为no，则会忽略本次快照文件的异常，主进程继续写入操作，说明此时你不在乎持久化数据和内存数据的不一致性。

• rdbcompression
  默认yes
  对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能

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

• dbfilename
  设置保存的rdb文件的名称，默认是dump.rdb

• dir
  设置rdb文件所在的路径，默认是当前路径./

5、REPLICATION/复制

这个到后面学习redis复制时再写

6、SECURITY/安全

redis默认是没有密码的。但是它也支持设置密码，并且它的密码是所有数据库共用的。
如果设置了密码，那么在访问时，需要输入密码才能进行操作。

• 查看密码
  config get requirepass
• 设置密码
  config set requirepass "123456"
• 取消密码
  auth

7、LIMITS/限制

• Maxclients
  设置redis同时可以和多少个客户端进行连接，默认情况下是1万个客户端。
  当你无法设置进程文件句柄限制时，redis会设置为当前的文件句柄限制-32，因为redis会为自身内部逻辑处理留一些句柄出来。如果到了这个限制，redis就会拒绝新的连接请求，并且向这些新的连接请求方发出max number of clients reached的响应

• Maxmemory
  设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。
  如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。但是对于无内存申请的指令，仍然会正常响应，比如GET等。
  如果你的redis是主redis（说明你的redis有从redis），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移除”的情况下，才不用考虑这个因素。
  简单来说：
  指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区

• Maxmemory-policy/key移除规则
  默认是noeviction
  1.volatile-lru：使用LRU算法移除key，只对设置了过期时间的键有效
  2.allkeys-lru：使用LRU算法移除key，对所有的key都有效
  3.volatile-random：在过期集合中移除随机的key，只对设置了过期时间的键
  4.allkeys-random：移除随机的key
  5.volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key
  6.noeviction：不进行移除。针对写操作，只是返回错误信息

LRU全称是Least Recently Used，即最近最久未使用的意思。
LRU算法的设计原则是：如果一个数据在最近一段时间没有被访问到，那么在将来它被访问的可能性也很小。也就是说，当限定的空间已存满数据时，应当把最久没有被访问到的数据淘汰。

• Maxmemory-samples
  设置样本数量，默认是5。
  LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis会检查这么多个key并选择其中LRU的那个。

8、APPEND ONLY MODE/追加

Redis两大持久化策略之一的AOF策略。
AOF在同步内存数据到磁盘上时，并不是马上把文件写入到磁盘中，而是先把文件缓存到系统，然后每隔多少秒将文件写入到磁盘中，我们可以在配置文件中修改``Appendfsync```配置项来修改同步的策略。

• appendonly
  默认为no
  指定是否在每次更新操作后进行操作日志的记录（也就是写入到AOF文件中）。
  Redis在默认情况下是RDB策略；也就是异步的把内存数据写入磁盘。
  如果不开启AOF，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按设置RDB的save条件来同步的，所以有的数据会在一段时间内只存在于内存中，这段时间内如果不触发RDB且同步成功，则这段时间新增的数据就会丢失。

• appendfilename
  指定AOF文件名，默认为appendonly.aof

• Appendfsync
  指定更新AOF文件的条件，共有3个可选值
  Always：同步持久化；每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好
  Everysec：出厂默认推荐；异步操作，每秒记录到磁盘，如果一秒内宕机，那么可能会丢失这1秒的数据。
  No：表示等操作系统进行数据缓存同步到磁盘（快）

• No-appendfsync-on-rewrite
  指定是否启用虚拟内存机制，默认值为no。
  VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（Redis的VM机制）

AOF的原理是直接把用户插入到服务器的命令追加到文件末尾，所以文件会原来越大，一些重复的写命令也会越来越多。这时候就需要进行重写AOF。

• Auto-aof-rewrite-min-size
  aof文件大小超过上次重写时文件大小的百分之几开始重写，如果之前没有写过，则根据启动时文件大小。
  默认是100，也就是达到上次文件大小的1倍时进行重写。

• Auto-aof-rewrite-percentage
  aof文件增长比例，指当前aof文件比上次重写的增长比例大小。默认是64mb（实际肯定要调大）
  aof重写即在aof文件在一定大小之后，重新将整个内存写到aof文件当中，以反映最新的状态(相当于bgsave)。这样就避免了aof文件过大，而实际内存数据小的问题(频繁修改数据问题)。

推荐的文章

看完后也可以去看下：https://www.cnblogs.com/zxtceq/p/7676911.html