redis配置文件redis.conf总结

redis配置文件redis.conf总结

1.通用配置

1. 查看yum 安装的redis.conf位置

   yum install redis
   rpm -qa|grep redis
   rpm -ql redis-3.2.10-2.el7.x86_64
   >>>
   /etc/redis.conf
   

2. 查看 redis 进程状态
   ps -ef|grep redis
3. 守护进程
   daemonize no

   当以 daemon 形式运行时，Redis 会生成一个 pid 文件，默认会生成在 /var/run/Redis.pid 。当然，可以通过 pidfile 来指定 pid 文件生成的位置

4. 指定 pid 文件生成的位置
   pidfile /path/to/Redis.pid
5. 指定要绑定的IP
   bind 192.168.1.2 10.8.4.2
6. 修改监听端口
   port 6379

   如果端口设置为0的话，Redis 便不会监听端口了。

7. 通过 unix socket 方式来接收请求。
   unixsocket /tmp/Redis.sock
   unixsocketperm 700
8. Tcp backlog 的值
   tcp-backlog 511

   想要提高 backlog 的值，除了需要设置 Redis 的 tcp-backlog ，还要同时提高更改 Linux 的配置，否则，Linux内核会默认将其截取为 /proc/sys/net/core/somaxconn 的大小。

9. timeout 超时
   timeout 0

   当一个 Redis-client 一直没有请求发向 server 端，那么 server 端有权主动关闭这个连接，可以通过timeout 来设置“空闲超时时限”，0表示永不关闭。

10. TCP连接保活策略
    tcp-keepalive 0

    TCP连接保活策略，可以通过 tcp-keepalive 配置项来进行设置，单位为秒，假如设置为60秒，则 server 端会每60秒向连接空闲的客户端发起一次 ACK 请求，以检查客户端是否已经挂掉，对于无响应的客户端则会关闭其连接。

11. 日志等级
    loglevel notice

    loglevel 配置项设置日志等级，共分四级，即 debug、verbose、notice、warning。

12. 日志文件的生成位置
    logfile “”

    Redis也支持通过 logfile 配置项来设置日志文件的生成位置。如果设置为空字符串，则 Redis 会将日志输出到标准输出。假如在 daemon 情况下将日志设置为输出到标准输出，则日志会被写到 /dev/null 中。

13. 设置其数据库的总数量
    databases 16

    2. Redis 的 RDB 持久化相关的配置

14. save

    save 900 1 //表示每15分钟且至少有1个 key 改变，就触发一次持久化
    save 300 10 //表示每5分钟且至少有10个 key 改变，就触发一次持久化
    save 60 10000 //表示每60秒至少有10000个 key 改变，就触发一次持久化
    如果想禁用 RDB 持久化的策略，只要不设置任何 save 指令就可以，或者给 save 传入一个空字符串参数也可以达到相同效果，就像这样：
    save””

15. stop-writes-on-bgsave-error yes

    如果不在乎这种数据不一致或者有其他的手段发现和控制这种不一致的话完全可以关闭这个功能，以便在快照写入失败时，也能确保 Redis 继续接受新的写请求

16. rdbcompression yes

    对于存储到磁盘中的快照，可以设置是否进行压缩存储。

17. rdbchecksum yes

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

18. dbfilename dump.rdb

    还可以设置快照文件的名称，默认是这样配置的

19. dir ./db/

    还可以设置这个快照文件存放的路径。

    3. 主从配置

20. slaveof

    通过 slaveof 配置项可以控制某一个 Redis 作为另一个 Redis 的从服务器，通过指定 IP 和端口来定位到主Redis 的位置。一般情况下建议用户为从 Redis 设置一个不同频率的快照持久化的周期，或者为从 Redis 配置一个不同的服务端口等等。

21. masterauth

    如果主 Redis 设置了验证密码的话（使用 requirepass 来设置），则在从 Redis 的配置中要使用masterauth 来设置校验密码，否则的话，主 Redis 会拒绝从 Redis 的访问请求。

22. slave-serve-stale-data yes
23. slave-serve-stale-data no

    当从 Redis 失去了与主 Redis 的连接，或者主从同步正在进行中时， Redis 该如何处理外部发来的访问请求呢？这里，从 Redis 可以有两种选择：yes （默认），则从 Redis 仍会继续响应客户端的读写请求。no，则从 Redis 会对客户端的请求返回“SYNC with master inprogress”

