天天看點

Redis使用——Redis的redis.conf配置注釋詳解(二)

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           

複制