共计 70933 个字符，预计需要花费 178 分钟才能阅读完成。
| # Redis configuration file example. | |
| # Note that in order to read the configuration file, Redis must be | |
| # started with the file path as first argument: | |
| # 为了读取配置文件，Redis 必须以文件门路作为第一个参数启动。# ./redis-server /path/to/redis.conf | |
| # Note on units: when memory size is needed, it is possible to specify | |
| # it in the usual form of 1k 5GB 4M and so forth: | |
| # 对于单元的注意事项：当须要内存大小时，能够用通常的 1k 5GB 4M 等模式指定它 | |
| # 1k => 1000 bytes | |
| # 1kb => 1024 bytes | |
| # 1m => 1000000 bytes | |
| # 1mb => 1024*1024 bytes | |
| # 1g => 1000000000 bytes | |
| # 1gb => 1024*1024*1024 bytes | |
| # | |
| # units are case insensitive so 1GB 1Gb 1gB are all the same. | |
| ######################## INCLUDES ###################### | |
| # Include one or more other config files here. This is useful if you | |
| # have a standard template that goes to all Redis servers but also need | |
| # to customize a few per-server settings. Include files can include | |
| # other files, so use this wisely. | |
| # include 能够蕴含一个或多个其余配置文件，如果您有一个规范模板，可用于所有 Redis 服 | |
| # 务器，而每个服务只需大量的配置，那么这很有用。Include 文件能够蕴含其余文件，# 所以要明智地应用它。# Notice option "include" won't be rewritten by command"CONFIG REWRITE" | |
| # from admin or Redis Sentinel. Since Redis always uses the last processed | |
| # line as value of a configuration directive, you'd better put includes | |
| # at the beginning of this file to avoid overwriting config change at runtime. | |
| # 留神：选项 "include" 不能通过 admin 或者 Redis Sentinel 应用 "CONFIG REWRITE" 命 | |
| # 令重写。# If instead you are interested in using includes to override configuration | |
| # options, it is better to use include as the last line. | |
| # 如果您对应用 include 重写配置选项感兴趣，那么最好应用 include 作为最初一行 | |
| # include /path/to/local.conf | |
| # include /path/to/other.conf | |
| ######################### MODULES ########################### | |
| # Load modules at startup. If the server is not able to load modules | |
| # it will abort. It is possible to use multiple loadmodule directives. | |
| # REDIS 在启动的时候加载自定义模块，如果模块不能加载，REDIS 将启动失败。# 能够配置多个 loadmodule 命令。# loadmodule /path/to/my_module.so | |
| # loadmodule /path/to/other_module.so | |
| ######################## NETWORK ############################# | |
| # By default, if no "bind" configuration directive is specified, Redis listens | |
| # for connections from all the network interfaces available on the server. | |
| # It is possible to listen to just one or multiple selected interfaces using | |
| # the "bind" configuration directive, followed by one or more IP addresses. | |
| # 默认状况下，如果没有指定“bind”配置指令，Redis 将侦听服务器上所有可用 | |
| # 网络地址。应用“bind”配置指令，后跟一个或多个 IP 地址，能够只监听一个或多个 | |
| # 指定的 IP 地址。# Examples: | |
| # | |
| # bind 192.168.1.100 10.0.0.1 | |
| # bind 127.0.0.1 ::1 | |
| # | |
| # ~~~ WARNING ~~~ If the computer running Redis is directly exposed to the | |
| # internet, binding to all the interfaces is dangerous and will expose the | |
| # instance to everybody on the internet. So by default we uncomment the | |
| # following bind directive, that will force Redis to listen only into | |
| # the IPv4 loopback interface address (this means Redis will be able to | |
| # accept connections only from clients running into the same computer it | |
| # is running). | |
| # 如果 Redis 所在的服务器裸露在了互联网上，那么 Redis 监听所有的网络地址 | |
| # 是危险的。互联网上的每个人都能够应用该 Redis 服务。所有默认状况下，咱们 | |
| # 只监听本地 IP 地址，这样，只有本服务器上的利用能力应用该 Redis 服务。# IF YOU ARE SURE YOU WANT YOUR INSTANCE TO LISTEN TO ALL THE INTERFACES | |
| # JUST COMMENT THE FOLLOWING LINE. | |
| # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| bind 127.0.0.1 | |
| # Protected mode is a layer of security protection, in order to avoid that | |
| # Redis instances left open on the internet are accessed and exploited. | |
| # | |
| # When protected mode is on and if: | |
| # | |
| # 1) The server is not binding explicitly to a set of addresses using the | |
| # "bind" directive. | |
| # 2) No password is configured. | |
| # 爱护模块是一个平安保护层，目标是防止在互联网上裸露的 Redis 服务被 | |
| # 利用和拜访。在上面状况下时，保护模式被开启：# 1：没有应用“bind”指令显式绑定到一组地址 | |
| # 2：没有配置拜访明码 | |
| # The server only accepts connections from clients connecting from the | |
| # IPv4 and IPv6 loopback addresses 127.0.0.1 and ::1, and from Unix domain | |
| # sockets. | |
| # | |
| # By default protected mode is enabled. You should disable it only if | |
| # you are sure you want clients from other hosts to connect to Redis | |
| # even if no authentication is configured, nor a specific set of interfaces | |
| # are explicitly listed using the "bind" directive. | |
| #默认状况下，已启用保护模式。只有当您确定心愿其余主机的客户机连贯到 Redis 时，# 才应该禁用它，即便没有配置身份验证，也没有应用“bind”指令显式列出一组 | |
| # 特定的网络 IP 地址。protected-mode yes | |
| # Accept connections on the specified port, default is 6379 (IANA #815344). | |
| # If port 0 is specified Redis will not listen on a TCP socket. | |
| # 在指定端口上承受连贯。默认端口是 6379. | |
| # 如果端口指定为 0，将不再承受 TCP 连贯。port 6379 | |
| # TCP listen() backlog. | |
| # | |
| # In high requests-per-second environments you need an high backlog in order | |
| # to avoid slow clients connections issues. Note that the Linux kernel | |
| # will silently truncate it to the value of /proc/sys/net/core/somaxconn so | |
| # make sure to raise both the value of somaxconn and tcp_max_syn_backlog | |
| # in order to get the desired effect. | |
| # 在每秒申请数高的环境中，能够配置一个高 tcp-backlog 值，# 从而防止客户机连贯速度慢的问题，请留神，Linux 内核将静默地将其 | |
| # 截断为 /proc/sys/net/core/somaxconn 的值，因而请确保同时 | |
| # 进步 somaxconn 和 tcp_max_syn_backlog 的值，以取得所需的成果。tcp-backlog 511 | |
| # Unix socket. | |
| # | |
| # Specify the path for the Unix socket that will be used to listen for | |
| # incoming connections. There is no default, so Redis will not listen | |
| # on a unix socket when not specified. | |
| # 指定将用于侦听传入连贯的 Unix 套接字的门路。没有默认值，# 因而未指定时，Redis 将不会侦听 unix 套接字 | |
| # unixsocket /tmp/redis.sock | |
| # unixsocketperm 700 | |
| # Close the connection after a client is idle for N seconds (0 to disable) | |
| timeout 0 | |
| # TCP keepalive. | |
| # | |
| # If non-zero, use SO_KEEPALIVE to send TCP ACKs to clients in absence | |
| # of communication. This is useful for two reasons: | |
| # | |
| # 1) Detect dead peers. | |
| # 2) Take the connection alive from the point of view of network | |
| # equipment in the middle. | |
| # 如果不为 0，在客户端离线状况下，应用 SO_KEEPALIVE 来发送 TCP | |
| # 应答音讯。这样做有 2 个目标：# 1：检测死机 | |
| # 2：以网络中间件形式来对待网络 | |
| # On Linux, the specified value (in seconds) is the period used to send ACKs. | |
| # Note that to close the connection the double of the time is needed. | |
| # On other kernels the period depends on the kernel configuration. | |
| # 在 Linux 零碎，该指定值（以秒为单位）是发送确认的周期。# 须要留神的是，敞开连贯须要破费双倍的工夫。# 在其它内核上，周期依赖于内核配置。# A reasonable value for this option is 300 seconds, which is the new | |
| # Redis default starting with Redis 3.2.1. | |
| # 该选项的正当值是 300 秒。这是从 Redis 3.2.1 开始的新 Redis 默认值 | |
| tcp-keepalive 300 | |
| ##################### TLS/SSL ######################## | |
| # By default, TLS/SSL is disabled. To enable it, the "tls-port" configuration | |
| # directive can be used to define TLS-listening ports. To enable TLS on the | |
| # default port, use: | |
| # 默认状况下，TLS/SSL 是禁用的。如果须要启动，配置 tls-port 来定义 TLS | |
| # 监听段。能够应用上面配置来启动 TLS。# port 0 | |
| # tls-port 6379 | |
| # Configure a X.509 certificate and private key to use for authenticating the | |
| # server to connected clients, masters or cluster peers. These files should be | |
| # PEM formatted. | |
| # 配置 X.509 证书和私钥，以用于验证连贯的客户端、主机或群集。# 这些文件应为 PEM 格局。# tls-cert-file redis.crt | |
| # tls-key-file redis.key | |
| # Configure a DH parameters file to enable Diffie-Hellman (DH) key exchange: | |
| # | |
| # tls-dh-params-file redis.dh | |
| # Configure a CA certificate(s) bundle or directory to authenticate TLS/SSL | |
| # clients and peers. Redis requires an explicit configuration of at least one | |
| # of these, and will not implicitly use the system wide configuration. | |
| # | |
| # tls-ca-cert-file ca.crt | |
| # tls-ca-cert-dir /etc/ssl/certs | |
| # By default, clients (including replica servers) on a TLS port are required | |
| # to authenticate using valid client side certificates. | |
| # | |
| # It is possible to disable authentication using this directive. | |
| # | |
| # tls-auth-clients no | |
| # By default, a Redis replica does not attempt to establish a TLS connection | |
| # with its master. | |
| # | |
| # Use the following directive to enable TLS on replication links. | |
| # | |
| # tls-replication yes | |
| # By default, the Redis Cluster bus uses a plain TCP connection. To enable | |
| # TLS for the bus protocol, use the following directive: | |
| # | |
| # tls-cluster yes | |
| ######################## GENERAL ############################## | |
| # By default Redis does not run as a daemon. Use 'yes' if you need it. | |
| # Note that Redis will write a pid file in /var/run/redis.pid when daemonized. | |
| # 默认状况下，Redis 并不是守护过程。如果须要是守护过程，请配置为 yes. | |
| # 如果是守护过程，Redis 会写一个 PID 文件：/var/run/redis.pid | |
| daemonize no | |
| # If you run Redis from upstart or systemd, Redis can interact with your | |
| # supervision tree. Options: | |
| # 能够通过 upstart 和 systemd 治理 Redis 守护过程 | |
| # supervised no - no supervision interaction | |
| # supervised no - 无监督互动 | |
| # supervised upstart - signal upstart by putting Redis into SIGSTOP mode | |
| # supervised upstart - 通过将 Redis 置于 SIGSTOP 模式发出信号 | |
| # supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET | |
| # supervised systemd - signal systemd 将 READY = 1 写入 $ NOTIFY_SOCKET | |
| # supervised auto - detect upstart or systemd method based on | |
| # UPSTART_JOB or NOTIFY_SOCKET environment variables | |
| # supervised auto - 检测 upstart 或 systemd 办法基于 UPSTART_JOB | |
| # 或 NOTIFY_SOCKET 环境变量 | |
| # Note: these supervision methods only signal "process is ready." | |
| # They do not enable continuous liveness pings back to your supervisor. | |
| supervised no | |
| # If a pid file is specified, Redis writes it where specified at startup | |
| # and removes it at exit. | |
| # 指定 pid 文件。Redis 将在启动的时候写入，退出的时候删除。# When the server runs non daemonized, no pid file is created if none is | |
| # specified in the configuration. When the server is daemonized, the pid file | |
| # is used even if not specified, defaulting to "/var/run/redis.pid". | |
| # 如果 Reids 是非守护过程，如果没有配置 pid 文件，那么就不会产生 pid 文件。# 如果是守护过程，即便没有配置 pid 文件，也会创立 pid 文件。默认门路 | |
| # 是 /var/run/redis.pid | |
| # Creating a pid file is best effort: if Redis is not able to create it | |
| # nothing bad happens, the server will start and run normally. | |
| # 创立一个 pid 文件是最好的办法：如果 Redis 不能创立它，# 那么不会有什么不好的事件产生，服务器将失常启动和运行。pidfile /var/run/redis_6379.pid | |
| # Specify the server verbosity level. 指定日志级别 | |
| # This can be one of: | |
| # debug (a lot of information, useful for development/testing) | |
| # verbose (many rarely useful info, but not a mess like the debug level) | |
| # notice (moderately verbose, what you want in production probably) | |
| # warning (only very important / critical messages are logged) | |
| loglevel notice | |
| # Specify the log file name. Also the empty string can be used to force | |
| # Redis to log on the standard output. Note that if you use standard | |
| # output for logging but daemonize, logs will be sent to /dev/null | |
| # 指定日志文件名。也能够应用空字符串强制 Redis 应用日志规范输入。# 请留神，如果您应用规范输入进行日志记录，然而 daemonize，# 日志将被发送到 /dev/null | |
| logfile ""# To enable logging to the system logger, just set'syslog-enabled' to yes, | |
| # and optionally update the other syslog parameters to suit your needs. | |
| # 如果须要打印日志到操作系统日志，配置 syslog-enabled 为 yes。# 并依据须要更新其余 syslog 参数 | |
| # syslog-enabled no | |
| # Specify the syslog identity. 指定系统日志标识 | |
| # syslog-ident redis | |
| # Specify the syslog facility. Must be USER or between LOCAL0-LOCAL7. | |
| # 指定日志日志设置，必须是 USER 或者是 LOCAL0 到 LOCAL7。# syslog-facility local0 | |
| # 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 | |
| # 设置数据库数量。默认数据是 DB 0。能够在连贯 redis 的时候抉择一个不同的 | |
| # 数据库应用 SELECT <dbid>。dbid 是一个数字基于 0 到 'databases'-1。databases 16 | |
| # By default Redis shows an ASCII art logo only when started to log to the | |
| # standard output and if the standard output is a TTY. Basically this means | |
| # that normally a logo is displayed only in interactive sessions. | |
| # 默认状况下，只有在 TTY 规范日志输入的状况下，能力打印 LOGO。# However it is possible to force the pre-4.0 behavior and always show a | |
| # ASCII art logo in startup logs by setting the following option to yes. | |
| # 如果想要强制在启动的时候打印 LOGO，配置 always-show-logo 为 yes | |
| always-show-logo yes | |
| ######################## SNAPSHOTTING ######################### | |
| # | |
| # Save the DB on disk: 保留 DB 到磁盘 | |
| # | |
| # save <seconds> <changes> | |
| # | |
| # Will save the DB if both the given number of seconds and the given | |
| # number of write operations against the DB occurred. | |
| # 在指定秒数 和 指定写入数据的次数共事满足的状况下，将保留 DB 到磁盘 | |
| # | |
| # In the example below the behaviour will be to save: | |
| # after 900 sec (15 min) if at least 1 key changed | |
| # after 300 sec (5 min) if at least 10 keys changed | |
| # after 60 sec if at least 10000 keys changed | |
| # | |
| # Note: you can disable saving completely by commenting out all "save" lines. | |
| # 如果禁用保留，通过正文 save 配置行 | |
| # It is also possible to remove all the previously configured save | |
| # points by adding a save directive with a single empty string argument | |
| # like in the following example: | |
| # 还能够通过增加带有单个空字符串参数的 save 指令来删除所有先前配置的存储点 | |
| # save "" | |
| save 900 1 # 900 秒内至多 1 次写操作 | |
| save 300 10 # 300 秒内至多 10 次写操作 | |
| save 60 10000 # 60 秒内至多 10000 次写操作 | |
| # By default Redis will stop accepting writes if RDB snapshots are enabled | |
| # (at least one save point) and the latest background save failed. | |
| # This will make the user aware (in a hard way) that data is not persisting | |
| # on disk properly, otherwise chances are that no one will notice and some | |
| # disaster will happen. | |
| # 默认状况下，如果启用了 RDB 快照（至多有一个保留点），并且最新的后盾保留失败，# 则 Redis 将进行承受写入。这将使用户意识到（以一种硬的形式）数据没有正确地 | |
| # 保留在磁盘上，否则很可能没有人会留神到，并且会产生一些劫难。# | |
| # If the background saving process will start working again Redis will | |
| # automatically allow writes again. | |
| # 如果后盾保留过程从新开始工作，Redis 将主动容许再次写入。# However if you have setup your proper monitoring of the Redis server | |
| # and persistence, you may want to disable this feature so that Redis will | |
| # continue to work as usual even if there are problems with disk, | |
| # permissions, and so forth. | |
| # 然而，如果您曾经设置了对 Redis 服务器和持久性的适当监督，那么您可能心愿禁用此性能，# 以便即便磁盘、权限等呈现问题，Redis 也将持续失常工作。stop-writes-on-bgsave-error yes | |
| # Compress string objects using LZF when dump .rdb databases? | |
| # For default that's set to'yes'as it's almost always a win. | |
| # If you want to save some CPU in the saving child set it to 'no' but | |
| # the dataset will likely be bigger if you have compressible values or keys. | |
| # 在转储.rdb 数据库时应用 LZF 压缩字符串对象？默认设置为“是”，因为这简直总是一场胜利。# 如果您想在 saving 子过程中保留一些 CPU，请将其设置为“no”，但如果您有可压缩的值或键，# 则数据集可能会更大。rdbcompression yes | |
| # Since version 5 of RDB a CRC64 checksum is placed at the end of the file. | |
| # This makes the format more resistant to corruption but there is a performance | |
| # hit to pay (around 10%) when saving and loading RDB files, so you can disable it | |
| # for maximum performances. | |
| # 从 RDB 的版本 5 开始，CRC64 校验和被放在文件的开端，这能避免文件格式损坏，# 然而在保留和加载 RDB 文件时，会有一个性能损失（大概 10%），#因而您能够禁用它以取得最大的性能 | |
| # RDB files created with checksum disabled have a checksum of zero that will | |
| # tell the loading code to skip the check. | |
| # 在禁用校验和的状况下创立的 RDB 文件的校验和为零，这将通知加载代码跳过查看。rdbchecksum yes | |
| # The filename where to dump the DB DB 快照到磁盘的文件名 | |
| dbfilename dump.rdb | |
| # Remove RDB files used by replication in instances without persistence | |
| # enabled. By default this option is disabled, however there are environments | |
| # where for regulations or other security concerns, RDB files persisted on | |
| # disk by masters in order to feed replicas, or stored on disk by replicas | |
| # in order to load them for the initial synchronization, should be deleted | |
| # ASAP. Note that this option ONLY WORKS in instances that have both AOF | |
| # and RDB persistence disabled, otherwise is completely ignored. | |
| # 在没有启用持久性的实例中删除复制应用的 RDB 文件。默认状况下，# 此选项处于禁用状态。然而，在某些环境中，出于治理法规或其余平安思考，# 应尽快删除主服务器在磁盘上保留的 RDB 文件，以便向正本提供数据，# 或通过正本存储在磁盘上以加载这些文件以进行初始同步。#请留神，此选项仅实用于同时禁用 AOF 和 RDB 持久性的实例，否则将齐全疏忽。# An alternative (and sometimes better) way to obtain the same effect is | |
| # to use diskless replication on both master and replicas instances. However | |
| # in the case of replicas, diskless is not always an option. | |
| # 另一种（有时更好）的办法是在主实例和正本实例上应用无盘复制。# 然而，对于正本，无盘并不总是一个选项。rdb-del-sync-files no | |
| # The working directory. 工作目录 | |
| # | |
| # The DB will be written inside this directory, with the filename specified | |
| # above using the 'dbfilename' configuration directive. | |
| # 数据库将写入此目录中，并应用下面应用“dbfilename”配置指令指定的文件名。# The Append Only File will also be created inside this directory. | |
| # AOF 文件也是写在此目录 | |
| # Note that you must specify a directory here, not a file name. 这里必须是目录，而不是文件名 | |
| dir ./ | |
| ################################# REPLICATION ################################# | |
| # Master-Replica replication. Use replicaof to make a Redis instance a copy of | |
| # another Redis server. A few things to understand ASAP about Redis replication. | |
| # 应用 replicaof 使 Redis 实例成为另一个 Redis 服务器的正本。# 对于 Redis 复制，须要尽快理解一些事件。# +------------------+ +---------------+ | |
| # | Master | ---> | Replica | | |
| # | (receive writes) | | (exact copy) | | |
| # +------------------+ +---------------+ | |
| # | |
| # 1) Redis replication is asynchronous, but you can configure a master to | |
| # stop accepting writes if it appears to be not connected with at least | |
| # a given number of replicas. | |
| # Redis 复制是异步的，然而您能够配置一个主服务器，# 使其进行承受写入，如果它仿佛没有连贯到至多给定数量的正本。# 2) Redis replicas are able to perform a partial resynchronization with the | |
| # master if the replication link is lost for a relatively small amount of | |
| # time. You may want to configure the replication backlog size (see the next | |
| # sections of this file) with a sensible value depending on your needs. | |
| # 如果复制链接失落的工夫绝对较短，则 Redis 正本可能与主服务器执行局部从新同步。# 依据您的须要，您可能须要应用一个正当的值 | |
| # 来配置复制 backlog 大小（请参阅此文件的下一节）。# 3) Replication is automatic and does not need user intervention. After a | |
| # network partition replicas automatically try to reconnect to masters | |
| # and resynchronize with them. | |
| # 复制是主动的，不须要用户干涉。在网络分区之后，# 复制正本会主动尝试从新连贯到主机并与它们从新同步。# replicaof <masterip> <masterport> | |
| # If the master is password protected (using the "requirepass" configuration | |
| # directive below) it is possible to tell the replica to authenticate before | |
| # starting the replication synchronization process, otherwise the master will | |
| # refuse the replica request. | |
| # 如果主机受密码保护（应用上面的“requirepass”配置指令），# 则能够在开始复制同步过程之前告诉正本进行身份验证，# 否则主服务器将回绝正本申请。# masterauth <master-password> | |
| # | |
| # However this is not enough if you are using Redis ACLs (for Redis version | |
| # 6 or greater), and the default user is not capable of running the PSYNC | |
| # command and/or other commands needed for replication. In this case it's | |
| # better to configure a special user to use with replication, and specify the | |
| # masteruser configuration as such: | |
| # 然而，如果您应用的是 Redis acl（用于 Redis version 6 或更高版本）# 并且默认用户无奈运行 PSYNC 命令和 / 或复制所需的其余命令，那么这还不够。# 在这种状况下，最好配置一个用于复制的非凡用户，并按如下形式指定主用户配置：# masteruser <username> | |
| # | |
| # When masteruser is specified, the replica will authenticate against its | |
| # master using the new AUTH form: AUTH <username> <password>. | |
| # 指定 masteruser 后，复制正本将应用新的身份验证模式 | |
| # AUTH<username><password> 对其主服务器进行身份验证。# When a replica loses its connection with the master, or when the replication | |
| # is still in progress, the replica can act in two different ways: | |
| # 当复制正本失去与主服务器的连贯，或复制仍在进行时，# 复制正本能够以两种不同的形式操作：# 1) if replica-serve-stale-data is set to 'yes' (the default) the replica will | |
| # still reply to client requests, possibly with out of date data, or the | |
| # data set may just be empty if this is the first synchronization. | |
| # 如果 replica-serve-stale-data 设置为“yes”（默认值），则复制正本仍将响应客户端申请 | |
| # 数据可能已过期，或者如果这是第一次同步，则数据集可能为空。# 2) if replica-serve-stale-data is set to 'no' the replica will reply with | |
| # an error "SYNC with master in progress" to all the kind of commands | |
| # but to INFO, replicaOF, AUTH, PING, SHUTDOWN, REPLCONF, ROLE, CONFIG, | |
| # SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, PUBLISH, PUBSUB, | |
| # COMMAND, POST, HOST: and LATENCY. | |
| # 如果 replica serve stale data 设置为“no”，复制正本将对所有类型的命令回答 | |
| # 谬误“SYNC with master in progress”，除了 INFO，AUTH 等命令外 | |
| replica-serve-stale-data yes | |
| # You can configure a replica instance to accept writes or not. Writing against | |
| # a replica instance may be useful to store some ephemeral data (because data | |
| # written on a replica will be easily deleted after resync with the master) but | |
| # may also cause problems if clients are writing to it because of a | |
| # misconfiguration. | |
| # 您能够将正本实例配置为承受或不承受写入。针对正本实例的写入对于存储 | |
| # 一些短暂的数据可能很有用（因为在正本上写入的数据在与主服务器从新同步后 | |
| # 很容易被删除 ), 然而如果客户机因为配置谬误而向其写入数据，也可能会导致问题 | |
| # Since Redis 2.6 by default replicas are read-only. | |
| # | |
| # Note: read only replicas are not designed to be exposed to untrusted clients | |
| # on the internet. It's just a protection layer against misuse of the instance. | |
| # Still a read only replica exports by default all the administrative commands | |
| # such as CONFIG, DEBUG, and so forth. To a limited extent you can improve | |
| # security of read only replicas using 'rename-command' to shadow all the | |
| # administrative / dangerous commands. | |
| # 请留神，复制正本不可在 internet 上公开。它只是避免实例被滥用的保护层。# 默认状况下，只读正本仍会导出所有治理命令，如 CONFIG、DEBUG 等。# 在肯定水平上，您能够应用“rename command”来暗藏所有治理 / 危险命令来进步只读正本的安全性。replica-read-only yes | |
| # Replication SYNC strategy: disk or socket. | |
| # 复制同步策略：磁盘或网络。# New replicas and reconnecting replicas that are not able to continue the | |
| # replication process just receiving differences, need to do what is called a | |
| # "full synchronization". An RDB file is transmitted from the master to the | |
| # replicas. | |
| # 新的复制正本和从新连贯的复制正本如果只是接管到差别而无奈持续复制过程，# 则须要执行所谓的“齐全同步”。RDB 文件从主服务器传输到正本。# The transmission can happen in two different ways: | |
| # | |
| # 1) Disk-backed: The Redis master creates a new process that writes the RDB | |
| # file on disk. Later the file is transferred by the parent | |
| # process to the replicas incrementally. | |
| # Redis 主机创立一个新过程, 将 RDB 文件写入磁盘. 稍后, 该文件由父过程以增量形式传输到正本。# 2) Diskless: The Redis master creates a new process that directly writes the | |
| # RDB file to replica sockets, without touching the disk at all. | |
| # Redis master 创立了一个新过程，间接将 RDB 文件写入正本套接字，而不须要接触磁盘。# | |
| # With disk-backed replication, while the RDB file is generated, more replicas | |
| # can be queued and served with the RDB file as soon as the current child | |
| # producing the RDB file finishes its work. With diskless replication instead | |
| # once the transfer starts, new replicas arriving will be queued and a new | |
| # transfer will start when the current one terminates. | |
| # 应用磁盘备份复制，在生成 RDB 文件时，只有以后生成 RDB 文件的子级实现工作，# 就能够将更多正本排入队列并与 RDB 文件一起提供服务。# 应用无盘复制，一旦传输开始，达到的新正本将进入队列，新的传输将在以后复制终止时开始 | |
| # When diskless replication is used, the master waits a configurable amount of | |
| # time (in seconds) before starting the transfer in the hope that multiple | |
| # replicas will arrive and the transfer can be parallelized. | |
| # 当应用无盘复制时，主机在开始传输之前期待一段可配置的工夫（以秒为单位），# 心愿多个正本将达到并且传输能够并行化。# With slow disks and fast (large bandwidth) networks, diskless replication | |
| # works better. 在磁盘速度慢和网络比拟快的状况下，无盘复制比拟适合 | |
| repl-diskless-sync no | |
| # When diskless replication is enabled, it is possible to configure the delay | |
| # the server waits in order to spawn the child that transfers the RDB via socket | |
| # to the replicas. | |
| # 启用无盘复制时，能够配置服务器期待的提早，以便生成通过套接字将 RDB 传输到正本的子工作。# This is important since once the transfer starts, it is not possible to serve | |
| # new replicas arriving, that will be queued for the next RDB transfer, so the | |
| # server waits a delay in order to let more replicas arrive. | |
| # 这一点很重要，因为一旦传输开始，就不可能为达到的新正本提供服务，新正本将排队 | |
| # 期待下一次 RDB 传输，因而服务器会期待一个提早，以便让更多正本达到。# The delay is specified in seconds, and by default is 5 seconds. To disable | |
| # it entirely just set it to 0 seconds and the transfer will start ASAP. | |
| # 提早以秒为单位指定，默认为 5 秒。要齐全禁用它，只需将其设置为 0 秒，传输将尽快开始。repl-diskless-sync-delay 5 | |
| # ----------------------------------------------------------------------------- | |
| # WARNING: RDB diskless load is experimental. Since in this setup the replica | |
| # does not immediately store an RDB on disk, it may cause data loss during | |
| # failovers. RDB diskless load + Redis modules not handling I/O reads may also | |
| # cause Redis to abort in case of I/O errors during the initial synchronization | |
| # stage with the master. Use only if your do what you are doing. | |
| # ----------------------------------------------------------------------------- | |
| # RDB 无盘加载是实验性的。因为在此设置中，复制正本不会立刻在磁盘上存储 RDB，# 因而在故障转移期间可能会导致数据失落。RDB 无盘加载 + 不解决 I / O 读取 | |
| # 的 Redis 模块也可能导致 Redis 在与主机的初始同步阶段呈现 I / O 谬误时停止。# 只在你确定想做的时才应用。# Replica can load the RDB it reads from the replication link directly from the | |
| # socket, or store the RDB to a file and read that file after it was completely | |
| # recived from the master. | |
| # Replica 能够间接从 socket 加载它从复制链接读取的 RDB，或者将 RDB 存储到一个文件中，# 并在齐全从主服务器接管到该文件之后读取该文件。# In many cases the disk is slower than the network, and storing and loading | |
| # the RDB file may increase replication time (and even increase the master's | |
| # Copy on Write memory and salve buffers). | |
| # 在许多状况下，磁盘比网络慢，存储和加载 RDB 文件可能会减少复制工夫 | |
| #（甚至会减少主机的“写入时拷贝”内存和缓冲区）。# However, parsing the RDB file directly from the socket may mean that we have | |
| # to flush the contents of the current database before the full rdb was | |
| # received. For this reason we have the following options: | |
| # 然而，间接从套接字解析 RDB 文件可能意味着咱们必须在收到残缺的 RDB 之前刷 | |
| # 新以后数据库的内容。为此，咱们有以下抉择：# "disabled" - Don't use diskless load (store the rdb file to the disk first) | |
| # "on-empty-db" - Use diskless load only when it is completely safe. | |
| # "swapdb" - Keep a copy of the current db contents in RAM while parsing | |
| # the data directly from the socket. note that this requires | |
| # sufficient memory, if you don't have it, you risk an OOM kill. | |
| repl-diskless-load disabled | |
| # Replicas send PINGs to server in a predefined interval. It's possible to | |
| # change this interval with the repl_ping_replica_period option. The default | |
| # value is 10 seconds. | |
| # 正本以预约义的工夫距离向服务器发送 ping。能够应用 | |
| # repl_ping_replica_period 选项更改此距离。默认值为 10 秒。# repl-ping-replica-period 10 | |
| # The following option sets the replication timeout for: | |
| # | |
| # 1) Bulk transfer I/O during SYNC, from the point of view of replica. | |
| # 2) Master timeout from the point of view of replicas (data, pings). | |
| # 3) Replica timeout from the point of view of masters (REPLCONF ACK pings). | |
| # | |
| # It is important to make sure that this value is greater than the value | |
| # specified for repl-ping-replica-period otherwise a timeout will be detected | |
| # every time there is low traffic between the master and the replica. | |
| # | |
| # repl-timeout 60 | |
| # Disable TCP_NODELAY on the replica socket after SYNC? | |
| # | |
| # If you select "yes" Redis will use a smaller number of TCP packets and | |
| # less bandwidth to send data to replicas. But this can add a delay for | |
| # the data to appear on the replica side, up to 40 milliseconds with | |
| # Linux kernels using a default configuration. | |
| # | |
| # If you select "no" the delay for data to appear on the replica side will | |
| # be reduced but more bandwidth will be used for replication. | |
| # | |
| # By default we optimize for low latency, but in very high traffic conditions | |
| # or when the master and replicas are many hops away, turning this to "yes" may | |
| # be a good idea. | |
| repl-disable-tcp-nodelay no | |
| # Set the replication backlog size. The backlog is a buffer that accumulates | |
| # replica data when replicas are disconnected for some time, so that when a | |
| # replica wants to reconnect again, often a full resync is not needed, but a | |
| # partial resync is enough, just passing the portion of data the replica | |
| # missed while disconnected. | |
| # | |
| # The bigger the replication backlog, the longer the time the replica can be | |
| # disconnected and later be able to perform a partial resynchronization. | |
| # | |
| # The backlog is only allocated once there is at least a replica connected. | |
| # | |
| # repl-backlog-size 1mb | |
| # After a master has no longer connected replicas for some time, the backlog | |
| # will be freed. The following option configures the amount of seconds that | |
| # need to elapse, starting from the time the last replica disconnected, for | |
| # the backlog buffer to be freed. | |
| # | |
| # Note that replicas never free the backlog for timeout, since they may be | |
| # promoted to masters later, and should be able to correctly "partially | |
| # resynchronize" with the replicas: hence they should always accumulate backlog. | |
| # | |
| # A value of 0 means to never release the backlog. | |
| # | |
| # repl-backlog-ttl 3600 | |
| # The replica priority is an integer number published by Redis in the INFO | |
| # output. It is used by Redis Sentinel in order to select a replica to promote | |
| # into a master if the master is no longer working correctly. | |
| # | |
| # A replica with a low priority number is considered better for promotion, so | |
| # for instance if there are three replicas with priority 10, 100, 25 Sentinel | |
| # will pick the one with priority 10, that is the lowest. | |
| # | |
| # However a special priority of 0 marks the replica as not able to perform the | |
| # role of master, so a replica with priority of 0 will never be selected by | |
| # Redis Sentinel for promotion. | |
| # | |
| # By default the priority is 100. | |
| replica-priority 100 | |
| # It is possible for a master to stop accepting writes if there are less than | |
| # N replicas connected, having a lag less or equal than M seconds. | |
| # | |
| # The N replicas need to be in "online" state. | |
| # | |
| # The lag in seconds, that must be <= the specified value, is calculated from | |
| # the last ping received from the replica, that is usually sent every second. | |
| # | |
| # This option does not GUARANTEE that N replicas will accept the write, but | |
| # will limit the window of exposure for lost writes in case not enough replicas | |
| # are available, to the specified number of seconds. | |
| # | |
| # For example to require at least 3 replicas with a lag <= 10 seconds use: | |
| # | |
| # min-replicas-to-write 3 | |
| # min-replicas-max-lag 10 | |
| # | |
| # Setting one or the other to 0 disables the feature. | |
| # | |
| # By default min-replicas-to-write is set to 0 (feature disabled) and | |
| # min-replicas-max-lag is set to 10. | |
| # A Redis master is able to list the address and port of the attached | |
| # replicas in different ways. For example the "INFO replication" section | |
| # offers this information, which is used, among other tools, by | |
| # Redis Sentinel in order to discover replica instances. | |
| # Another place where this info is available is in the output of the | |
| # "ROLE" command of a master. | |
| # | |
| # The listed IP and address normally reported by a replica is obtained | |
| # in the following way: | |
| # | |
| # IP: The address is auto detected by checking the peer address | |
| # of the socket used by the replica to connect with the master. | |
| # | |
| # Port: The port is communicated by the replica during the replication | |
| # handshake, and is normally the port that the replica is using to | |
| # listen for connections. | |
| # | |
| # However when port forwarding or Network Address Translation (NAT) is | |
| # used, the replica may be actually reachable via different IP and port | |
| # pairs. The following two options can be used by a replica in order to | |
| # report to its master a specific set of IP and port, so that both INFO | |
| # and ROLE will report those values. | |
| # | |
| # There is no need to use both the options if you need to override just | |
| # the port or the IP address. | |
| # | |
| # replica-announce-ip 5.5.5.5 | |
| # replica-announce-port 1234 | |
| ########################## SECURITY ############################ | |
| # Warning: since Redis is pretty fast an outside user can try up to | |
| # 1 million passwords per second against a modern box. This means that you | |
| # should use very strong passwords, otherwise they will be very easy to break. | |
| # Note that because the password is really a shared secret between the client | |
| # and the server, and should not be memorized by any human, the password | |
| # can be easily a long string from /dev/urandom or whatever, so by using a | |
| # long and unguessable password no brute force attack will be possible. | |
| # Redis ACL users are defined in the following format: | |
| # | |
| # user <username> ... acl rules ... | |
| # | |
| # For example: | |
| # | |
| # user worker +@list +@connection ~jobs:* on >ffa9203c493aa99 | |
| # | |
| # The special username "default" is used for new connections. If this user | |
| # has the "nopass" rule, then new connections will be immediately authenticated | |
| # as the "default" user without the need of any password provided via the | |
| # AUTH command. Otherwise if the "default" user is not flagged with "nopass" | |
| # the connections will start in not authenticated state, and will require | |
| # AUTH (or the HELLO command AUTH option) in order to be authenticated and | |
| # start to work. | |
| # | |
| # The ACL rules that describe what an user can do are the following: | |
| # | |
| # on Enable the user: it is possible to authenticate as this user. | |
| # off Disable the user: it's no longer possible to authenticate | |
| # with this user, however the already authenticated connections | |
| # will still work. | |
| # +<command> Allow the execution of that command | |
| # -<command> Disallow the execution of that command | |
| # +@<category> Allow the execution of all the commands in such category | |
| # with valid categories are like @admin, @set, @sortedset, ... | |
| # and so forth, see the full list in the server.c file where | |
| # the Redis command table is described and defined. | |
| # The special category @all means all the commands, but currently | |
| # present in the server, and that will be loaded in the future | |
| # via modules. | |
| # +<command>|subcommand Allow a specific subcommand of an otherwise | |
| # disabled command. Note that this form is not | |
| # allowed as negative like -DEBUG|SEGFAULT, but | |
| # only additive starting with "+". | |
| # allcommands Alias for +@all. Note that it implies the ability to execute | |
| # all the future commands loaded via the modules system. | |
| # nocommands Alias for -@all. | |
| # ~<pattern> Add a pattern of keys that can be mentioned as part of | |
| # commands. For instance ~* allows all the keys. The pattern | |
| # is a glob-style pattern like the one of KEYS. | |
| # It is possible to specify multiple patterns. | |
| # allkeys Alias for ~* | |
| # resetkeys Flush the list of allowed keys patterns. | |
| # ><password> Add this passowrd to the list of valid password for the user. | |
| # For example >mypass will add "mypass" to the list. | |
| # This directive clears the "nopass" flag (see later). | |
| # <<password> Remove this password from the list of valid passwords. | |
| # nopass All the set passwords of the user are removed, and the user | |
| # is flagged as requiring no password: it means that every | |
| # password will work against this user. If this directive is | |
| # used for the default user, every new connection will be | |
| # immediately authenticated with the default user without | |
| # any explicit AUTH command required. Note that the "resetpass" | |
| # directive will clear this condition. | |
| # resetpass Flush the list of allowed passwords. Moreover removes the | |
| # "nopass" status. After "resetpass" the user has no associated | |
| # passwords and there is no way to authenticate without adding | |
| # some password (or setting it as "nopass" later). | |
| # reset Performs the following actions: resetpass, resetkeys, off, | |
| # -@all. The user returns to the same state it has immediately | |
| # after its creation. | |
| # | |
| # ACL rules can be specified in any order: for instance you can start with | |
| # passwords, then flags, or key patterns. However note that the additive | |
| # and subtractive rules will CHANGE MEANING depending on the ordering. | |
| # For instance see the following example: | |
| # | |
| # user alice on +@all -DEBUG ~* >somepassword | |
| # | |
| # This will allow "alice" to use all the commands with the exception of the | |
| # DEBUG command, since +@all added all the commands to the set of the commands | |
| # alice can use, and later DEBUG was removed. However if we invert the order | |
| # of two ACL rules the result will be different: | |
| # | |
| # user alice on -DEBUG +@all ~* >somepassword | |
| # | |
| # Now DEBUG was removed when alice had yet no commands in the set of allowed | |
| # commands, later all the commands are added, so the user will be able to | |
| # execute everything. | |
| # | |
| # Basically ACL rules are processed left-to-right. | |
| # | |
| # For more information about ACL configuration please refer to | |
| # the Redis web site at https://redis.io/topics/acl | |
| # ACL LOG | |
| # | |
| # The ACL Log tracks failed commands and authentication events associated | |
| # with ACLs. The ACL Log is useful to troubleshoot failed commands blocked | |
| # by ACLs. The ACL Log is stored in memory. You can reclaim memory with | |
| # ACL LOG RESET. Define the maximum entry length of the ACL Log below. | |
| acllog-max-len 128 | |
| # Using an external ACL file | |
| # | |
| # Instead of configuring users here in this file, it is possible to use | |
| # a stand-alone file just listing users. The two methods cannot be mixed: | |
| # if you configure users here and at the same time you activate the exteranl | |
| # ACL file, the server will refuse to start. | |
| # | |
| # The format of the external ACL user file is exactly the same as the | |
| # format that is used inside redis.conf to describe users. | |
| # | |
| # aclfile /etc/redis/users.acl | |
| # IMPORTANT NOTE: starting with Redis 6 "requirepass" is just a compatiblity | |
| # layer on top of the new ACL system. The option effect will be just setting | |
| # the password for the default user. Clients will still authenticate using | |
| # AUTH <password> as usually, or more explicitly with AUTH default <password> | |
| # if they follow the new protocol: both will work. | |
| # | |
| # requirepass foobared | |
| # Command renaming (DEPRECATED). | |
| # | |
| # ------------------------------------------------------------------------ | |
| # WARNING: avoid using this option if possible. Instead use ACLs to remove | |
| # commands from the default user, and put them only in some admin user you | |
| # create for administrative purposes. | |
| # ------------------------------------------------------------------------ | |
| # | |
| # It is possible to change the name of dangerous commands in a shared | |
| # environment. For instance the CONFIG command may be renamed into something | |
| # hard to guess so that it will still be available for internal-use tools | |
| # but not available for general clients. | |
| # | |
| # Example: | |
| # | |
| # rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 | |
| # | |
| # It is also possible to completely kill a command by renaming it into | |
| # an empty string: | |
| # | |
| # rename-command CONFIG "" | |
| # | |
| # Please note that changing the name of commands that are logged into the | |
| # AOF file or transmitted to replicas may cause problems. | |
| ################################### CLIENTS #################################### | |
| # Set the max number of connected clients at the same time. By default | |
| # this limit is set to 10000 clients, however if the Redis server is not | |
| # able to configure the process file limit to allow for the specified limit | |
| # the max number of allowed clients is set to the current file limit | |
| # minus 32 (as Redis reserves a few file descriptors for internal uses). | |
| # 设置同时连贯的客户端的最大数量。默认状况下，此限度设置为 10000 个客户端，# 然而如果 Redis 服务器无奈配置过程文件限度以容许指定的限度，则容许的最大客户端 | |
| # 数将设置为以后文件限度减去 32（因为 Redis 保留了一些文件描述符供外部应用）。# Once the limit is reached Redis will close all the new connections sending | |
| # an error 'max number of clients reached'. | |
| # 一旦达到限度，Redis 将敞开所有新连贯，并发送谬误“max number of clients reached”。# IMPORTANT: When Redis Cluster is used, the max number of connections is also | |
| # shared with the cluster bus: every node in the cluster will use two | |
| # connections, one incoming and another outgoing. It is important to size the | |
| # limit accordingly in case of very large clusters. | |
| # 当应用 Redis 集群时，最大连接数也与集群总线共享：集群中的每个节点将应用两个连贯，# 一个传入，另一个传出。在十分大的簇的状况下，相应地调整限度的大小是很重要的。# maxclients 10000 | |
| ################### MEMORY MANAGEMENT ######################## | |
| # Set a memory usage limit to the specified amount of bytes. | |
| # When the memory limit is reached Redis will try to remove keys | |
| # according to the eviction policy selected (see maxmemory-policy). | |
| # | |
| # If Redis can't remove keys according to the policy, or if the policy is | |
| # set to 'noeviction', Redis will start to reply with errors to commands | |
| # that would use more memory, like SET, LPUSH, and so on, and will continue | |
| # to reply to read-only commands like GET. | |
| # 将内存应用限度设置为指定的字节数。当达到内存限度时，Redis 将依据所选的逐出 | |
| # 策略删除密钥（请参阅 maxmemory 策略）。如果 Redis 无奈依据策略删除密钥，# 或者如果策略设置为“noeviction”，Redis 将开始对应用更多内存的命令（如 set、# LPUSH 等）进行谬误应答，并持续回复 GET 等只读命令。# This option is usually useful when using Redis as an LRU or LFU cache, or to | |
| # set a hard memory limit for an instance (using the 'noeviction' policy). | |
| # 当将 Redis 用作 LRU 或 LFU 缓存时，或者设置实例的硬内存限度（应用“noeviction”策略）# 时，此选项通常很有用。# WARNING: If you have replicas attached to an instance with maxmemory on, | |
| # the size of the output buffers needed to feed the replicas are subtracted | |
| # from the used memory count, so that network problems / resyncs will | |
| # not trigger a loop where keys are evicted, and in turn the output | |
| # buffer of replicas is full with DELs of keys evicted triggering the deletion | |
| # of more keys, and so forth until the database is completely emptied. | |
| # 如果将正本附加到启用了 maxmemory 的实例，则将从已用内存计数中减去提供正本所需 | |
| # 的输入缓冲区的大小，这样网络问题 / 从新同步将不会触发一个循环，# 在循环中退出密钥，而正本的输入缓冲区将充斥被发出的密钥的增量, | |
| # 从而触发删除操作直到数据库齐全清空。# In short... if you have replicas attached it is suggested that you set a lower | |
| # limit for maxmemory so that there is some free RAM on the system for replica | |
| # output buffers (but this is not needed if the policy is 'noeviction'). | |
| # | |
| # maxmemory <bytes> | |
| # MAXMEMORY POLICY: how Redis will select what to remove when maxmemory | |
| # is reached. You can select one from the following behaviors: | |
| # 当达到 maxmemory 时，Redis 将如何抉择要删除的内容。# volatile-lru -> Evict using approximated LRU, only keys with an expire set. | |
| # 对设置了过期工夫的 KEY，应用 LRU 淘汰策略 | |
| # allkeys-lru -> Evict any key using approximated LRU. 所有 KEY 都采纳 LRU 淘汰策略 | |
| # volatile-lfu -> Evict using approximated LFU, only keys with an expire set. | |
| # 对设置了过期工夫的 KEY，应用 LFU 淘汰策略 | |
| # allkeys-lfu -> Evict any key using approximated LFU. 所有 KEY 都采纳 LFU 淘汰策略 | |
| # volatile-random -> Remove a random key having an expire set. | |
| # 对设置了有效期的 KEY，随机删除一个 KEY | |
| # allkeys-random -> Remove a random key, any key. 随机删除 | |
| # volatile-ttl -> Remove the key with the nearest expire time (minor TTL) | |
| # 删除靠近过期工夫的 KEY | |
| # noeviction -> Don't evict anything, just return an error on write operations. | |
| # 不淘汰数据，对写操作返回谬误 | |
| # LRU means Least Recently Used | |
| # LFU means Least Frequently Used | |
| # | |
| # Both LRU, LFU and volatile-ttl are implemented using approximated | |
| # randomized algorithms. | |
| # | |
| # Note: with any of the above policies, Redis will return an error on write | |
| # operations, when there are no suitable keys for eviction. | |
| # 应用以上任何一种策略，当没有适合的密钥进行逐出时，Redis 将在写操作时返回谬误 | |
| # At the date of writing these commands are: set setnx setex append | |
| # incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd | |
| # sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby | |
| # zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby | |
| # getset mset msetnx exec sort | |
| # | |
| # The default is: | |
| # | |
| # maxmemory-policy noeviction | |
| # LRU, LFU and minimal TTL algorithms are not precise algorithms but approximated | |
| # algorithms (in order to save memory), so you can tune it for speed or | |
| # accuracy. For default Redis will check five keys and pick the one that was | |
| # used less recently, you can change the sample size using the following | |
| # configuration directive. | |
| # LRU、LFU 和 minimal TTL 算法不是准确算法，而是近似算法（为了节俭内存），# 因而您能够依据速度或精度对其进行调整。默认状况下 Redis 将查看五个键并抉择 | |
| # 最近应用较少的键，能够应用以下配置指令更改样本大小。# The default of 5 produces good enough results. 10 Approximates very closely | |
| # true LRU but costs more CPU. 3 is faster but not very accurate. | |
| # 默认值为 5 会产生足够好的后果。10 靠近实在的 LRU，但占用更多的 CPU。3 更快，但不是很精确。# maxmemory-samples 5 | |
| # Starting from Redis 5, by default a replica will ignore its maxmemory setting | |
| # (unless it is promoted to master after a failover or manually). It means | |
| # that the eviction of keys will be just handled by the master, sending the | |
| # DEL commands to the replica as keys evict in the master side. | |
| # 默认状况下，复制正本将疏忽其 maxmemory 设置（除非在故障转移后或手动将其降级为 master）。# 这意味着密钥的发出将由主服务器解决，将 DEL 命令作为主机端的密钥发出发送到正本。# This behavior ensures that masters and replicas stay consistent, and is usually | |
| # what you want, however if your replica is writable, or you want the replica | |
| # to have a different memory setting, and you are sure all the writes performed | |
| # to the replica are idempotent, then you may change this default (but be sure | |
| # to understand what you are doing). | |
| # 此行为可确保主正本和正本保持一致，并且通常是您想要的，然而，如果您的复制正本是可写的，# 或者您心愿复制正本具备不同的内存设置，并且您确定对正本执行 | |
| # 的所有写操作都是幂等的，则能够更改此默认值（但肯定要理解您正在做什么）。# Note that since the replica by default does not evict, it may end using more | |
| # memory than the one set via maxmemory (there are certain buffers that may | |
| # be larger on the replica, or data structures may sometimes take more memory | |
| # and so forth). So make sure you monitor your replicas and make sure they | |
| # have enough memory to never hit a real out-of-memory condition before the | |
| # master hits the configured maxmemory setting. | |
| # 请留神，因为复制正本在默认状况下不会逐出，因而它可能会应用比通过 maxmemory 设置的 | |
| # 内存更多的内存（正本上有一些缓冲区可能更大，或者数据结构有时可能占用更多内存等等）。# 因而，请确保您监督您的正本，并确保它们有足够的内存，在主机 | |
| # 命中配置的 maxmemory 设置之前，它们不会呈现内存不足的状况。# replica-ignore-maxmemory yes | |
| # Redis reclaims expired keys in two ways: upon access when those keys are | |
| # found to be expired, and also in background, in what is called the | |
| # "active expire key". The key space is slowly and interactively scanned | |
| # looking for expired keys to reclaim, so that it is possible to free memory | |
| # of keys that are expired and will never be accessed again in a short time. | |
| # Redis 通过两种形式回收过期的密钥：当发现这些密钥过期时在拜访时，以及在后盾，即所 | |
| # 谓的“流动过期密钥”。密钥空间被迟缓地交互扫描，寻找过期的密钥以回收，这样就能够 | |
| # 开释过期密钥的内存，而这些密钥在短时间内将永远不会被拜访。# The default effort of the expire cycle will try to avoid having more than | |
| # ten percent of expired keys still in memory, and will try to avoid consuming | |
| # more than 25% of total memory and to add latency to the system. However | |
| # it is possible to increase the expire "effort" that is normally set to | |
| # "1", to a greater value, up to the value "10". At its maximum value the | |
| # system will use more CPU, longer cycles (and technically may introduce | |
| # more latency), and will tollerate less already expired keys still present | |
| # in the system. It's a tradeoff betweeen memory, CPU and latecy. | |
| # expire 循环的默认工作将尽量避免超过 10% 的过期密钥仍在内存中，并将尽量避免耗费超过 25% 的 | |
| # 总内存，并减少零碎的提早。然而，可将设置为“1”的 expire“effort”减少到更大的值，直到值“10”。# 在其最大值时，零碎将应用更多的 CPU、更长的周期（从技术上讲可能会引入更多的提早），# 并且可能接受较少的已过期密钥 | |
| # active-expire-effort 1 | |
| ############################# LAZY FREEING ############################## | |
| # Redis has two primitives to delete keys. One is called DEL and is a blocking | |
| # deletion of the object. It means that the server stops processing new commands | |
| # in order to reclaim all the memory associated with an object in a synchronous | |
| # way. If the key deleted is associated with a small object, the time needed | |
| # in order to execute the DEL command is very small and comparable to most other | |
| # O(1) or O(log_N) commands in Redis. However if the key is associated with an | |
| # aggregated value containing millions of elements, the server can block for | |
| # a long time (even seconds) in order to complete the operation. | |
| # Redis 有两种形式来删除密钥。一种叫做 DEL，是对对象的阻塞性删除。这意味着服务器进行 | |
| # 解决新命令，以便以同步形式回收与对象关联的所有内存。如果删除的密钥与一个小对象关联，# 则执行 DEL 命令所需的工夫十分小，与 Redis 中大多数其余 O（1）或 O（log_N）命令相似。# 然而，如果密钥与蕴含数百万个元素的值相关联，则服务器会进行比拟长的工夫以实现删除操作 | |
| # For the above reasons Redis also offers non blocking deletion primitives | |
| # such as UNLINK (non blocking DEL) and the ASYNC option of FLUSHALL and | |
| # FLUSHDB commands, in order to reclaim memory in background. Those commands | |
| # are executed in constant time. Another thread will incrementally free the | |
| # object in the background as fast as possible. | |
| # 基于以上起因，Redis 还提供了 UNLINK（non-blocking DEL）等非阻塞删除原语，# 以及 FLUSHALL 和 FLUSHDB 命令的异步选项，以便在后盾回收内存。这些命令在固定 | |
| # 工夫内执行。另一个线程将以最快的速度增量开释后盾的对象。# DEL, UNLINK and ASYNC option of FLUSHALL and FLUSHDB are user-controlled. | |
| # It's up to the design of the application to understand when it is a good | |
| # idea to use one or the other. However the Redis server sometimes has to | |
| # delete keys or flush the whole database as a side effect of other operations. | |
| # Specifically Redis deletes objects independently of a user call in the | |
| # following scenarios: | |
| # FLUSHALL,FLUSHDB,DEL,UNLINK 和 ASYNC 选项由用户管制。这取决于应用程序的 | |
| # 设计来了解怎么做比拟好。然而，因为某些操作，Redis 服务器有时不得不删除密钥或 | |
| # 刷新整个数据库。具体来说，在以下状况下，Redis 会独立于用户调用删除对象：# 1) On eviction, because of the maxmemory and maxmemory policy configurations, | |
| # in order to make room for new data, without going over the specified | |
| # memory limit. | |
| # 因为 maxmemory 和 maxmemory 策略配置，以便为新数据留出空间，而不超过指定的内存限度。# 2) Because of expire: when a key with an associated time to live (see the | |
| # EXPIRE command) must be deleted from memory. | |
| # 因为 expire：必须从内存中删除具备相干生存工夫的密钥 | |
| # 3) Because of a side effect of a command that stores data on a key that may | |
| # already exist. For example the RENAME command may delete the old key | |
| # content when it is replaced with another one. Similarly SUNIONSTORE | |
| # or SORT with STORE option may delete existing keys. The SET command | |
| # itself removes any old content of the specified key in order to replace | |
| # it with the specified string. | |
| # 因为命令的副作用是将数据存储在可能曾经存在的键上。例如，重命名命令可能会 | |
| # 删除旧的密钥内容，当它被另一个替换时。相似地，SUNIONSTORE 或 SORT with | |
| # STORE 选项可能会删除现有的密钥。SET 命令自身删除指定键的任何旧内容，# 以便用指定的字符串替换它。# 4) During replication, when a replica performs a full resynchronization with | |
| # its master, the content of the whole database is removed in order to | |
| # load the RDB file just transferred. | |
| # 在复制过程中，当正本与其主正本执行齐全从新同步时，整个数据库的内容将被删除，# 以便加载刚刚传输的 RDB 文件。# In all the above cases the default is to delete objects in a blocking way, | |
| # like if DEL was called. However you can configure each case specifically | |
| # in order to instead release memory in a non-blocking way like if UNLINK | |
| # was called, using the following configuration directives. | |
| # 在上述所有状况下，默认状况是以阻塞形式删除对象，就像调用 DEL 一样。然而，# 您能够具体地配置每种状况，以便应用以下配置指令以非阻塞形式开释内存，就像调用 UNLINK 一样。lazyfree-lazy-eviction no | |
| lazyfree-lazy-expire no | |
| lazyfree-lazy-server-del no | |
| replica-lazy-flush no | |
| # It is also possible, for the case when to replace the user code DEL calls | |
| # with UNLINK calls is not easy, to modify the default behavior of the DEL | |
| # command to act exactly like UNLINK, using the following configuration | |
| # directive: | |
| # 在用 UNLINK 调用替换用户代码 DEL 调用并不容易的状况下，还能够应用以下配置 | |
| # 指令批改 DEL 命令的默认行为，使其与 UNLINK 完全相同：lazyfree-lazy-user-del no | |
| ######################### THREADED I/O ############################# | |
| # Redis is mostly single threaded, however there are certain threaded | |
| # operations such as UNLINK, slow I/O accesses and other things that are | |
| # performed on side threads. | |
| # Redis 次要是单线程的，然而也有一些线程操作，比方 UNLINK、迟缓的 I / O 拜访 | |
| # 以及其余线程上执行的操作。# Now it is also possible to handle Redis clients socket reads and writes | |
| # in different I/O threads. Since especially writing is so slow, normally | |
| # Redis users use pipelining in order to speedup the Redis performances per | |
| # core, and spawn multiple instances in order to scale more. Using I/O | |
| # threads it is possible to easily speedup two times Redis without resorting | |
| # to pipelining nor sharding of the instance. | |
| # 当初还能够在不同的 I / O 线程中解决 Redis 客户端的套接字读写。因为编速度比较慢，# 通常 Redis 用户应用管道来减速每核的 Redis 性能，并生成多个实例以扩大更多。应用 I / O 线程，# 能够轻松地将 Redis 的速度进步两倍，而无需依赖于管道或实例的分片。# By default threading is disabled, we suggest enabling it only in machines | |
| # that have at least 4 or more cores, leaving at least one spare core. | |
| # Using more than 8 threads is unlikely to help much. We also recommend using | |
| # threaded I/O only if you actually have performance problems, with Redis | |
| # instances being able to use a quite big percentage of CPU time, otherwise | |
| # there is no point in using this feature. | |
| # 默认状况下，线程被禁用，咱们倡议只在至多有 4 个或更多内核的计算机中启用它，# 并至多保留一个备用内核。应用超过 8 个线程不大可能有多大帮忙。咱们还倡议仅当 | |
| # 您理论存在性能问题时才应用线程 I /O，因为 Redis 实例能够占用相当大比例的 CPU 工夫，# 否则应用此性能没有任何意义。# So for instance if you have a four cores boxes, try to use 2 or 3 I/O | |
| # threads, if you have a 8 cores, try to use 6 threads. In order to | |
| # enable I/O threads use the following configuration directive: | |
| # 例如，如果你有一个 4 核的 CPU，尝试应用 2 或 3 个 I / O 线程，如果你有一个 8 核，# 尝试应用 6 个线程。要启用 I / O 线程，请应用以下配置指令：# io-threads 4 | |
| # | |
| # Setting io-threads to 1 will just use the main thread as usually. | |
| # When I/O threads are enabled, we only use threads for writes, that is | |
| # to thread the write(2) syscall and transfer the client buffers to the | |
| # socket. However it is also possible to enable threading of reads and | |
| # protocol parsing using the following configuration directive, by setting | |
| # it to yes: | |
| # 将 io 线程设置为 1 只会像平时一样应用主线程。当启用 I / O 线程时，咱们只应用线程进行写入，# 即线程 write(2) 零碎调用并将客户机缓冲区传输到套接字。然而，也能够应用以下配置指令 | |
| # 启用读取线程和协定解析，办法是将其设置为 yes | |
| # io-threads-do-reads no | |
| # | |
| # Usually threading reads doesn't help much. 通常线程读取没有多大帮忙。# | |
| # NOTE 1: This configuration directive cannot be changed at runtime via | |
| # CONFIG SET. Aso this feature currently does not work when SSL is | |
| # enabled. | |
| # 无奈在运行时通过配置集更改此配置指令。# NOTE 2: If you want to test the Redis speedup using redis-benchmark, make | |
| # sure you also run the benchmark itself in threaded mode, using the | |
| # --threads option to match the number of Redis theads, otherwise you'll not | |
| # be able to notice the improvements. | |
| ###################### APPEND ONLY MODE ####################### | |
| # By default Redis asynchronously dumps the dataset on disk. This mode is | |
| # good enough in many applications, but an issue with the Redis process or | |
| # a power outage may result into a few minutes of writes lost (depending on | |
| # the configured save points). | |
| # 默认状况下，Redis 异步地将数据集转储到磁盘上。这种模式在许多利用中曾经足够好了，# 然而 Redis 过程的问题或断电可能会导致几分钟的写操作失落（取决于配置的保留点）。# The Append Only File is an alternative persistence mode that provides | |
| # much better durability. For instance using the default data fsync policy | |
| # (see later in the config file) Redis can lose just one second of writes in a | |
| # dramatic event like a server power outage, or a single write if something | |
| # wrong with the Redis process itself happens, but the operating system is | |
| # still running correctly. | |
| # AOF 是另一种持久性模式，它提供了更好的持久性。例如，如果应用默认的数据 | |
| # fsync 策略（请参阅配置文件前面的局部），Redis 在服务器断电等戏剧性事件中可能只会 | |
| # 失落一秒钟的写入操作，或者如果 Redis 过程自身产生了问题，但操作系统仍在失常运行，# 则只会失落一次写入操作。# AOF and RDB persistence can be enabled at the same time without problems. | |
| # If the AOF is enabled on startup Redis will load the AOF, that is the file | |
| # with the better durability guarantees. | |
| # AOF 和 RDB 持久性能够同时启用而不会呈现问题。如果启动时启用了 AOF，Redis 将加载 AOF，# 即具备更好的持久性保障的文件。# Please check http://redis.io/topics/persistence for more information. | |
| appendonly no | |
| # The name of the append only file (default: "appendonly.aof") AOF 文件名 | |
| appendfilename "appendonly.aof" | |
| # The fsync() call tells the Operating System to actually write data on disk | |
| # instead of waiting for more data in the output buffer. Some OS will really flush | |
| # data on disk, some other OS will just try to do it ASAP. | |
| # fsync() 调用通知操作系统在磁盘上理论写入数据，而不是期待输入缓冲区中的更多数据。# 有些操作系统会在磁盘上刷新数据，而有些操作系统则会尽快刷新 | |
| # Redis supports three different modes: | |
| # | |
| # no: don't fsync, just let the OS flush the data when it wants. Faster. 等操作系统刷新缓存到磁盘 | |
| # always: fsync after every write to the append only log. Slow, Safest. 每次写操作都刷新 | |
| # everysec: fsync only one time every second. Compromise. 每秒刷新 | |
| # | |
| # The default is "everysec", as that's usually the right compromise between | |
| # speed and data safety. It's up to you to understand if you can relax this to | |
| # "no" that will let the operating system flush the output buffer when | |
| # it wants, for better performances (but if you can live with the idea of | |
| # some data loss consider the default persistence mode that's snapshotting), | |
| # or on the contrary, use "always" that's very slow but a bit safer than | |
| # everysec. | |
| # 默认值是“everysec”，因为这通常是速度和数据安全之间的正确折衷。为了更新好的性能，# 能够设置为 "no"，或者恰恰相反，应用“always”，它十分慢，但比 everysec 平安一些。# More details please check the following article: | |
| # http://antirez.com/post/redis-persistence-demystified.html | |
| # | |
| # If unsure, use "everysec". | |
| # appendfsync always | |
| appendfsync everysec | |
| # appendfsync no | |
| # When the AOF fsync policy is set to always or everysec, and a background | |
| # saving process (a background save or AOF log background rewriting) is | |
| # performing a lot of I/O against the disk, in some Linux configurations | |
| # Redis may block too long on the fsync() call. Note that there is no fix for | |
| # this currently, as even performing fsync in a different thread will block | |
| # our synchronous write(2) call. | |
| # 当 AOF fsync 策略设置为 always 或 everysec，后盾保留过程（后盾保留或 AOF 日志后盾重写）# 正在对磁盘执行大量 I / O 时，在某些 Linux 配置中，Redis 可能会在 fsync() 调用上阻塞太长时间。# 留神，目前没对此进行修复，因为即便在不同的线程中执行 fsync 也会阻止咱们的同步 write 调用。# In order to mitigate this problem it's possible to use the following option | |
| # that will prevent fsync() from being called in the main process while a | |
| # BGSAVE or BGREWRITEAOF is in progress. | |
| # | |
| # This means that while another child is saving, the durability of Redis is | |
| # the same as "appendfsync none". In practical terms, this means that it is | |
| # possible to lose up to 30 seconds of log in the worst scenario (with the | |
| # default Linux settings). | |
| # | |
| # If you have latency problems turn this to "yes". Otherwise leave it as | |
| # "no" that is the safest pick from the point of view of durability. | |
| # 如果您有提早问题，请将此选项设置为“是”。否则，将其保留为“否”，从耐用性的角度来看，# 这是最平安的抉择。no-appendfsync-on-rewrite no | |
| # Automatic rewrite of the append only file. | |
| # Redis is able to automatically rewrite the log file implicitly calling | |
| # BGREWRITEAOF when the AOF log size grows by the specified percentage. | |
| # Redis 可能在 AOF 日志大小按指定的百分比增长时主动重写日志文件，并隐式调用 BGREWRITEAOF。# This is how it works: Redis remembers the size of the AOF file after the | |
| # latest rewrite (if no rewrite has happened since the restart, the size of | |
| # the AOF at startup is used). | |
| # 它是这样工作的：Redis 在最近一次重写之后记住 AOF 文件的大小（如果重新启动后没有重写，# 则应用启动时 AOF 的大小）。# This base size is compared to the current size. If the current size is | |
| # bigger than the specified percentage, the rewrite is triggered. Also | |
| # you need to specify a minimal size for the AOF file to be rewritten, this | |
| # is useful to avoid rewriting the AOF file even if the percentage increase | |
| # is reached but it is still pretty small. | |
| # 将此根本大小与以后大小进行比拟。如果以后大小大于指定的百分比，则会触发重写。# 此外，您还须要为要重写的 AOF 文件指定最小大小，这对于防止重写 AOF 文件十分有用，# 即便达到了百分比减少，但它依然很小。# Specify a percentage of zero in order to disable the automatic AOF | |
| # rewrite feature. | |
| auto-aof-rewrite-percentage 100 | |
| auto-aof-rewrite-min-size 64mb | |
| # An AOF file may be found to be truncated at the end during the Redis | |
| # startup process, when the AOF data gets loaded back into memory. | |
| # This may happen when the system where Redis is running | |
| # crashes, especially when an ext4 filesystem is mounted without the | |
| # data=ordered option (however this can't happen when Redis itself | |
| # crashes or aborts but the operating system still works correctly). | |
| # 在 Redis 启动过程中，当 AOF 数据加载回内存时，可能会发现 AOF 文件在开端被截断。# 当运行 Redis 的零碎解体时，尤其是在没有 data=ordered 选项的状况下挂载 ext4 文件系统时，# 可能会产生这种状况（然而，当 Redis 自身解体或停止，但操作系统依然失常工作时，# 这种状况就不会产生）。# Redis can either exit with an error when this happens, or load as much | |
| # data as possible (the default now) and start if the AOF file is found | |
| # to be truncated at the end. The following option controls this behavior. | |
| # Redis 能够在产生这种状况时退出，或者尽可能多地加载数据（默认当初），# 如果发现 AOF 文件在结尾被截断。以下选项管制此行为。# If aof-load-truncated is set to yes, a truncated AOF file is loaded and | |
| # the Redis server starts emitting a log to inform the user of the event. | |
| # Otherwise if the option is set to no, the server aborts with an error | |
| # and refuses to start. When the option is set to no, the user requires | |
| # to fix the AOF file using the "redis-check-aof" utility before to restart | |
| # the server. | |
| # 如果 aof-load-truncated 设置为 yes，则加载一个截断的 aof 文件，Redis 服务器则记录日志来告诉用户。# 如果该选项设置为“否”，则服务器会因谬误而停止并回绝启动。当该选项设置为 no 时，# 用户须要在重新启动服务器之前应用“redis-check-aof”实用程序修复 AOF 文件 | |
| # Note that if the AOF file will be found to be corrupted in the middle | |
| # the server will still exit with an error. This option only applies when | |
| # Redis will try to read more data from the AOF file but not enough bytes | |
| # will be found. | |
| # 请留神，如果发现 AOF 文件在两头被损坏，服务器仍将退出并返回一个谬误。# 此选项仅实用于 Redis 将尝试从 AOF 文件读取更多数据，但找不到足够字节的状况。aof-load-truncated yes | |
| # When rewriting the AOF file, Redis is able to use an RDB preamble in the | |
| # AOF file for faster rewrites and recoveries. When this option is turned | |
| # on the rewritten AOF file is composed of two different stanzas: | |
| # 在重写 AOF 文件时，Redis 可能在 AOF 文件中应用 RDB 前导码以放慢重写和复原。# [RDB file][AOF tail] | |
| # | |
| # When loading Redis recognizes that the AOF file starts with the "REDIS" | |
| # string and loads the prefixed RDB file, and continues loading the AOF | |
| # tail. | |
| aof-use-rdb-preamble yes | |
| ######################## LUA SCRIPTING ########################### | |
| # Max execution time of a Lua script in milliseconds. | |
| # | |
| # If the maximum execution time is reached Redis will log that a script is | |
| # still in execution after the maximum allowed time and will start to | |
| # reply to queries with an error. | |
| # | |
| # When a long running script exceeds the maximum execution time only the | |
| # SCRIPT KILL and SHUTDOWN NOSAVE commands are available. The first can be | |
| # used to stop a script that did not yet called write commands. The second | |
| # is the only way to shut down the server in the case a write command was | |
| # already issued by the script but the user doesn't want to wait for the natural | |
| # termination of the script. | |
| # | |
| # Set it to 0 or a negative value for unlimited execution without warnings. | |
| lua-time-limit 5000 | |
| ########################### REDIS CLUSTER ########################### | |
| # Normal Redis instances can't be part of a Redis Cluster; only nodes that are | |
| # started as cluster nodes can. In order to start a Redis instance as a | |
| # cluster node enable the cluster support uncommenting the following: | |
| # 一般的 Redis 实例不能是 Redis 集群的一部分；只有作为集群节点启动的节点才能够。# 为了将 Redis 实例作为群集节点启动，请启用群集反对勾销正文以下内容：# cluster-enabled yes | |
| # Every cluster node has a cluster configuration file. This file is not | |
| # intended to be edited by hand. It is created and updated by Redis nodes. | |
| # Every Redis Cluster node requires a different cluster configuration file. | |
| # Make sure that instances running in the same system do not have | |
| # overlapping cluster configuration file names. | |
| # 每个群集节点都有一个群集配置文件。此文件不可手动编辑。它由 Redis 节点创立和更新。# 每个 Redis 集群节点都须要不同的集群配置文件。确保在同一零碎中运行的实例没有重叠的 | |
| # 群集配置文件名。# cluster-config-file nodes-6379.conf | |
| # Cluster node timeout is the amount of milliseconds a node must be unreachable | |
| # for it to be considered in failure state. | |
| # Most other internal time limits are multiple of the node timeout. | |
| # Cluster node timeout 是节点必须无法访问能力被视为处于故障状态的毫秒数。# 大其余少数工夫限度是节点超时的倍数。# cluster-node-timeout 15000 | |
| # A replica of a failing master will avoid to start a failover if its data | |
| # looks too old. | |
| # 如果数据太旧，集群中的不可用 master 的 slave 节点会防止成为备用 master | |
| # There is no simple way for a replica to actually have an exact measure of | |
| # its "data age", so the following two checks are performed: | |
| # 对于复制正本来说，没有一种简略的办法来理论精确测量其“数据期限 | |
| # 1) If there are multiple replicas able to failover, they exchange messages | |
| # in order to try to give an advantage to the replica with the best | |
| # replication offset (more data from the master processed). | |
| # Replicas will try to get their rank by offset, and apply to the start | |
| # of the failover a delay proportional to their rank. | |
| # 如果有多个复制正本可能进行故障转移，# 2) Every single replica computes the time of the last interaction with | |
| # its master. This can be the last ping or command received (if the master | |
| # is still in the "connected" state), or the time that elapsed since the | |
| # disconnection with the master (if the replication link is currently down). | |
| # If the last interaction is too old, the replica will not try to failover | |
| # at all. | |
| # | |
| # The point "2" can be tuned by user. Specifically a replica will not perform | |
| # the failover if, since the last interaction with the master, the time | |
| # elapsed is greater than: | |
| # | |
| # (node-timeout * replica-validity-factor) + repl-ping-replica-period | |
| # | |
| # So for example if node-timeout is 30 seconds, and the replica-validity-factor | |
| # is 10, and assuming a default repl-ping-replica-period of 10 seconds, the | |
| # replica will not try to failover if it was not able to talk with the master | |
| # for longer than 310 seconds. | |
| # | |
| # A large replica-validity-factor may allow replicas with too old data to failover | |
| # a master, while a too small value may prevent the cluster from being able to | |
| # elect a replica at all. | |
| # | |
| # For maximum availability, it is possible to set the replica-validity-factor | |
| # to a value of 0, which means, that replicas will always try to failover the | |
| # master regardless of the last time they interacted with the master. | |
| # (However they'll always try to apply a delay proportional to their | |
| # offset rank). | |
| # 为了达到最大限度的高可用性，能够设置为 0，即 slave 不论和 master 失联多久都能够晋升为 master | |
| # Zero is the only value able to guarantee that when all the partitions heal | |
| # the cluster will always be able to continue. | |
| # | |
| # cluster-replica-validity-factor 10 | |
| # Cluster replicas are able to migrate to orphaned masters, that are masters | |
| # that are left without working replicas. This improves the cluster ability | |
| # to resist to failures as otherwise an orphaned master can't be failed over | |
| # in case of failure if it has no working replicas. | |
| # | |
| # Replicas migrate to orphaned masters only if there are still at least a | |
| # given number of other working replicas for their old master. This number | |
| # is the "migration barrier". A migration barrier of 1 means that a replica | |
| # will migrate only if there is at least 1 other working replica for its master | |
| # and so forth. It usually reflects the number of replicas you want for every | |
| # master in your cluster. | |
| # | |
| # Default is 1 (replicas migrate only if their masters remain with at least | |
| # one replica). To disable migration just set it to a very large value. | |
| # A value of 0 can be set but is useful only for debugging and dangerous | |
| # in production. | |
| # | |
| # cluster-migration-barrier 1 | |
| # By default Redis Cluster nodes stop accepting queries if they detect there | |
| # is at least an hash slot uncovered (no available node is serving it). | |
| # This way if the cluster is partially down (for example a range of hash slots | |
| # are no longer covered) all the cluster becomes, eventually, unavailable. | |
| # It automatically returns available as soon as all the slots are covered again. | |
| # 默认状况下如果 redis 集群如果检测到至多有 1 个 hash slot 不可用，集群将进行查问数据。# 如果所有 slot 复原则集群主动复原。# However sometimes you want the subset of the cluster which is working, | |
| # to continue to accept queries for the part of the key space that is still | |
| # covered. In order to do so, just set the cluster-require-full-coverage | |
| # option to no. | |
| # 如果须要集群局部可用状况下仍可提供查问服务，设置为 no。# cluster-require-full-coverage yes | |
| # This option, when set to yes, prevents replicas from trying to failover its | |
| # master during master failures. However the master can still perform a | |
| # manual failover, if forced to do so. | |
| # 选项设置为 yes 时，会阻止 replicas 尝试对其 master 在主故障期间进行故障转移 | |
| # 然而，master 依然能够执行手动故障转移, 如果强制这样做的话。# This is useful in different scenarios, especially in the case of multiple | |
| # data center operations, where we want one side to never be promoted if not | |
| # in the case of a total DC failure. | |
| # | |
| # cluster-replica-no-failover no | |
| # This option, when set to yes, allows nodes to serve read traffic while the | |
| # the cluster is in a down state, as long as it believes it owns the slots. | |
| # | |
| # This is useful for two cases. The first case is for when an application | |
| # doesn't require consistency of data during node failures or network partitions. | |
| # One example of this is a cache, where as long as the node has the data it | |
| # should be able to serve it. | |
| # | |
| # The second use case is for configurations that don't meet the recommended | |
| # three shards but want to enable cluster mode and scale later. A | |
| # master outage in a 1 or 2 shard configuration causes a read/write outage to the | |
| # entire cluster without this option set, with it set there is only a write outage. | |
| # Without a quorum of masters, slot ownership will not change automatically. | |
| # | |
| # cluster-allow-reads-when-down no | |
| # In order to setup your cluster make sure to read the documentation | |
| # available at http://redis.io web site. | |
| ########################## CLUSTER DOCKER/NAT support ######################## | |
| # In certain deployments, Redis Cluster nodes address discovery fails, because | |
| # addresses are NAT-ted or because ports are forwarded (the typical case is | |
| # Docker and other containers). | |
| # | |
| # In order to make Redis Cluster working in such environments, a static | |
| # configuration where each node knows its public address is needed. The | |
| # following two options are used for this scope, and are: | |
| # | |
| # * cluster-announce-ip | |
| # * cluster-announce-port | |
| # * cluster-announce-bus-port | |
| # | |
| # Each instruct the node about its address, client port, and cluster message | |
| # bus port. The information is then published in the header of the bus packets | |
| # so that other nodes will be able to correctly map the address of the node | |
| # publishing the information. | |
| # | |
| # If the above options are not used, the normal Redis Cluster auto-detection | |
| # will be used instead. | |
| # | |
| # Note that when remapped, the bus port may not be at the fixed offset of | |
| # clients port + 10000, so you can specify any port and bus-port depending | |
| # on how they get remapped. If the bus-port is not set, a fixed offset of | |
| # 10000 will be used as usually. | |
| # | |
| # Example: | |
| # | |
| # cluster-announce-ip 10.1.1.5 | |
| # cluster-announce-port 6379 | |
| # cluster-announce-bus-port 6380 | |
| ################################## SLOW LOG ################################### | |
| # The Redis Slow Log is a system to log queries that exceeded a specified | |
| # execution time. The execution time does not include the I/O operations | |
| # like talking with the client, sending the reply and so forth, | |
| # but just the time needed to actually execute the command (this is the only | |
| # stage of command execution where the thread is blocked and can not serve | |
| # other requests in the meantime). | |
| # | |
| # You can configure the slow log with two parameters: one tells Redis | |
| # what is the execution time, in microseconds, to exceed in order for the | |
| # command to get logged, and the other parameter is the length of the | |
| # slow log. When a new command is logged the oldest one is removed from the | |
| # queue of logged commands. | |
| # The following time is expressed in microseconds, so 1000000 is equivalent | |
| # to one second. Note that a negative number disables the slow log, while | |
| # a value of zero forces the logging of every command. | |
| slowlog-log-slower-than 10000 | |
| # There is no limit to this length. Just be aware that it will consume memory. | |
| # You can reclaim memory used by the slow log with SLOWLOG RESET. | |
| slowlog-max-len 128 | |
| ################################ LATENCY MONITOR ############################## | |
| # The Redis latency monitoring subsystem samples different operations | |
| # at runtime in order to collect data related to possible sources of | |
| # latency of a Redis instance. | |
| # | |
| # Via the LATENCY command this information is available to the user that can | |
| # print graphs and obtain reports. | |
| # | |
| # The system only logs operations that were performed in a time equal or | |
| # greater than the amount of milliseconds specified via the | |
| # latency-monitor-threshold configuration directive. When its value is set | |
| # to zero, the latency monitor is turned off. | |
| # | |
| # By default latency monitoring is disabled since it is mostly not needed | |
| # if you don't have latency issues, and collecting data has a performance | |
| # impact, that while very small, can be measured under big load. Latency | |
| # monitoring can easily be enabled at runtime using the command | |
| # "CONFIG SET latency-monitor-threshold <milliseconds>" if needed. | |
| latency-monitor-threshold 0 | |
| ############################### ADVANCED CONFIG ############################### | |
| # Hashes are encoded using a memory efficient data structure when they have a | |
| # small number of entries, and the biggest entry does not exceed a given | |
| # threshold. These thresholds can be configured using the following directives. | |
| hash-max-ziplist-entries 512 | |
| hash-max-ziplist-value 64 | |
| # Lists are also encoded in a special way to save a lot of space. | |
| # The number of entries allowed per internal list node can be specified | |
| # as a fixed maximum size or a maximum number of elements. | |
| # For a fixed maximum size, use -5 through -1, meaning: | |
| # -5: max size: 64 Kb <-- not recommended for normal workloads | |
| # -4: max size: 32 Kb <-- not recommended | |
| # -3: max size: 16 Kb <-- probably not recommended | |
| # -2: max size: 8 Kb <-- good | |
| # -1: max size: 4 Kb <-- good | |
| # Positive numbers mean store up to _exactly_ that number of elements | |
| # per list node. | |
| # The highest performing option is usually -2 (8 Kb size) or -1 (4 Kb size), | |
| # but if your use case is unique, adjust the settings as necessary. | |
| list-max-ziplist-size -2 | |
| # Lists may also be compressed. | |
| # Compress depth is the number of quicklist ziplist nodes from *each* side of | |
| # the list to *exclude* from compression. The head and tail of the list | |
| # are always uncompressed for fast push/pop operations. Settings are: | |
| # 0: disable all list compression | |
| # 1: depth 1 means "don't start compressing until after 1 node into the list, | |
| # going from either the head or tail" | |
| # So: [head]->node->node->...->node->[tail] | |
| # [head], [tail] will always be uncompressed; inner nodes will compress. | |
| # 2: [head]->[next]->node->node->...->node->[prev]->[tail] | |
| # 2 here means: don't compress head or head->next or tail->prev or tail, | |
| # but compress all nodes between them. | |
| # 3: [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail] | |
| # etc. | |
| list-compress-depth 0 | |
| # Sets have a special encoding in just one case: when a set is composed | |
| # of just strings that happen to be integers in radix 10 in the range | |
| # of 64 bit signed integers. | |
| # The following configuration setting sets the limit in the size of the | |
| # set in order to use this special memory saving encoding. | |
| set-max-intset-entries 512 | |
| # Similarly to hashes and lists, sorted sets are also specially encoded in | |
| # order to save a lot of space. This encoding is only used when the length and | |
| # elements of a sorted set are below the following limits: | |
| zset-max-ziplist-entries 128 | |
| zset-max-ziplist-value 64 | |
| # HyperLogLog sparse representation bytes limit. The limit includes the | |
| # 16 bytes header. When an HyperLogLog using the sparse representation crosses | |
| # this limit, it is converted into the dense representation. | |
| # | |
| # A value greater than 16000 is totally useless, since at that point the | |
| # dense representation is more memory efficient. | |
| # | |
| # The suggested value is ~ 3000 in order to have the benefits of | |
| # the space efficient encoding without slowing down too much PFADD, | |
| # which is O(N) with the sparse encoding. The value can be raised to | |
| # ~ 10000 when CPU is not a concern, but space is, and the data set is | |
| # composed of many HyperLogLogs with cardinality in the 0 - 15000 range. | |
| hll-sparse-max-bytes 3000 | |
| # Streams macro node max size / items. The stream data structure is a radix | |
| # tree of big nodes that encode multiple items inside. Using this configuration | |
| # it is possible to configure how big a single node can be in bytes, and the | |
| # maximum number of items it may contain before switching to a new node when | |
| # appending new stream entries. If any of the following settings are set to | |
| # zero, the limit is ignored, so for instance it is possible to set just a | |
| # max entires limit by setting max-bytes to 0 and max-entries to the desired | |
| # value. | |
| stream-node-max-bytes 4096 | |
| stream-node-max-entries 100 | |
| # Active rehashing uses 1 millisecond every 100 milliseconds of CPU time in | |
| # order to help rehashing the main Redis hash table (the one mapping top-level | |
| # keys to values). The hash table implementation Redis uses (see dict.c) | |
| # performs a lazy rehashing: the more operation you run into a hash table | |
| # that is rehashing, the more rehashing "steps" are performed, so if the | |
| # server is idle the rehashing is never complete and some more memory is used | |
| # by the hash table. | |
| # | |
| # The default is to use this millisecond 10 times every second in order to | |
| # actively rehash the main dictionaries, freeing memory when possible. | |
| # | |
| # If unsure: | |
| # use "activerehashing no" if you have hard latency requirements and it is | |
| # not a good thing in your environment that Redis can reply from time to time | |
| # to queries with 2 milliseconds delay. | |
| # | |
| # use "activerehashing yes" if you don't have such hard requirements but | |
| # want to free memory asap when possible. | |
| activerehashing yes | |
| # The client output buffer limits can be used to force disconnection of clients | |
| # that are not reading data from the server fast enough for some reason (a | |
| # common reason is that a Pub/Sub client can't consume messages as fast as the | |
| # publisher can produce them). | |
| # | |
| # The limit can be set differently for the three different classes of clients: | |
| # | |
| # normal -> normal clients including MONITOR clients | |
| # replica -> replica clients | |
| # pubsub -> clients subscribed to at least one pubsub channel or pattern | |
| # | |
| # The syntax of every client-output-buffer-limit directive is the following: | |
| # | |
| # client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds> | |
| # | |
| # A client is immediately disconnected once the hard limit is reached, or if | |
| # the soft limit is reached and remains reached for the specified number of | |
| # seconds (continuously). | |
| # So for instance if the hard limit is 32 megabytes and the soft limit is | |
| # 16 megabytes / 10 seconds, the client will get disconnected immediately | |
| # if the size of the output buffers reach 32 megabytes, but will also get | |
| # disconnected if the client reaches 16 megabytes and continuously overcomes | |
| # the limit for 10 seconds. | |
| # | |
| # By default normal clients are not limited because they don't receive data | |
| # without asking (in a push way), but just after a request, so only | |
| # asynchronous clients may create a scenario where data is requested faster | |
| # than it can read. | |
| # | |
| # Instead there is a default limit for pubsub and replica clients, since | |
| # subscribers and replicas receive data in a push fashion. | |
| # | |
| # Both the hard or the soft limit can be disabled by setting them to zero. | |
| client-output-buffer-limit normal 0 0 0 | |
| client-output-buffer-limit replica 256mb 64mb 60 | |
| client-output-buffer-limit pubsub 32mb 8mb 60 | |
| # Client query buffers accumulate new commands. They are limited to a fixed | |
| # amount by default in order to avoid that a protocol desynchronization (for | |
| # instance due to a bug in the client) will lead to unbound memory usage in | |
| # the query buffer. However you can configure it here if you have very special | |
| # needs, such us huge multi/exec requests or alike. | |
| # | |
| # client-query-buffer-limit 1gb | |
| # In the Redis protocol, bulk requests, that are, elements representing single | |
| # strings, are normally limited ot 512 mb. However you can change this limit | |
| # here. | |
| # | |
| # proto-max-bulk-len 512mb | |
| # Redis calls an internal function to perform many background tasks, like | |
| # closing connections of clients in timeout, purging expired keys that are | |
| # never requested, and so forth. | |
| # | |
| # Not all tasks are performed with the same frequency, but Redis checks for | |
| # tasks to perform according to the specified "hz" value. | |
| # | |
| # By default "hz" is set to 10. Raising the value will use more CPU when | |
| # Redis is idle, but at the same time will make Redis more responsive when | |
| # there are many keys expiring at the same time, and timeouts may be | |
| # handled with more precision. | |
| # | |
| # The range is between 1 and 500, however a value over 100 is usually not | |
| # a good idea. Most users should use the default of 10 and raise this up to | |
| # 100 only in environments where very low latency is required. | |
| hz 10 | |
| # Normally it is useful to have an HZ value which is proportional to the | |
| # number of clients connected. This is useful in order, for instance, to | |
| # avoid too many clients are processed for each background task invocation | |
| # in order to avoid latency spikes. | |
| # | |
| # Since the default HZ value by default is conservatively set to 10, Redis | |
| # offers, and enables by default, the ability to use an adaptive HZ value | |
| # which will temporary raise when there are many connected clients. | |
| # | |
| # When dynamic HZ is enabled, the actual configured HZ will be used | |
| # as a baseline, but multiples of the configured HZ value will be actually | |
| # used as needed once more clients are connected. In this way an idle | |
| # instance will use very little CPU time while a busy instance will be | |
| # more responsive. | |
| dynamic-hz yes | |
| # When a child rewrites the AOF file, if the following option is enabled | |
| # the file will be fsync-ed every 32 MB of data generated. This is useful | |
| # in order to commit the file to the disk more incrementally and avoid | |
| # big latency spikes. | |
| aof-rewrite-incremental-fsync yes | |
| # When redis saves RDB file, if the following option is enabled | |
| # the file will be fsync-ed every 32 MB of data generated. This is useful | |
| # in order to commit the file to the disk more incrementally and avoid | |
| # big latency spikes. | |
| rdb-save-incremental-fsync yes | |
| # Redis LFU eviction (see maxmemory setting) can be tuned. However it is a good | |
| # idea to start with the default settings and only change them after investigating | |
| # how to improve the performances and how the keys LFU change over time, which | |
| # is possible to inspect via the OBJECT FREQ command. | |
| # | |
| # There are two tunable parameters in the Redis LFU implementation: the | |
| # counter logarithm factor and the counter decay time. It is important to | |
| # understand what the two parameters mean before changing them. | |
| # | |
| # The LFU counter is just 8 bits per key, it's maximum value is 255, so Redis | |
| # uses a probabilistic increment with logarithmic behavior. Given the value | |
| # of the old counter, when a key is accessed, the counter is incremented in | |
| # this way: | |
| # | |
| # 1. A random number R between 0 and 1 is extracted. | |
| # 2. A probability P is calculated as 1/(old_value*lfu_log_factor+1). | |
| # 3. The counter is incremented only if R < P. | |
| # | |
| # The default lfu-log-factor is 10. This is a table of how the frequency | |
| # counter changes with a different number of accesses with different | |
| # logarithmic factors: | |
| # | |
| # +--------+------------+------------+------------+------------+------------+ | |
| # | factor | 100 hits | 1000 hits | 100K hits | 1M hits | 10M hits | | |
| # +--------+------------+------------+------------+------------+------------+ | |
| # | 0 | 104 | 255 | 255 | 255 | 255 | | |
| # +--------+------------+------------+------------+------------+------------+ | |
| # | 1 | 18 | 49 | 255 | 255 | 255 | | |
| # +--------+------------+------------+------------+------------+------------+ | |
| # | 10 | 10 | 18 | 142 | 255 | 255 | | |
| # +--------+------------+------------+------------+------------+------------+ | |
| # | 100 | 8 | 11 | 49 | 143 | 255 | | |
| # +--------+------------+------------+------------+------------+------------+ | |
| # | |
| # NOTE: The above table was obtained by running the following commands: | |
| # | |
| # redis-benchmark -n 1000000 incr foo | |
| # redis-cli object freq foo | |
| # | |
| # NOTE 2: The counter initial value is 5 in order to give new objects a chance | |
| # to accumulate hits. | |
| # | |
| # The counter decay time is the time, in minutes, that must elapse in order | |
| # for the key counter to be divided by two (or decremented if it has a value | |
| # less <= 10). | |
| # | |
| # The default value for the lfu-decay-time is 1. A Special value of 0 means to | |
| # decay the counter every time it happens to be scanned. | |
| # | |
| # lfu-log-factor 10 | |
| # lfu-decay-time 1 | |
| ########################### ACTIVE DEFRAGMENTATION ####################### | |
| # | |
| # What is active defragmentation? | |
| # ------------------------------- | |
| # | |
| # Active (online) defragmentation allows a Redis server to compact the | |
| # spaces left between small allocations and deallocations of data in memory, | |
| # thus allowing to reclaim back memory. | |
| # | |
| # Fragmentation is a natural process that happens with every allocator (but | |
| # less so with Jemalloc, fortunately) and certain workloads. Normally a server | |
| # restart is needed in order to lower the fragmentation, or at least to flush | |
| # away all the data and create it again. However thanks to this feature | |
| # implemented by Oran Agra for Redis 4.0 this process can happen at runtime | |
| # in an "hot" way, while the server is running. | |
| # | |
| # Basically when the fragmentation is over a certain level (see the | |
| # configuration options below) Redis will start to create new copies of the | |
| # values in contiguous memory regions by exploiting certain specific Jemalloc | |
| # features (in order to understand if an allocation is causing fragmentation | |
| # and to allocate it in a better place), and at the same time, will release the | |
| # old copies of the data. This process, repeated incrementally for all the keys | |
| # will cause the fragmentation to drop back to normal values. | |
| # | |
| # Important things to understand: | |
| # | |
| # 1. This feature is disabled by default, and only works if you compiled Redis | |
| # to use the copy of Jemalloc we ship with the source code of Redis. | |
| # This is the default with Linux builds. | |
| # | |
| # 2. You never need to enable this feature if you don't have fragmentation | |
| # issues. | |
| # | |
| # 3. Once you experience fragmentation, you can enable this feature when | |
| # needed with the command "CONFIG SET activedefrag yes". | |
| # | |
| # The configuration parameters are able to fine tune the behavior of the | |
| # defragmentation process. If you are not sure about what they mean it is | |
| # a good idea to leave the defaults untouched. | |
| # Enabled active defragmentation | |
| # activedefrag no | |
| # Minimum amount of fragmentation waste to start active defrag | |
| # active-defrag-ignore-bytes 100mb | |
| # Minimum percentage of fragmentation to start active defrag | |
| # active-defrag-threshold-lower 10 | |
| # Maximum percentage of fragmentation at which we use maximum effort | |
| # active-defrag-threshold-upper 100 | |
| # Minimal effort for defrag in CPU percentage, to be used when the lower | |
| # threshold is reached | |
| # active-defrag-cycle-min 1 | |
| # Maximal effort for defrag in CPU percentage, to be used when the upper | |
| # threshold is reached | |
| # active-defrag-cycle-max 25 | |
| # Maximum number of set/hash/zset/list fields that will be processed from | |
| # the main dictionary scan | |
| # active-defrag-max-scan-fields 1000 | |
| # Jemalloc background thread for purging will be enabled by default | |
| jemalloc-bg-thread yes | |
| # It is possible to pin different threads and processes of Redis to specific | |
| # CPUs in your system, in order to maximize the performances of the server. | |
| # This is useful both in order to pin different Redis threads in different | |
| # CPUs, but also in order to make sure that multiple Redis instances running | |
| # in the same host will be pinned to different CPUs. | |
| # | |
| # Normally you can do this using the "taskset" command, however it is also | |
| # possible to this via Redis configuration directly, both in Linux and FreeBSD. | |
| # | |
| # You can pin the server/IO threads, bio threads, aof rewrite child process, and | |
| # the bgsave child process. The syntax to specify the cpu list is the same as | |
| # the taskset command: | |
| # | |
| # Set redis server/io threads to cpu affinity 0,2,4,6: | |
| # server_cpulist 0-7:2 | |
| # | |
| # Set bio threads to cpu affinity 1,3: | |
| # bio_cpulist 1,3 | |
| # | |
| # Set aof rewrite child process to cpu affinity 8,9,10,11: | |
| # aof_rewrite_cpulist 8-11 | |
| # | |
| # Set bgsave child process to cpu affinity 1,10,11 | |
| # bgsave_cpulist 1,10-11 |
正文完