24. slave-read-only yes

    可以控制一个从 Redis 是否可以接受写请求。将数据直接写入从 Redis ，一般只适用于那些生命周期非常短的数据，因为在主从同步时，这些临时数据就会被清理掉。自从 Redis2.6 版本之后，默认从 Redis 为只读。

25. repl-ping-slave-period 10

    只读的从 Redis 并不适合直接暴露给不可信的客户端。为了尽量降低风险，可以使用 rename-command指令来将一些可能有破坏力的命令重命名，避免外部直接调用。比如：
    rename-command CONFIG b8c02d524045429941cc15f59e41cb7be6c52
    从 Redis 会周期性的向主 Redis 发出 PING 包。可以通过 repl_ping_slave_period 指令来控制其周期。默认是10秒。

26. repl-timeout 60

    在主从同步时，可能在这些情况下会有超时发生：
    （1）以从 Redis 的角度来看，当有大规模 IO 传输时。
    （2）以从 Redis 的角度来看，当数据传输或 PING 时，主 Redis 超时
    （3）以主 Redis 的角度来看，在回复从 Redis 的 PING 时，从 Redis 超时
    用户可以设置上述超时的时限，不过要确保这个时限比 repl-ping-slave-period 的值要大，否则每次主Redis 都会认为从 Redis 超时。

27. repl-disable-tcp-nodelay no

    我们可以控制在主从同步时是否禁用 TCP_NODELAY 。如果开启 TCP_NODELAY ，那么主 Redis 会使用更少的 TCP 包和更少的带宽来向从 Redis 传输数据。但是这可能会增加一些同步的延迟，大概会达到40毫秒左右。如果关闭了 TCP_NODELAY ，那么数据同步的延迟时间会降低，但是会消耗更多的带宽。

28. repl-backlog-size 1mb

    可以设置同步队列长度。队列长度（ backlog )是主 Redis 中的一个缓冲区，在与从 Redis 断开连接期间，主 Redis 会用这个缓冲区来缓存应该发给从 Redis 的数据。这样的话，当从 Redis 重新连接上之后，就不必重新全量同步数据，只需要同步这部分增量数据即可。

29. repl-backlog-ttl 3600

    如果主 Redis 等了一段时间之后，还是无法连接到从 Redis ，那么缓冲队列中的数据将被清理掉。我们可以设置主 Redis 要等待的时间长度。如果设置为0，则表示永远不清理。默认是1个小时。

30. slave-priority 100

    我们可以给众多的从 Redis 设置优先级，在主 Redis 持续工作不正常的情况，优先级高的从 Redis 将会升级为主 Redis 。而编号越小，优先级越高。比如一个主 Redis 有三个从 Redis ，优先级编号分别为10、100、25，那么编号为10的从 Redis 将会被首先选中升级为主 Redis 。当优先级被设置为0时，这个从Redis 将永远也不会被选中。默认的优先级为100。

31. min-slaves-to-write 3
32. min-slaves-max-lag 10

    假如主 Redis 发现有超过M个从 Redis 的连接延时大于N秒，那么主 Redis 就停止接受外来的写请求。这是因为从 Redis 一般会每秒钟都向主Redis发出PING，而主Redis会记录每一个从 Redis 最近一次发来 PING 的时间点，所以主 Redis 能够了解每一个从 Redis 的运行情况。

    上面这个例子表示，假如有大于等于3个从 Redis 的连接延迟大于10秒，那么主 Redis 就不再接受外部的写请求。上述两个配置中有一个被置为0，则这个特性将被关闭。默认情况下 min-slaves-to-write 为0，而 min-slaves-max-lag 为10。

    4. 安全配置

33. requirepass xxxxx

    我们可以要求 Redis 客户端在向 Redis-server 发送请求之前，先进行密码验证。由于 Redis 性能非常高，每秒钟可以完成多达15万次的密码尝试，所以最好设置一个足够复杂的密码，否则很容易被黑客破解。

34. rename-command CONFIG b840fc02d5240454299c15f59e41cb7be6c89

    Redis 允许我们对 Redis 指令进行更名，比如将一些比较危险的命令改个名字，避免被误执行。比如可以把 CONFIG 命令改成一个很复杂的名字，这样可以避免外部的调用，同时还可以满足内部调用的需要.

    但需要注意的是，如果使用 AOF 方式进行数据持久化，或者需要与从 Redis 进行通信，那么更改指令的名字可能会引起一些问题。

    5. 限制配置

