学习redis的途中，碰上了redis.conf，突发奇想，想着来进行一波翻译输出。
源码之前，了无秘密。
文章目录
快照
原文
################################ SNAPSHOTTING ################################
#
# Save the DB on disk:
#
# 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.
#
# 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.
#
# 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 900 1
save 300 10
save 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.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# 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.
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.
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 files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes
# The filename where to dump the 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.
#
# 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.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./
译文
将数据保存在磁盘上：save <seconds> <changes>
如果在给定的时间内发生了给定次数的写操作，则将数据写入磁盘。
示例：
save 900 1 //900秒内至少有一条数据写入
save 300 10 //300秒内至少有10条数据写入
save 60 10000 //60秒内至少有10000条数据写入
注意:你可以通过注释掉所有“保存”行来完全禁用保存。
如果出现一次写入磁盘操作失败，redis将停止接收所有写操作，以此来让用户知道数据不能正常的持久化到磁盘。
如果后台保存进程又活了，Redis将自动再次允许写入。
如果你安装了可靠的监控，你可能不希望redis继续保持这个功能了，那就改成 ‘no’ 就好了。
将字符串转储至.rdb数据库的字符串压缩算法是LZF算法？
默认情况下设置为yes，因为大部分情况下这样是有优势的。
如果你想保存一些CPU，将它设置为’no’，但是如果你有可压缩的值或键，数据集可能会更大。
从第五代RDB版本开始，文件末尾添加了一个CRC64 校验和。这提高了该模式的健壮性，但是在保存和加载RDB文件时，会有大约10%的性能损失，所以您可以禁用它以获得最大的性能。
禁用校验和的RDB文件的校验和为零，这将告诉加载代码跳过检查。
删除复制在实例中使用的RDB文件，但不启用持久性。默认情况下，这个选项是禁用的，但是，在一些环境中，由于规则或其他安全考虑，应该尽快删除主服务器保存在磁盘上以提供副本的RDB文件，或通过副本存储在磁盘上以加载它们进行初始同步。注意，此选项仅在AOF和RDB持久性都禁用的情况下有效，否则将完全忽略。
还有一种替代方法，相同效果(有时更好)，是在主实例和副本实例上使用无磁盘复制。然而，对于副本，无磁盘并不总是可选的。
工作目录。
DB将写入到这个目录中，使用上面使用’dbfilename’配置指令指定的文件名。
“仅追加”文件也将在此目录中创建。
注意，这里必须指定目录，而不是文件名。
主从复制
原文
################################# 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.
#
# +------------------+ +---------------+
# | 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.
# 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.
# 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.
#
# 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:
#
# masteruser <username>
#
# When masteruser is specified, the replica will authenticate against its
# master using the new AUTH form: 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.
#
# 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 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.
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.
#
# 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.
# 2) Diskless: The Redis master creates a new process that directly writes the
# RDB file to replica sockets, without touching the disk at all.
#
# 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.
#
# 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.
#
# 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.
#
# 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.
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.
# -----------------------------------------------------------------------------
#
# 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.
#
# 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).
# 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:
#
# "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.
#
# 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
译文
主-副本复制。
使用副本的Redis实例复制另一个Redis服务器。关于Redis复制的一些事情需要了解。
# +------------------+ +---------------+
# | Master | ---> | Replica |
# | (receive writes) | | (exact copy) |
# +------------------+ +---------------+
1)Redis复制是异步的。但是你可以配置一个主服务器，如果它没有连接到至少给定数量的副本，则停止写操作。
2)如果复制链接丢失了相对较短的时间，Redis副本能够执行与主服务器的部分重新同步。您可能希望根据自己的需要配置复制积压大小(请参阅此文件的下一部分)。
3)复制是自动的，不需要用户干预。在网络分区之后，副本会自动尝试重新连接主分区并与它们重新同步。
如果主服务器受密码保护，会在开始复制同步过程之前告诉副本进行身份验证，否则主服务器将拒绝复制请求。
然而，这是不够的，如果你是使用Redis ACLs (Redis版本6或更高)，默认用户不能够运行PSYNC命令和/或其他复制所需的命令。在这种情况下，最好配置一个特殊用户来使用复制，
指定masteruser配置如下：masteruser <username>
当指定了masteruser时，副本将使用新的身份验证表单对其主进行身份验证：AUTH <username> <password>。
当一个副本失去了它与主的连接，或者当复制仍在进行时，副本将会出现以下两种情况:
1)如果将replica-serve-stale-data设置为’yes’(缺省值)，该副本仍然会响应客户机请求，可能会使用过期数据，或者如果这是第一次同步，数据集可能只是空的。
2)如果copy - service - stal- data被设置为“no”，那么除了INFO、replicaOF、AUTH、PING、SHUTDOWN、REPLCONF、ROLE、CONFIG、SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE、PUNSUBSCRIBE、PUBLISH、PUBSUB、COMMAND、POST、HOST:和LATENCY之外，所有类型的命令都会回复一个错误“SYNC with master in progress”。
您可以配置一个副本实例来接受或不接受写操作。写副本实例对于存储一些临时数据可能很有用(因为写在副本上的数据在与主服务器重新同步后很容易删除)，但是如果客户端由于配置错误而写副本，也可能会导致问题。
（从2.6代版本开始，副本默认只读）。
注意:只读副本的设计不是为了在internet上向不受信任的客户端公开。它只是防止实例滥用的保护层。
默认情况下，仍然使用只读副本导出所有管理命令，如配置、调试等。使用“renmin -command”隐藏所有管理/危险命令，可以在一定程度上提高只读副本的安全性。
复制同步策略:磁盘或套接字。
新的副本和重新连接的副本不能继续复制过程只是接收差异，需要做所谓的“完全同步”。RDB文件从主服务器传输到副本服务器。
有以下两种方式进行传输：
1)磁盘备份：Redis主机创建一个新的进程，将RDB文件写到磁盘上。稍后，该文件由父进程递增地传输到副本。
2)无磁盘：Redis master创建一个新的进程，直接将RDB文件写入副本套接字，而不需要接触磁盘。
使用磁盘支持的复制，在生成RDB文件时，只要当前生成RDB文件的子文件完成其工作，就可以将更多的副本排队并与RDB文件一起提供服务。如果在传输开始后使用无磁盘复制，到达的新副本将排队，当当前副本终止时，新的传输将开始。
当使用无磁盘复制时，主服务器在开始传输之前等待一段可配置的时间(以秒为单位)，希望多个副本到达并并行传输。
对于慢磁盘和快(大带宽)网络，无磁盘复制工作得更好。
当启用无磁盘复制时，可以配置服务器等待的延迟，以便生成通过套接字将RDB传输到副本的子服务器。
这一点很重要，因为一旦传输开始，就不可能为到达的新副本提供服务，这些副本将排队等待下一次RDB传输，因此服务器等待延迟，以便让更多的副本到达。
延迟以秒为单位指定，默认情况下为5秒。要完全禁用它，只需将它设置为0秒，传输将尽快开始。
警告:RDB无磁盘加载是试验性的。由于在这种设置中，副本不会立即将RDB存储在磁盘上，因此在故障转移期间可能会导致数据丢失。RDB无磁盘加载+ Redis模块不处理I/O读取也可能导致Redis中止在I/O错误的情况下。只有你有了绝对权限之后才可以这么做。
副本可以直接从套接字加载从复制链接中读取的RDB，或者将RDB存储到一个文件中，并在从主服务器完全接收到该文件后读取该文件。
在许多情况下，磁盘比网络慢，存储和加载RDB文件可能会增加复制时间(甚至增加写内存和缓冲缓冲区上的主副本)。
但是，直接从套接字解析RDB文件可能意味着我们必须在接收到完整的RDB之前刷新当前数据库的内容。因此，我们有以下选择:
“disabled”——不要使用无磁盘加载(首先将rdb文件存储到磁盘)
“on-empty-db”——只有在完全安全的情况下才使用无磁盘加载。
“swapdb”——在直接从套接字解析数据时，在RAM中保留当前db内容的副本。注意，这需要足够的内存，如果没有内存，就会面临OOM被杀死的风险。
复制按预定义的时间间隔将ping发送到服务器。可以使用repl_ping_replica_period选项更改这个间隔。默认值是10秒。
以下选项设置复制超时:
1)从复制的角度看，同步过程中批量传输I/O。
2)从副本(data, pings)的角度控制超时。
3)从master(REPLCONF ACK pings)的角度来看副本超时。
一定要确保此值大于repl-ping-replica-period指定的值，否则每当主服务器和副本之间的流量较低时，就会检测到超时。
同步后在复制套接字上禁用TCP_NODELAY ?
如果你选择“是”Redis将使用更少的TCP数据包和更少的带宽发送数据副本。但是这可能会增加数据在副本端出现的延迟，在使用默认配置的Linux内核中，延迟高达40毫秒。
如果选择“no”，数据在复制端出现的延迟将会减少，但复制将使用更多的带宽。
默认情况下，我们优化的是低延迟，但在流量非常大的情况下，或者当主服务器和副本之间有很多跳距时，将其转换为“yes”可能是一个好主意。
设置复制backlog大小。backlog是一个缓冲区，当副本断开连接一段时间后，它会积累副本数据，因此当副本希望重新连接时，通常不需要完全重新同步，但部分重新同步就足够了，只需传递副本断开连接时丢失的那部分数据。
复制积压越大，副本断开连接的时间就越长，随后就能够执行部分重新同步。
只在至少有一个副本连接时分配backlog。
在主服务器不再连接副本一段时间后，backlog将被释放。以下选项配置从最后一个副本断开连接开始释放积压缓冲区所需的秒数。
注意，副本永远不会因为超时而释放backlog，因为它们可能稍后被提升为主版本，并且应该能够正确地与副本“部分重新同步”:因此，它们应该始终积累backlog。
值为0意味着永远不会释放积压。
副本优先级是由Redis在INFO输出中发布的一个整数。它被Redis哨兵用来选择一个副本提升为一个master，如果master不再正常工作。
优先级较低的副本被认为更适合升级，因此，例如，如果有三个优先级为10,100,25的副本，Sentinel将选择优先级为10的副本，即优先级最低的副本。
但是，如果优先级为0，则表示该副本不能执行master的角色，因此Redis Sentinel将永远不会选择优先级为0的副本进行升级。
默认情况下，优先级是100。
如果连接的副本少于N个，主服务器可以停止接受写操作，延迟小于或等于M秒。
N个副本需要处于“在线”状态。
以秒为单位的延迟必须是<=指定的值，它是从副本接收到的最后一个ping计算出来的，这个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。
一个Redis的管理员是能够列出的地址和端口的附加副本在不同的方式。例如，"INFO replication"部分提供了这个信息，在其他工具中，Redis Sentinel用来找出副本实例。
该信息可用的另一个地方是master的“ROLE”命令的输出。
副本通常报告的所列IP和地址通过以下方式获取:
IP:通过检查副本与主连接使用的套接字的对等地址来自动检测地址。
Port:该端口在复制握手期间由副本通信，并且通常是副本用于侦听连接的端口。
然而，当使用端口转发或网络地址转换(NAT)时，可以通过不同的IP和端口对访问副本。副本可以使用以下两个选项向其主人报告一组特定的IP和端口，以便INFO和ROLE都能报告这些值：
（如果您只需要覆盖端口或IP地址，则不需要同时使用这两个选项）
# 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
# to understand more about the feature check this page:
#
# 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
译文
Redis实现了服务器辅助支持客户端缓存值。这是使用一个invalidation table（失效表？）实现的，它使用了1600万个插槽，客户机可能拥有特定的键子集。
相反的，它用于向客户端发送invalidation信息。详情请去下面的网站一探究竟：
https://redis.io/topics/client-side-caching
当对客户端启用跟踪时，假设所有只读查询都被缓存：这将迫使Redis在invalidation table中存储信息。
当键值被修改时，这些信息被刷新，旧消息（失效消息）被发送到客户端。
然而，如果工作负载主要是读取，Redis可能会使用越来越多的内存来跟踪许多客户端获取的键。
因此，可以为invalidation table配置最大填充值。默认设置为1M的键，一旦达到这个限制，Redis就会开始从invalidation表中移除键，即使它们没有被修改，这样做只是为了回收内存：这将反过来迫使客户机将缓存的值清空。
基本上，表的最大大小是在服务器端用于跟踪 /你缓存了什么信息的内存/ 和 /客户机在内存中保留缓存对象的能力/ 之间进行权衡。
如果你设置的值为0，这意味着没有限制，Redis将保留invalidation table 所需要的所有键。
在“统计”信息部分，您可以找到关于在每个给定时刻invalidation表中的键数的信息。
注意:在广播模式下使用键值跟踪时，服务器端不会使用内存，因此此设置无效。
啊，累啊。。
