Redis使用——Redis的redis.conf配置注释详解（二）
背景
日常我们开发时，我们会遇到各种各样的奇奇怪怪的问题（踩坑o(╯□╰)o），这个常见问题系列就是我日常遇到的一些问题的记录文章系列，这里整理汇总后分享给大家，让其还在深坑中的小伙伴有绳索能爬出来。 同时在这里也欢迎大家把自己遇到的问题留言或私信给我，我看看其能否给大家解决。
开发环境
- 系统：Ubuntu
- 工具：Docker
- 镜像：Redis
- 官方配置：redis.conf
内容
本节对于其Redis的redis.conf配置进行注释翻译，确定各个配置的主要用途，便于日后配置使用，由于redis.conf中的配置较多，因此我们拆分为四节进行，本节为第二篇，话不多说下面开始。
################################# REPLICATION ################################# # 主副本复制。使用replicaof 使Redis 实例复制另一个Redis服务器。 # 关于Redis复制的一些事情需要尽快了解。 # # +------------------+ +---------------+ # | Master | ---> | Replica | # | (receive writes) | | (exact copy) | # +------------------+ +---------------+ # # 1) Redis 复制是异步的，但您可以配置一个 master 来停止接受写入，如果它似乎没有连接到至少给定数量的副本。 # 2) Redis 副本能够与master 如果复制链接丢失的时间相对较少时间。您可能需要配置复制积压大小（请参阅下一个此文件的部分）根据您的需要具有合理的值。 # 3) 复制是自动的，不需要用户干预。之后网络分区副本自动尝试重新连接到主节点并与它们重新同步。 # # replicaof <masterip> <masterport> # 如果 master 受密码保护（使用“requirepass”配置下面的指令）可以告诉副本之前进行身份验证开始复制同步过程，否则master会拒绝副本请求。 # # masterauth <master-password> # # 但是，如果您使用的是 Redis ACL，这还不够（对于 Redis 版本6 或更高），并且默认用户无法运行 PSYNC命令和/或复制所需的其他命令。 # 在这种情况下是最好配置一个特殊用户用于复制，并指定 # masteruser 配置如下： # # masteruser <username> # # 当 masteruser 被指定时，副本将对其进行身份验证master 使用新的 AUTH 形式： AUTH <username> <password>. # 当一个副本与主节点失去连接时，或者当副本仍在进行中，副本可以以两种不同的方式运行： # is still in progress, the replica can act in two different ways: # # 1) 如果 replica-serve-stale-data 设置为“yes”（默认），副本将仍然回复客户端请求，可能有过时的数据，或者如果这是第一次同步，数据集可能只是空的。 # 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. # # 2) 如果 replica-serve-stale-data 设置为“no”，副本将回复除以下命令外，所有命令都出现错误“SYNC with master in progress”： # INFO, REPLICAOF, AUTH, PING, SHUTDOWN, REPLCONF, ROLE, CONFIG, SUBSCRIBE, # UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, PUBLISH, PUBSUB, COMMAND, POST, # HOST and LATENCY. # replica-serve-stale-data yes # 您可以配置副本实例接受或不接受写入。写反对副本实例可能有助于存储一些临时数据（因为数据写在副本上的在与主服务器重新同步后很容易被删除）但是 # 如果客户端因为一个原因而写入它，也可能会导致问题错误配置。 # # 由于 Redis 2.6 默认副本是只读的。 # # 注意：只读副本不会暴露给不受信任的客户端在网上。它只是防止滥用实例的保护层。 # 仍然是只读副本默认导出所有管理命令如 CONFIG、DEBUG 等。在有限的范围内，您可以改进只读副本的安全性使用“rename-command”来隐藏所有管理/危险命令。 # replica-read-only yes # 复制同步策略：disk 或 socket. # # 无法继续的新副本和重新连接的副本复制过程只是接收差异，需要做所谓的"full synchronization"。RDB 文件从 master 传输到副本。 # # 传输可以通过两种不同的方式发生： # # 1) Disk-backed: Redis master 创建一个新的进程来写入 RDB磁盘上的文件。后来文件由父级传输以增量方式处理副本。 # 2) Diskless: Redis master 创建一个新进程，直接写入RDB 文件复制套接字，根本不接触磁盘。 # # 使用磁盘备份复制，在生成 RDB 文件的同时，更多的副本可以在当前子进程中排队并与 RDB 文件一起提供服务生成 RDB 文件完成其工作。 # 用无盘复制代替一旦传输开始，到达的新副本将排队并生成一个新副本传输将在当前终止时开始。 # # 当使用无盘复制时，master 等待一个可配置的数量开始传输前的时间（以秒为单位），希望多次个副本将到达，传输可以并行化。 # # 使用慢速磁盘和快速（大带宽）网络，无盘复制效果更好。 # repl-diskless-sync no # 启用无盘复制时，可以配置延迟服务器等待以生成通过套接字传输 RDB 的子进程到副本。 # 这很重要，因为一旦传输开始，就无法提供服务新副本到达，将排队等待下一次 RDB 传输，因此服务器等待延迟以便让更多副本到达。 # 延迟以秒为单位指定，默认为 5 秒。禁用它完全只是将其设置为 0 秒，传输将尽快开始。 # repl-diskless-sync-delay 5 # ----------------------------------------------------------------------------- # 警告：RDB 无盘负载是实验性的。由于在此设置中复制品不会立即将 RDB 存储在磁盘上，可能会导致数据丢失故障转移。 # RDB无磁盘加载+ Redis模块不处理I/O读也可以在与master的初始同步阶段，如果出现I/O错误，Redis将中止。只有当你在做你正在做的事情时才使用。 # ----------------------------------------------------------------------------- # # Replica可以直接从replica加载它从replication link读取的RDB套接字，或者将RDB存储到一个文件中，并在从主服务器完全接收到该文件后读取该文件。 # # 在很多情况下，磁盘比网络慢，并且存储和加载RDB文件可能会增加复制时间(甚至增加主服务器的Write内存和缓冲)。 # 然而，直接从套接字解析RDB文件可能意味着我们必须在接收到完整的RDB之前刷新当前数据库的内容。为此，我们有以下选择: # # "disabled" - 不要使用无盘加载（先将 rdb 文件存储到磁盘） # "on-empty-db" - 只有在完全安全的情况下才使用无盘加载。 # "swapdb" - 在RAM中保留当前db内容的副本，同时直接从套接字解析数据。注意，这需要足够的内存，如果您没有足够的内存，则可能会导致OOM死亡。 repl-diskless-load disabled # 副本以预定义的时间间隔向服务器发送ping。可以使用repl_ping_replica_period选项更改这个间隔。默认值是10秒。 # # repl-ping-replica-period 10 # 以下选项设置复制超时: # # 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). # # 重要的是要确保这个值大于为repp -ping-replica-period指定的值，否则每次主服务器和副本之间的流量较低时都会检测到超时。默认值是60秒。 # # repl-timeout 60 # 在复制套接字同步后禁用TCP_NODELAY ? # # 如果选择“yes”，Redis将使用更少的TCP包和更少的带宽来发送数据到副本。但是，这可能会增加数据出现在副本端的延迟，使用默认配置的Linux内核最高可达40毫秒。 # # 如果选择“no”，数据在复制端出现的延迟将会减少，但更多的带宽将被用于复制。 # # 默认情况下，我们优化的是低延迟，但在非常高的流量条件下，或当主服务器和副本有很多跳的时候，将此转换为“yes”可能是一个好主意。 repl-disable-tcp-nodelay no # 设置复制待办事项大小。backlog是一个缓冲区，当副本断开连接一段时间后，它会累积副本数据，因此当一个副本想要重新连接时，通常不需要完全重同步 # 但部分重同步就足够了，只需要传递副本在断开连接时丢失的部分数据。 # # 复制积压越大，副本能够承受断开的时间就越长，并且稍后能够执行部分重同步。 # # 只有至少有一个副本连接时才会分配积压。 # # repl-backlog-size 1mb # 当主服务器没有连接副本一段时间后，积压将被释放。下面的选项配置从最后一个副本断开连接时开始释放待定缓冲区所需的秒数。 # # 请注意，副本永远不会因为超时而释放积压，因为它们可能会在稍后升级为主副本，并且应该能够正确地与其他副本“partially resynchronize”:因此，它们应该总是积累积压。 # # 值为 0 表示永远不会释放积压。 # # repl-backlog-ttl 3600 # 副本优先级是Redis在INFO中发布的整数输出。 # 当主服务器不能正常工作时，Redis Sentinel使用它来选择一个副本来提升到主服务器。 # 优先级低的副本被认为更有利于提升，例如，如果有三个优先级为10,100,25的副本，Sentinel将选择优先级为10的副本，这是最低的。 # # 然而，一个特殊的优先级为0的副本标志着该副本不能执行主角色，因此优先级为0的副本永远不会被Redis Sentinel选择进行升级。 # 默认优先级为 100. replica-priority 100 # 如果少于N 个副本连接，延迟小于或等于 M 秒。 # N 个副本需要处于“在线”状态。 # # 延迟(以秒为单位)必须<=指定的值，该延迟是根据从副本收到的最后一个ping计算的，该副本通常每秒发送一次。 # # 这个选项并不保证N个副本将接受写操作，但是在没有足够的副本可用的情况下，将暴露丢失写操作的窗口限制在指定的秒数。 # # 例如，需要至少 3 个延迟 <= 10 秒的副本，请使用： # # min-replicas-to-write 3 # min-replicas-max-lag 10 # # 将一个或另一个设置为 0 将禁用该功能。 # # 默认情况下，min-replicas-to-write 设置为 0（禁用功能）并且 min-replicas-max-lag 设置为 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 address and port 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 actually be 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 ############################### KEYS TRACKING ################################# # Redis implements server assisted support for client side caching of values. # This is implemented using an invalidation table that remembers, using # 16 millions of slots, what clients may have certain subsets of keys. In turn # this is used in order to send invalidation messages to clients. Please # check this page to understand more about the feature: # # https://redis.io/topics/client-side-caching # # When tracking is enabled for a client, all the read only queries are assumed # to be cached: this will force Redis to store information in the invalidation # table. When keys are modified, such information is flushed away, and # invalidation messages are sent to the clients. However if the workload is # heavily dominated by reads, Redis could use more and more memory in order # to track the keys fetched by many clients. # # For this reason it is possible to configure a maximum fill value for the # invalidation table. By default it is set to 1M of keys, and once this limit # is reached, Redis will start to evict keys in the invalidation table # even if they were not modified, just to reclaim memory: this will in turn # force the clients to invalidate the cached values. Basically the table # maximum size is a trade off between the memory you want to spend server # side to track information about who cached what, and the ability of clients # to retain cached objects in memory. # # If you set the value to 0, it means there are no limits, and Redis will # retain as many keys as needed in the invalidation table. # In the "stats" INFO section, you can find information about the number of # keys in the invalidation table at every given moment. # # Note: when key tracking is used in broadcasting mode, no memory is used # in the server side so this setting is useless. # # tracking-table-max-keys 1000000 ################################## 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 a 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 password 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 external # 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 compatibility # 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). # # Once the limit is reached Redis will close all the new connections sending # an error '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. # # 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. # # 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). # # 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. # # 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: # # volatile-lru -> Evict using approximated LRU, only keys with an expire set. # allkeys-lru -> Evict any key using approximated LRU. # volatile-lfu -> Evict using approximated LFU, only keys with an expire set. # allkeys-lfu -> Evict any key using approximated LFU. # volatile-random -> Remove a random key having an expire set. # allkeys-random -> Remove a random key, any key. # volatile-ttl -> Remove the key with the nearest expire time (minor TTL) # 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. # # 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. By default Redis will check five keys and pick the one that was # used least recently, you can change the sample size using the following # configuration directive. # # 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. # # 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. # # 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. # # 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. # # 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 tolerate less already expired keys still present # in the system. It's a tradeoff between memory, CPU and latency. # # active-expire-effort 1