35. maxclients 10000

    我们可以设置 Redis 同时可以与多少个客户端进行连接。默认情况下为10000个客户端。当无法设置进程文件句柄限制时， Redis 会设置为当前的文件句柄限制值减去32，因为 Redis 会为自身内部处理逻辑留一些句柄出来。
    如果达到了此限制， Redis 则会拒绝新的连接请求，并且向这些连接请求方发出 “max number of clients reached” 以作回应。

36. maxmemory

    如果 Redis 无法根据移除规则来移除内存中的数据，或者我们设置了“不允许移除”，那么 Redis 则会针对那些需要申请内存的指令返回错误信息，比如 SET 、 LPUSH 等。但是对于无内存申请的指令，仍然会正常响应，比如 GET 等。

    如果 Redis 是主 Redis （说明 Redis 有从 Redis ），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在设置的是“不移除”的情况下，才不用考虑这个因素。

37. maxmemory-policy volatile-lru

    对于内存移除规则来说， Redis 提供了多达6种的移除规则。他们是：
    （1）volatile-lru：使用 LRU 算法移除过期集合中的 key
    （2）allkeys-lru：使用 LRU 算法移除 key
    （3）volatile-random：在过期集合中移除随机的 key
    （4）allkeys-random：移除随机的 key
    （5）volatile-ttl：移除那些 TTL 值最小的 key ，即那些最近才过期的 key
    （6）noeviction：不进行移除。针对写操作，只是返回错误信息
    无论使用上述哪一种移除规则，如果没有合适的 key 可以移除的话， Redis 都会针对写请求返回错误信息。

38. maxmemory-samples 3

    LRU算法和最小TTL算法都并非是精确的算法，而是估算值。所以可以设置样本的大小。假如 Redis 默认会检查三个 key 并选择其中 LRU 的那个，那么可以改变这个 key 样本的数量。

    6. AOF配置

39. appendonly yes

    默认情况下， Redis 会异步的将数据持久化到磁盘。这种模式在大部分应用程序中已被验证是很有效的，但是在一些问题发生时，比如断电，则这种机制可能会导致数分钟的写请求丢失。
    如上半部分中介绍的， AOF 是一种更好的保持数据一致性的方式。即使当服务器断电时，也仅会有1秒钟的写请求丢失，当 Redis 进程出现问题且操作系统运行正常时，甚至只会丢失一条写请求。

    官方建议， AOF 机制和 RDB 机制可以同时使用，不会有任何冲突。

40. appendfilename “appendonly.aof”

    我们还可以设置 AOF 文件的名称

41. appendfsync everysec

    fsync()调用，用来告诉操作系统立即将缓存的指令写入磁盘。一些操作系统会“立即”进行，而另外一些操作系统则会“尽快”进行。
    Redis支持三种不同的模式：
    （1）no：不调用 fsync() 。而是让操作系统自行决定 sync 的时间。这种模式下， Redis 的性能会最快。
    （2）always：在每次写请求后都调用 fsync() 。这种模式下， Redis 会相对较慢，但数据最安全。
    （3）everysec：每秒钟调用一次 fsync() 。这是性能和安全的折衷。

    默认情况下为 everysec 。

42. no-appendfsync-on-rewrite no

    当 fsync 方式设置为 always 或 everysec 时，如果后台持久化进程需要执行一个很大的磁盘IO操作，那么 Redis 可能会在 fsync() 调用时卡住。目前尚未修复这个问题，这是因为即使我们在另一个新的线程中去执行 fsync() ，也会阻塞住同步写调用。
    为了缓解这个问题，我们可以使用下面的配置项，这样的话，当 BGSAVE 或 BGWRITEAOF 运行时， fsync() 在主进程中的调用会被阻止。这意味着当另一路进程正在对 AOF 文件进行重构时， Redis 的持久化功能就失效了，就好像我们设置了 “appendsync none” 一样。如果 Redis 有时延问题，那么可以将下面的选项设置为yes。否则请保持no，因为这是保证数据完整性的最安全的选择。

43. auto-aof-rewrite-percentage 100
44. auto-aof-rewrite-min-size 64mb

    我们允许 Redis 自动重写 aof 。当 aof 增长到一定规模时， Redis 会隐式调用 BGREWRITEAOF 来重写log文件，以缩减文件体积。
    Redis 是这样工作的： Redis 会记录上次重写时的 aof 大小。假如 Redis 自启动至今还没有进行过重写，那么启动时 aof 文件的大小会被作为基准值。这个基准值会和当前的 aof 大小进行比较。如果当前 aof 大小超出所设置的增长比例，则会触发重写。另外还需要设置一个最小大小，是为了防止在 aof 很小时就触发重写

    如果设置 auto-aof-rewrite-percentage 为0，则会关闭此重写功能。

45. aof-load-truncated yes

    指Redis在恢复时，会忽略最后一条可能存在问题的指令，默认值yes。即在 aof 写入时，可能存在指令写错的问题(突然断电，写了一半)，这种情况下，yes会log并继续，而no会直接恢复失败。

    7. LUA脚本配置

46. lua-time-limit 5000

    lua 脚本的最大运行时间是需要被严格限制的，单位是毫秒.如果此值设置为0或负数，则既不会有报错也不会有时间限制。

    8. 集群设置

47. cluster-enabled yes

    平常的 Redis 实例不能作为集群的节点，只有作为集群节点启动的实例才可以。下面的配置可以是 Redis 实例作为集群节点启动

48. cluster-config-file nodes-6379.conf

    每个集群节点都有一个集群配置文件，该文件是由集群节点来创建和维护的，不能人工参与。每个集群节点需要不同的配置文件，所以需要保证同一个系统下的集群节点没有重名的配置文件，建议以端口号标记配置文件。

49. cluster-node-timeout 15000

    当节点超时大于 cluster-node-timeout 的时候后，就会被认为宕机了，单位为毫秒

50. cluster-slave-validity-factor 10

    Redis 集群有一种 failover （故障转移）机制，即当主 Redis 宕机之后，会有一个最合适的从 Redis 充当主 Redis 。但是，当从 Redis 的数据“太老”了，与住 Redis 的标准数据偏差很大，为了保证数据一致性， Redis 会放弃 failover 。判别从 Redis 的的数据是不是“太老”有两种方法：
    （1）如果有多个从 Redis 可以接替主 Redis 的工作，则它们会交换信息，选取“最佳复制偏移”（接受了原主 Redis 最多的数据同步）的从 Redis 作为下一任主 Redis 。
    （2）每个从Redis计算与原主Redis最后一次数据同步的时间，当最短的时间间隔大于某个临界点的时候，集群则放弃failover。
    方法（2）当中的临界点可以通过配置调节，临界点的计算规则为：
    (node-timeout * slave-validity-factor)+ repl-ping-slave-period
    如node-timeout为30秒，slave-validity-factor为10秒，repl-ping-slave-period为10秒，当与原主Redis最后一次对话的时间间隔超过310秒的时候，集群就会放弃failover。
    当slave-validity-factor太大会使一台数据“太老”的从Redis充当主Redis；而slave-validity-factor太小可能会造成找不到合适的从Redis继任。

51. cluster-migration-barrier 1

    考虑一种极端情况，集群有一台主Redis和四台从Redis，从Redis全部挂掉，failover机制有可能造成集群只有主Redis而无从Redis的尴尬境况。为了保证集群的名副其实，可以规定，当从Redis少于某个数量时，拒绝执行failover。

52. cluster-require-full-coverage yes

    默认情况下，当集群检测到某个哈希槽（hash slot）没有被覆盖（没有任何节点为此服务）会停止接受查询服务，如果集群部分宕机最终会导致整个集群不可用，当哈希槽重新被全覆盖的时候会自动变为可用。如果希望那些哈希槽被覆盖的集群节点继续接受查询服务，需要将cluster-require-full-coverage设置为no。

    9. 慢日志

53. slowlog-log-slower-than 10000
54. slowlog-max-len 128

    Redis慢日志是指一个系统进行日志查询超过了指定的时长。这个时长不包括IO操作，比如与客户端的交互、发送响应内容等，而仅包括实际执行查询命令的时间。
    针对慢日志可以设置两个参数，一个是执行时长，单位是微秒，另一个是慢日志的长度。当一个新的命令被写入日志时，最老的一条会从命令日志队列中被移除。单位是微秒，即1000000表示一秒。负数则会禁用慢日志功能，而0则表示强制记录每一个命令。

    慢日志最大长度，可以随便填写数值，没有上限，但要注意它会消耗内存。可以使用SLOWLOG RESET来重设这个值。

    10. 延迟监控配置

55. latency-monitor-threshold 0

    Redis的延迟监控子系统会在运行时对不同操作取样，以此来收集与延迟相关的数据，这些信息可以通过LATENCY命令以报表的形式呈现给用户。
    系统只会记录那些执行时间等于或大于atency-monitor-threshold的操作，该值默认为0，代表关闭监控，因为收集延迟数据多少会影响Redis的性能。

    11. 事件通知配置

56. notify-keyspace-events “”
    Redis可以向客户端通知某些事件的发生。
    例如，键空间（keyspace）事件通知如果开启，一个客户端对Database 0中的“foo”键执行了DEL操作，两条信息会通过Pub/Sub发布出去：
    PUBLISHkeyspace@0:foo del
    PUBLISHkeyevent@0:del foo
    可以选择需要发送哪种类型的通知，每种类型用一个字母代表：

    K     键空间事件,发布到“**keyspace@** prefix”频道
    E     键事件, 发布到“ **keyevent@** prefix”频道
    g     通用事件，比如 DEL,EXPIRE, RENAME, ...等操作都属于
    $          String操作
    l     List操作
    s     Set操作
    h     Hash操作
    z     Sorted set操作
    x     过期操作
    e     驱逐操作（因为内存不足数据被删除）
    A     代表“g$lshzxe”的组合, 所以“AKE”可以代表所有事件
    

    notify-keyspace-events配置以上述的字母组合为参数，举例说明：

• notify-keyspace-events Elg
  当有List操作或通用操作，发布通知到“ keyevent@ prefix”频道
• notify-keyspace-events Ex
  当有键的过期操作时，发布通知到“keyevent@0:expired”频道
  默认情况下，notify-keyspace-events的参数为空字符串，代表关闭通知。

  12. 高级配置

1. hash-max-ziplist-entries 512
2. hash-max-ziplist-value 64

   Hash 在条目数量较小的时候会使用一种高效的内存数据结构编码，当超过某个临界点就会采用另一种存储方式。该临界点由这两个配置决定。

3. list-max-ziplist-entries 512
4. list-max-ziplist-value 64

   与Hash类似，较小的List会以一种特殊的编码方式来节省空间，只要List不超过配置的上限。

5. set-max-intset-entries 512

   Set只有在满足下面的条件时才会采用特殊编码方式：Set中存储的恰好都是十进制的整数，而且长度不超过64位（有符号）

6. zset-max-ziplist-entries 128
7. zset-max-ziplist-value 64

   有序集合也会采用特殊编码来节省空间

8. hll-sparse-max-bytes 3000

   RedisHyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定并且很小的。当HyperLogLog用稀疏式表示法时所用内存超过下面的限制，就会转换成稠密式表示，为了更高的内存利用率，官方建议值为3000。

9. activerehashing yes

   Redis 在每 100 毫秒时使用 1 毫秒的 CPU时间来对 Redis 的 hash 表进行重新 hash 。当使用场景中有非常严格的实时性需要，不能够接受 Redis 时不时的对请求有 2 毫秒的延迟的话，把这项配置为 no 。
   如果没有这么严格的实时性要求，可以设置为 yes ，以便能够尽可能快的释放内存。

10. client-output-buffer-limit

    客户端的输出缓冲区的限制，因为某种原因客户端从服务器读取数据的速度不够快，可用于强制断开连接（一个常见的原因是一个发布 / 订阅客户端消费消息的速度无法赶上生产它们的速度）。
    可以三种不同客户端的方式进行设置：
    （1）normal -> 正常客户端
    （2）slave -> slave 和 MONITOR 客户端
    （3）pubsub -> 至少订阅了一个 pubsub channel 或 pattern 的客户端

    一旦达到硬限制客户端会立即断开，或者达到软限制并保持达成的指定秒数（连续）。
    例如，如果硬限制为 32 兆字节和软限制为 16 兆字节 /10 秒，如果输出缓冲区的大小达到 32 兆字节，客户端将会立即断开，客户端达到 16 兆字节和连续超过了限制 10 秒，也将断开连接。
    默认 normal 客户端不做限制，因为他们在一个请求后未要求时（以推的方式）不接收数据，只有异步客户端可能会出现请求数据的速度比它可以读取的速度快的场景。
    把硬限制和软限制都设置为 0 来禁用该特性
    client-output-buffer-limit normal 0 0 0
    client-output-buffer-limit slave 256mb 64mb 60
    client-output-buffer-limit pubsub 32mb 8mb 60

11. hz 10

    Redis 会按照一定的频率来执行后台任务，比如关闭超时的客户端，清除过期键等。不是所有的任务都会按照相同的频率来执行，但 Redis 依照指定的“ Hz ”值来执行检查任务。

12. aof-rewrite-incremental-fsync yes

    aof rewrite 过程中，是否采取增量文件同步策略，默认为“yes”。 rewrite 过程中,每32M数据进行一次文件同步，这样可以减少 aof 大文件写入对磁盘的操作次数。

---

注：本文大部分内容为转载后重排版
原文链接：https://www.jianshu.com/p/f5c9a9738bc2

​