目錄

1. Units

·配置數(shù)據(jù)單位換算關(guān)系

·包含其它配置文件的信息 include path

2. Network 網(wǎng)絡(luò)相關(guān)

·bind IP1 [IP2 …]

·保護模式 protected-mode

·端口號 port

·TCP半連接隊列長度配置 tcp-backlog

·是否超時無操作關(guān)閉連接 timeout

·TCP連接保活策略 tcp-keepalive

3. GENERAL 通用配置

·啟動方式 daemonize

·進程pid文件 pidfile

·日志相關(guān) loglevel logfile

·指定數(shù)據(jù)庫的數(shù)量 databse

·啟動是否顯示logo

4. SECURITY 安全相關(guān)

·配置ACL

描述用戶可以做的操作的ACL規(guī)則如下：

·ACL日志配置

·外部ACL文件配置

·配置默認用戶default的密碼

5. CLIENTS 客戶端配置

·設(shè)置最大同時客戶端連接數(shù)

6. MEMORY MANAGEMENT 內(nèi)存管理

·最大內(nèi)存限制

·達到最大內(nèi)存限制時的策略

·使用LRU/LFU/TTL算法時采樣率

·從庫不淘汰數(shù)據(jù)

·過期keys駐留在內(nèi)存中的比例

7. LAZY FREEING 懶惰刪除

8. THREADED I/O

·配置IO線程數(shù)

9. KERNEL OOM CONTROL 設(shè)置OOM時終止哪些進程

10. APPEND ONLY MODE AOF持久化配置

·開始/關(guān)閉aof

·aof文件名稱

·執(zhí)行fsync()系統(tǒng)調(diào)用刷盤的頻率

·當(dāng)有后臺保存任務(wù)時，關(guān)閉appendfsync

·自動重寫aof文件

·AOF文件末尾被截斷

·開啟混合持久化

11. LUA SCRIPTING-LUA腳本相關(guān)

·配置LUA腳本最大執(zhí)行時長

12. REDIS CLUSTER 集群配置

·允許集群模式

·集群配置文件

·節(jié)點超時時間

·設(shè)置副本有效因子

·設(shè)置master故障轉(zhuǎn)移時保留的最少副本數(shù)

·哈希槽全覆蓋檢查

·是否自動故障轉(zhuǎn)移

·集群失敗時允許節(jié)點處理讀請求

13. CLUSTER DOCKER/NAT support

·聲明訪問IP、port

14. SLOW LOG 慢日志

·設(shè)置慢日志記錄閾值

·慢日志文件大小

15. LATENCY MONITOR 延遲監(jiān)控

·設(shè)置延遲閾值

16.EVENT NOTIFICATION 事件通知

17. GOPHER SERVER Gopher協(xié)議

18. ADVANCED CONFIG 高級設(shè)置

·設(shè)置Hash底層數(shù)據(jù)結(jié)構(gòu)由ziplist轉(zhuǎn)為hashtable的閾值

·設(shè)置List底層數(shù)據(jù)結(jié)構(gòu)quicklist中單個ziplist的大小

·設(shè)置壓縮List中ziplist為quicklistLZF結(jié)構(gòu)

·設(shè)置Set底層intset最大entities個數(shù)/intset升級為hashtable的閾值

·設(shè)置ZSet底層數(shù)據(jù)結(jié)構(gòu)由ziplist轉(zhuǎn)為skiplist的閾值

·設(shè)置HyperLogLog底層稀疏矩陣轉(zhuǎn)為稠密矩陣的閾值

·自定義Stream宏節(jié)點大小

·開啟Rehash

·客戶端輸出緩存控制

·配置客戶端query buffer大小

·Redis協(xié)議批量請求單個字符串限制

·Redis執(zhí)行任務(wù)頻率

·動態(tài)hz配置

·AOF重寫時執(zhí)行fsync刷盤策略

·保存RDB文件時執(zhí)行fsync刷盤策略

·LFU設(shè)置

19. ACTIVE DEFRAGMENTATION 碎片整理

---

1. Units

·配置數(shù)據(jù)單位換算關(guān)系

################## 該部分用于指定存儲單位的大小換算關(guān)系，不區(qū)分大小寫，只支持bytes，不支持bits # 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.

·包含其它配置文件的信息 include path

對于公共部分配置，可以按以下方式配置引入

# include /path/to/local.conf # include /path/to/other.conf

2. Network 網(wǎng)絡(luò)相關(guān)

·bind IP1 [IP2 …]

這項配置綁定的IP并不是遠程訪問的客戶端的IP地址，而是本機的IP地址。

# bind 192.168.1.100 10.0.0.1 # bind 127.0.0.1 ::1 bind 127.0.0.1

本機的IP地址是和網(wǎng)卡（network interfaces）綁定在一起的，配置這項后，Redis只會接收來自指定網(wǎng)卡的數(shù)據(jù)包。比如我的主機有以下網(wǎng)卡：

root@VM-4-5-ubuntu:~# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500inet 10.0.4.5 netmask 255.255.252.0 broadcast 10.0.7.255inet6 fe80::5054:ff:fe0b:843 prefixlen 64 scopeid 0x20<link>ether 52:54:00:0b:08:43 txqueuelen 1000 (Ethernet)RX packets 283943 bytes 28027507 (28.0 MB)RX errors 0 dropped 0 overruns 0 frame 0TX packets 280878 bytes 43033240 (43.0 MB)TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536inet 127.0.0.1 netmask 255.0.0.0inet6 ::1 prefixlen 128 scopeid 0x10<host>loop txqueuelen 1000 (Local Loopback)RX packets 35168 bytes 2582220 (2.5 MB)RX errors 0 dropped 0 overruns 0 frame 0TX packets 35168 bytes 2582220 (2.5 MB)TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

如果我想要讓Redis可以遠程連接的話，就需要讓Redis監(jiān)聽eht0這塊網(wǎng)卡，也就是要加上配置bind 127.0.0.1 10.0.4.5，這樣既可以本地訪問，也能夠遠程訪問。（主要bind只能有一行配置，如果有多個網(wǎng)卡要監(jiān)聽，就配置多個ip，用空格隔開，否者只有配置的最后一個bind生效）。

·保護模式 protected-mode

從注釋信息就可以看到，如果protected-mode是yes的話，如果沒有指定bind或者沒有指定密碼，那么只能本地訪問。

protected-mode yes

·端口號 port

配置Redis監(jiān)聽的端口號，默認6379。

# Accept connections on the specified port, default is 6379 (IANA #815344). # If port 0 is specified Redis will not listen on a TCP socket. port 6379

·TCP半連接隊列長度配置 tcp-backlog

在進行TCP/IP連接時，內(nèi)核會維護兩個隊列

• syns queue用于保存已收到sync但沒有接收到ack的TCP半連接請求。由/proc/sys/net/ipv4/tcp_max_syn_backlog指定，我的系統(tǒng)（Ubuntu20.04）上是1024。
• accept queue，用于保存已經(jīng)建立的連接，也就是全連接。由/proc/sys/net/core/somaxconn指定。

根據(jù)配置里的注釋，需要同時提高somaxconn和tcp_max_syn_backlog的值來確保生效。

tcp-backlog 511

·是否超時無操作關(guān)閉連接 timeout

客戶端經(jīng)過多少時間（單位秒）沒有操作就關(guān)閉連接，0代表永不關(guān)閉。

timeout 0

·TCP連接保活策略 tcp-keepalive

TCP連接保活策略，可以通過tcp-keepalive配置項來進行設(shè)置，單位為秒，假如設(shè)置為60秒，則server端會每60秒向連接空閑的客戶端發(fā)起一次ACK請求，以檢查客戶端是否已經(jīng)掛掉，對于無響應(yīng)的客戶端則會關(guān)閉其連接。如果設(shè)置為0，則不會進行保活檢測。

tcp-keepalive 300

3. GENERAL 通用配置

·啟動方式 daemonize

是否以守護（后臺）進程的方式啟動，默認no。

daemonize yes

·進程pid文件 pidfile

redis啟動后會把pid寫入到pidfile指定的文件中。

pidfile /var/run/redis_6379.pid

·日志相關(guān) loglevel logfile

loglevel用于配置日志打印機別，默認notice：

• debug：能設(shè)置的最高的日志級別，打印所有信息，包括debug信息。
• verbose：打印除了debug日志之外的所有日志。
• notice：打印除了debug和verbose級別的所有日志。
• warning：僅打印非常重要的信息。

loglevel noticelogfile ""

·指定數(shù)據(jù)庫的數(shù)量 databse

redis默認有16個數(shù)據(jù)庫，編號從0開始。

databases 16

·啟動是否顯示logo

always-show-logo yes

4. SECURITY 安全相關(guān)

################################## 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很快，所以被破解密碼時，性能也很好，如果你的密碼太渣渣了，那么可能很快就被破解了，因此盡量使用長且不容易被猜到的密碼作為redis的訪問密碼。

·配置ACL

ACL：訪問控制列表。

有兩種方法配置ACL：

• • • 在命令行通過ACL命令進行配置
    • 在Redis配置文件中開始，可以直接在redis.conf中配置，也可以通過外部aclfile配置。aclfile path。

配置語法：

user <username> ... acl rules ...，

例如： user worker +@list +@connection ~jobs:* on >ffa9203c493aa99

redis默認有一個default用戶。如果default具有nopass規(guī)則（就是說沒有配置密碼），那么新連接將立即作為default用戶登錄，無需通過AUTH命令提供任何密碼。否則，連接會在未驗證狀態(tài)下啟動，并需要AUTH驗證才能開始工作。

---

描述用戶可以做的操作的ACL規(guī)則如下：

• 啟用或禁用用戶（已經(jīng)建立的連接不會生效）

• • on 啟用用戶，該用戶可以驗證身份登陸。
  • off 禁用用戶，該用戶不允許驗證身份登陸。

• 允許/禁止用戶執(zhí)行某些命令

• • +<command> 允許用戶執(zhí)行command指示的命令?
  • -<command> 禁止用戶執(zhí)行command指示的命令🈲
  • +@<category> 允許用戶執(zhí)行category分類中的所有命令?
  • -@<category> 禁止用戶執(zhí)行category分類中的所有命令🈲
  • +<command>|subcommand 允許執(zhí)行某個被禁止的command的子命令subcommand。沒有對應(yīng)的-規(guī)則。?
  • allcommands +@all的別名，允許執(zhí)行所有命令。?
  • nocommands -@all的別名，禁止執(zhí)行所有命令。🈲

• 允許/禁止用戶訪問某些Key

• • ~<pattern> 添加用戶可以訪問的Key，比如~*代表用戶可以訪問所有key，~K*代表用戶可訪問以K開頭的key。?
  • allkeys 等價于~*?
  • resetkeys ~<pattern> 刷新允許模式的列表，會覆蓋之前設(shè)置的模式。例如 user test ~* resetkeys ~K*，則只允許訪問匹配K*的鍵，~*失效。?

• 為用戶配置有效密碼

• • ><password> 將密碼添加到用戶的有效密碼列表中。例如user test >mypass on，則用戶test可以使用mypass驗證。
  • <<password> 將密碼從用戶的有效密碼列表中刪除，即不可以使用該密碼驗證。
  • nopass 使用任意密碼都可以成功驗證。
  • resetpass 清除用戶可用密碼列表的數(shù)據(jù)，并清除 nopass 狀態(tài)。之后該用戶不能登陸。直到重新設(shè)置密碼/設(shè)置nopass。
  • reset 重置用戶到初始狀態(tài)。該命令會執(zhí)行以下操作：resetpass, resetkeys, off,-@all。

·ACL日志配置

設(shè)置ACL日志最大長度，默認128個記錄。這個日志是存在內(nèi)存里的。

acllog-max-len 128

·外部ACL文件配置

默認位置etc/redis/users.acl，我們可以在這個文件中定義所有用戶的ACL控制信息。

aclfile /etc/redis/users.acl

·配置默認用戶default的密碼

該配置只對默認用戶default生效。

requirepass yourpass

5. CLIENTS 客戶端配置

·設(shè)置最大同時客戶端連接數(shù)

設(shè)置可以同時連接客戶端的最大數(shù)量。默認該項設(shè)置為 10000 個客戶端。達到限制值后的連接會被拒絕并會返回錯誤信息。

maxclients 10000

6. MEMORY MANAGEMENT 內(nèi)存管理

·最大內(nèi)存限制

指定Redis最大內(nèi)存限制。達到內(nèi)存限制時，Redis將嘗試刪除已到期或即將到期的Key。

maxmemory <bytes>

·達到最大內(nèi)存限制時的策略

配置達到最大內(nèi)存限制后，Redis進行何種操作。默認noeviction

maxmemory-policy noeviction

總共有8種策略可供選擇：

• • volatile-lru 只對設(shè)置了過期時間的Key進行淘汰，淘汰算法近似的LRU。
  • allkeys-lru 對所有Key進行淘汰，LRU。
  • volatile-lfu 只對設(shè)置了過期時間的Key進行淘汰，淘汰算法近似的LFU。
  • allkeys-lfu 對所有Key進行淘汰，LFU。
  • volatile-random 只對設(shè)置了過期時間的Key進行淘汰，淘汰算法為隨機淘汰。
  • allkeys-random 對所有Key進行淘汰，隨機淘汰。
  • volatile-ttl 只對設(shè)置了過期時間的Key進行淘汰，刪除即將過期的即ttl最小的。
  • noeviction 永不刪除key，達到最大內(nèi)存再進行數(shù)據(jù)裝入時會返回錯誤。

對于可以通過刪除key來釋放內(nèi)存的策略，如果沒有key可以刪除了，那么也會報錯。

·使用LRU/LFU/TTL算法時采樣率

Redis使用的是近似的LRU/LFU/minimal TTL算法。主要是為了節(jié)約內(nèi)存以及提升性能。Redis配置文件有maxmemory-samples選項，可以配置每次取樣的數(shù)量。Redis每次會選擇配置數(shù)量的key，然后根據(jù)算法從中淘汰最差的key。

maxmemory-samples 5

可以通過修改這個配置來獲取更高的淘汰精度或者更好的性能。默認值5就可以獲得很好的結(jié)果。選擇10可以非常接近真是的LRU算法，但是會耗費更多的CPU資源。3的話更快但是淘汰結(jié)果不是特別準(zhǔn)確。

·從庫不淘汰數(shù)據(jù)

配置Redis主從復(fù)制時，從庫超過maxmemory也不淘汰數(shù)據(jù)。這個配置主要是為了保證主從庫的一致性，因為Redis的淘汰策略是隨機的，如果允許從庫自己淘汰key，那么會導(dǎo)致主從不一致的現(xiàn)象出現(xiàn)（master節(jié)點刪除key的命令會同步給slave節(jié)點）。

replica-ignore-maxmemory yes

·過期keys駐留在內(nèi)存中的比例

設(shè)置過期keys仍然駐留在內(nèi)存中的比重，默認是為1，表示最多只能有10%的過期key駐留在內(nèi)存中，該值設(shè)置的越小，那么在一個淘汰周期內(nèi)，消耗的CPU資源也更多，因為需要實時刪除更多的過期key。

active-expire-effort 1

7. 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. # # 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. # 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: # # 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. # 2) Because of expire: when a key with an associated time to live (see the # EXPIRE command) must be deleted from memory. # 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. # 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. # # 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.

翻譯上面的話就是：

Redis有兩個刪除keys的原語。一個是DEL并且它是一個阻塞的刪除對象的操作。意味著server會停止處理新的command以便以同步的方式回收與對象關(guān)聯(lián)的所有內(nèi)存。如果被刪除的key關(guān)聯(lián)的是一個小對象，那么執(zhí)行DEL命令所需要的時間非常短，與Redis中其它O(1)或O(log_N)的命令時間開銷幾乎一樣。然而，如果key與包含了數(shù)百萬個元素的大對象相關(guān)聯(lián)，那么服務(wù)器為了完成刪除命令會阻塞很長時間（甚至幾秒鐘）。

出于以上原因，Redis提供了非阻塞的刪除原語，例如UNLINK(非阻塞式的DEL)和FLUSHALL、FLUSHDB命令的ASYNC選項，以便在后臺回收內(nèi)存。這些命令會在常量（固定的）時間內(nèi)執(zhí)行。另外一個線程會在后臺盡可能快的以漸進式的方式釋放對象。

使用DEL,UNLINK以及FLUSHALL和FLUSHDB的ASYNC選項是由用戶來控制的。這應(yīng)該由應(yīng)用程序的設(shè)計來決定使用其中的哪一個。 然而，作為其它操作的副作用，Redis server有時不得不去刪除keys或者刷新整個數(shù)據(jù)庫。具體來說，Redis在以下情況下會獨立于用戶調(diào)用而刪除對象：

1） 由于maxmemory 和maxmemory policy的設(shè)置，為了在不超出指定的內(nèi)存限制而為新對象騰出空間而逐出舊對象；

2） 因為過期：當(dāng)一個key設(shè)置了過期時間且必須從內(nèi)存中刪除時；

3） 由于在已經(jīng)存在的key上存儲對象的命令的副作用。例如，RENAME命令可能會刪除舊的key的內(nèi)容，當(dāng)該key的內(nèi)容被其它內(nèi)容代替時。類似的，SUNIONSTORE或者帶STORE選項的SORT命令可能會刪除已經(jīng)存在的keys。SET命令會刪除指定鍵的任何舊內(nèi)容，以便使用指定字符串替換。

4）在復(fù)制過程中，當(dāng)從庫與主庫執(zhí)行完全重新同步時，整個數(shù)據(jù)庫的內(nèi)容將被刪除，以便加載剛剛傳輸?shù)腞DB文件。

在上述所有情況下，默認情況是以阻塞方式刪除對象，就像調(diào)用DEL一樣。但是，你可以使用以下配置指令專門配置每種情況，以非阻塞的方式釋放內(nèi)存，就像調(diào)用UNLINK一樣。

相關(guān)的配置：

# 內(nèi)存達到設(shè)置的maxmemory時，是否使用惰性刪除，對應(yīng)上面 1） lazyfree-lazy-eviction no # 過期keys是否惰性刪除，對應(yīng)上面 2） lazyfree-lazy-expire no # 內(nèi)部刪除選項，對應(yīng)上面選項 3）的情況是否惰性刪除 lazyfree-lazy-server-del no # slave接收完RDB文件后清空數(shù)據(jù)是否是惰性的，對應(yīng)上面情況 4） 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:# 是否將DEL調(diào)用替換為UNLINK，注釋里寫的從user code里替換DEL調(diào)用為UNLINK調(diào)用可能并不是一件 # 容易的事，因此可以使用以下選項，將DEL的行為替換為UNLINK lazyfree-lazy-user-del no

8. THREADED I/O

Redis大體上是單線程的，但是也有一些場景使用額外的線程去做的，比如UNLINK、slow I/O accesses。

現(xiàn)在還可以在不同的I/O線程中處理Redis客戶端socket讀寫。（只是網(wǎng)絡(luò)IO這塊兒成了多線程，執(zhí)行命令的那個家伙，還是單線程！）特別是因為寫操作很慢，通常Redis的用戶使用pipeline來提升每個核心下的Redis性能，并且運行多個Redis實例來實現(xiàn)擴展。使用多線程I/O，不需要使用pipeline和實例切分，就可以輕松的提升兩倍的性能。

默認情況下，多線程是禁用的，我們建議只在至少有4個或更多內(nèi)核的機器中啟用多線程，至少保留一個備用內(nèi)核。使用超過8個線程不太可能有多大幫助。我們還建議僅當(dāng)您確實存在性能問題時才使用線程化I/O，因為除非Redis實例能夠占用相當(dāng)大的CPU時間，否則使用此功能沒有意義。

·配置IO線程數(shù)

如果你的機器是4核的，可以配置2個或者3個線程。如果你有8核，可以配置6個線程。通過下面這個參數(shù)來配置線程數(shù)：

io-threads 4

將io-threads設(shè)置為1將只使用主線程。當(dāng)啟用I/O線程時，我們只使用多線程進行寫操作，也就是說，執(zhí)行write(2)系統(tǒng)調(diào)用并將Client緩沖區(qū)傳輸?shù)教捉幼帧５?#xff0c;也可以通過將以下配置指令設(shè)置為yes來啟用讀取線程和協(xié)議解析：

io-threads-do-reads no

通常情況下多線程的read并沒有什么卵用。

需要注意的兩點是：

• 這兩個配置不能運行時通過CONFIG SET來改變，而且開啟SSL功能時，多線程I/O同樣不會生效。
• 如果你想用benchmark腳本測試多線程下的性能提升，確保benchmark也是多線程模式，在后面加上--threads參數(shù)，來匹配Redis的線程數(shù)。不然看不到什么性能提升。

9. KERNEL OOM CONTROL 設(shè)置OOM時終止哪些進程

KERNEL OOM CONTROL：

KERNEL ：核心

OOM：Out Of Memory(內(nèi)存溢出)

在Linux上，可以提示內(nèi)核OOM killer在OOM發(fā)生時應(yīng)該首先終止哪些進程。

啟用此功能可使Redis根據(jù)其角色主動控制其所有進程的oom_score_adj值。默認分數(shù)將嘗試在所有其他進程之前殺死背景子進程，并在主進程之前殺死從節(jié)點進程。

Redis支持三個選項：

• • no：對oom-score-adj不做任何修改（默認值）
  • yes：relative的別名
  • absolute：oom-score-adj-values配置的值將寫入內(nèi)核
  • relative：當(dāng)服務(wù)器啟動時，使用相對于oom_score_adj初始值的值，然后將其限制在-1000到1000的范圍內(nèi)。因為初始值通常為0，所以它們通常與絕對值匹配。

oom-score-adj no

當(dāng)使用oom-score-adj選項（不為no）時，該指令控制用于主、從和后臺子進程的特定值。數(shù)值范圍為-2000到2000（越高意味著死亡的可能性越大）。

非特權(quán)進程（不是根進程，也沒有CAP_SYS_RESOURCE功能）可以自由地增加它們的價值，但不能將其降低到初始設(shè)置以下。這意味著將oom score adj設(shè)置為“相對”，并將oom score adj值設(shè)置為正值將始終成功

# 分別控制主進程、從進程和后臺子進程的值 oom-score-adj-values 0 200 800

10. APPEND ONLY MODE AOF持久化配置

·開始/關(guān)閉aof

appendonly no

·aof文件名稱

appendfilename "appendonly.aof"

·執(zhí)行fsync()系統(tǒng)調(diào)用刷盤的頻率

appendfsync everysec

• • everysec：每秒執(zhí)行，可能會丟失最后一秒的數(shù)據(jù)。
  • always：每次寫操作執(zhí)行，數(shù)據(jù)最安全，但是對性能有影響。
  • no：不強制刷盤，由內(nèi)核決定什么時候刷盤，數(shù)據(jù)最不安全，性能最好。

·當(dāng)有后臺保存任務(wù)時，關(guān)閉appendfsync

當(dāng)后臺在執(zhí)行save任務(wù)或者aof文件的rewrite時，會對磁盤造成大量I/O操作，在某些Linux配置中，Redis可能會在fsync()系統(tǒng)調(diào)用上阻塞很長時間。需要注意的是，目前還沒有很好的解決方法，因為即使是在不同的線程中執(zhí)行fsync()調(diào)用也會阻塞write(2)調(diào)用。

為了緩解上述問題，可以使用以下選項，防止在進行BGSAVE或者BGREWRITEAOF時在主進程中調(diào)用fsync()。

• • SAVE 直接調(diào)用 rdbSave函數(shù) ，阻塞 Redis 主進程，直到保存完成為止。在主進程阻塞期間，服務(wù)器不能處理客戶端的任何請求。（如果數(shù)據(jù)量小，用此命令可能感覺不出有什么區(qū)別，但是當(dāng)數(shù)據(jù)量很大的時候，就需要謹慎使用這個命令。）
  • BGSAVE 命令執(zhí)行之后立即返回 OK ，然后 Redis fork 出一個新子進程，原來的 Redis 進程(父進程)繼續(xù)處理客戶端請求，而子進程則負責(zé)將數(shù)據(jù)保存到磁盤，然后退出。（BGSAVE方式比較適合線上的維護操作。）

這意味這如果有其它子進程在執(zhí)行saving任務(wù)時，Redis的行為相當(dāng)于配置了appendfsync none。實際上，這意味著在最壞的情況下（使用Linux默認設(shè)置），可能丟失最多30s的日志。

如果您有延遲的問題（性能問題），將此設(shè)置為“yes”，否則，設(shè)置為“no”。從持久化的角度看，這是最安全的選擇。

no-appendfsync-on-rewrite no

·自動重寫aof文件

在AOF文件大小增長到了指定的百分比（相對于上次AOF文件大小的增長量）或者最小體積時，自動調(diào)用BGREWRITEAOF命令重寫AOF文件。

auto-aof-rewrite-percentage 100 #aof文件的大小超過基準(zhǔn)百分之多少后觸發(fā)重寫（100默認值，2倍的意思） auto-aof-rewrite-min-size 64mb #當(dāng)前aof文件大于多少字節(jié)后才觸發(fā)重寫

·AOF文件末尾被截斷

在Redis啟動過程的最后，當(dāng)AOF數(shù)據(jù)加載回內(nèi)存時，可能會發(fā)現(xiàn)AOF文件被截斷。當(dāng)運行Redis的系統(tǒng)崩潰時，可能會發(fā)生這種情況，尤其是在安裝ext4文件系統(tǒng)時，沒有data=ordered選項（然而，當(dāng)Redis本身崩潰或中止，但操作系統(tǒng)仍然正常工作時，這種情況不會發(fā)生）。

Redis可以在出現(xiàn)這種情況時帶著錯誤退出，也可以加載盡可能多的數(shù)據(jù)（現(xiàn)在是默認值），并在發(fā)現(xiàn)AOF文件在最后被截斷時啟動。以下選項控制此行為。

如果aof load truncated設(shè)置為yes，則會加載一個被截斷的aof文件，Redis服務(wù)器開始發(fā)送日志，通知用戶該事件。否則，如果該選項設(shè)置為“no”，服務(wù)器將因錯誤而中止并拒絕啟動。當(dāng)選項設(shè)置為“no”時，用戶需要使用“redis-check-aof”實用程序修復(fù)AOF文件，然后才能重新啟動服務(wù)器。

請注意，如果在中間發(fā)現(xiàn)AOF文件已損壞，服務(wù)器仍將退出并出現(xiàn)錯誤。此選項僅適用于Redis嘗試從AOF文件讀取更多數(shù)據(jù)，但找不到足夠字節(jié)的情況。

aof-load-truncated yes

·開啟混合持久化

當(dāng)重寫AOF文件時，Redis能夠在AOF文件中使用RDB前導(dǎo)，以更快地重寫和恢復(fù)。啟用此選項后，重寫的AOF文件由兩個不同的節(jié)組成：

[RDB file][AOF tail]

加載時，Redis識別出AOF文件以“Redis”字符串開頭，并加載帶前綴的RDB文件，然后繼續(xù)加載AOF尾部。

aof-use-rdb-preamble yes

11. LUA SCRIPTING-LUA腳本相關(guān)

·配置LUA腳本最大執(zhí)行時長

單位毫秒，默認5s。當(dāng)腳本運行時間超過限制后，Redis將開始接受其他命令當(dāng)不會執(zhí)行，而是會返回BUSY錯誤。

lua-time-limit 5000

12. REDIS CLUSTER 集群配置

·允許集群模式

只有以集群模式啟動的Redis實例才能作為集群的節(jié)點

cluster-enabled yes

·集群配置文件

由Redis創(chuàng)建維護，不需要我們關(guān)心內(nèi)容，只需要配好位置即可

cluster-config-file nodes-6379.conf

·節(jié)點超時時間

集群模式下，master節(jié)點之間會互相發(fā)送PING心跳來檢測集群master節(jié)點的存活狀態(tài)，超過配置的時間沒有得到響應(yīng)，則認為該master節(jié)點主觀宕機。

cluster-node-timeout 15000

·設(shè)置副本有效因子

副本數(shù)據(jù)太老舊就不會被選為故障轉(zhuǎn)移的啟動者。

副本沒有簡單的方法可以準(zhǔn)確測量其“數(shù)據(jù)年齡”，因此需要執(zhí)行以下兩項檢查：

• • 如果有多個復(fù)制副本能夠進行故障切換，則它們會交換消息，以便嘗試為具有最佳復(fù)制偏移量的副本提供優(yōu)勢（已經(jīng)從master接收了盡可能多的數(shù)據(jù)的節(jié)點更可能成為新master）。復(fù)制副本將嘗試按偏移量獲取其排名，并在故障切換開始時應(yīng)用與其排名成比例的延遲（排名越靠前的越早開始故障遷移）。
  • 每個副本都會計算最后一次與其主副本交互的時間。這可以是最后一次收到的PING或命令（如果主機仍處于“已連接”狀態(tài)），也可以是與主機斷開連接后經(jīng)過的時間（如果復(fù)制鏈路當(dāng)前已關(guān)閉）。如果最后一次交互太舊，復(fù)制副本根本不會嘗試故障切換。

第二點的值可以由用戶調(diào)整。特別的，如果自上次與master交互以來，經(jīng)過的時間大于(node-timeout * cluster-replica-validity-factor) + repl-ping-replica-period，則不會成為新的master。

較大的cluster-replica-validity-factor可能允許數(shù)據(jù)太舊的副本故障切換到主副本，而太小的值可能會阻止群集選擇副本。

為了獲得最大可用性，可以將cluster-replica-validity-factor設(shè)置為0，這意味著，無論副本上次與主機交互的時間是什么，副本都將始終嘗試故障切換主機。（不過，他們總是會嘗試應(yīng)用與其偏移等級成比例的延遲）。

0是唯一能夠保證當(dāng)所有分區(qū)恢復(fù)時，集群始終能夠繼續(xù)的值（保證集群的可用性）。

cluster-replica-validity-factor 10

·設(shè)置master故障轉(zhuǎn)移時保留的最少副本數(shù)

群集某個master的slave可以遷移到孤立的master，即沒有工作slave的master。這提高了集群抵御故障的能力，因為如果孤立master沒有工作slave，則在發(fā)生故障時無法對其進行故障轉(zhuǎn)移。

只有在slave的舊master的其他工作slave的數(shù)量至少為給定數(shù)量時，slave才會遷移到孤立的master。這個數(shù)字就是cluster-migration-barrier。值為1意味著slave只有在其master至少有一個其他工作的slave時才會遷移，以此類推。它通常反映集群中每個主機所需的副本數(shù)量。

默認值為1（僅當(dāng)副本的主副本至少保留一個副本時，副本才會遷移）。要禁用遷移，只需將其設(shè)置為非常大的值。可以設(shè)置值0，但僅對調(diào)試有用，并且在生產(chǎn)中很危險。

cluster-migration-barrier 1 # 一個主節(jié)點在擁有幾個從節(jié)點的時候，才會可能割讓一個從節(jié)點

·哈希槽全覆蓋檢查

默認情況下，如果Redis群集節(jié)點檢測到至少有一個未覆蓋的哈希槽（沒有可用的節(jié)點為其提供服務(wù)），它們將停止接受查詢。這樣，如果集群部分關(guān)閉（例如，一系列哈希槽不再被覆蓋），那么所有集群最終都將不可用。一旦所有插槽再次被覆蓋，它就會自動返回可用狀態(tài)。

然而，有時您希望正在工作的集群的子集繼續(xù)接受對仍然覆蓋的密鑰空間部分的查詢。為此，只需將cluster-require-full-coverage選項設(shè)置為no。

cluster-require-full-coverage yes

·是否自動故障轉(zhuǎn)移

當(dāng)設(shè)置為“yes”時，此選項可防止副本在主機故障期間嘗試故障切換master。但是，如果被迫這樣做，主機仍然可以執(zhí)行手動故障切換。

這在不同的場景中很有用，尤其是在多個數(shù)據(jù)中心運營的情況下，如果不在DC（DataCenter？）完全故障的情況下，我們希望其中一方永遠不會升級為master。

cluster-replica-no-failover no

·集群失敗時允許節(jié)點處理讀請求

此選項設(shè)置為“yes”時，允許節(jié)點在集群處于關(guān)閉狀態(tài)時提供讀取流量，只要它認為自己擁有這些插槽。

這對兩種情況很有用：

• • 第一種情況適用于在節(jié)點故障或網(wǎng)絡(luò)分區(qū)期間應(yīng)用程序不需要數(shù)據(jù)一致性的情況。其中一個例子是緩存，只要節(jié)點擁有它應(yīng)該能夠為其提供服務(wù)的數(shù)據(jù)。
  • 第二個用例適用于不滿足三個分片集群，但又希望啟用群集模式并在以后擴展的配置。不設(shè)置該選項而使用1或2分片配置中的master中斷服務(wù)會導(dǎo)致整個集群的讀/寫服務(wù)中斷。如果設(shè)置此選項，則只會發(fā)生寫中斷。如果達不到master的quorum（客觀宕機）數(shù)值，插槽所有權(quán)將不會自動更改。

cluster-allow-reads-when-down no

13. CLUSTER DOCKER/NAT support

·聲明訪問IP、port

以下三項設(shè)置對NAT網(wǎng)絡(luò)或者Docker的支持。

因為NAT端口映射的IP地址在局域網(wǎng)之外是沒辦法訪問到的，因此在這種情況下，要聲明集群的公網(wǎng)網(wǎng)關(guān)（NAT映射）/宿主機的IP地址，以便局域網(wǎng)之外也可以訪問到NAT映射后的/Docker容器內(nèi)的Redis集群中的每個實例。

cluster-announce-bus-port集群節(jié)點之間進行數(shù)據(jù)交換的額外端口。

cluster-announce-ip cluster-announce-port cluster-announce-bus-port

14. SLOW LOG 慢日志

Redis的慢查詢?nèi)罩竟δ苡糜谟涗泩?zhí)行時間超過給定時長的命令請求，用戶可以通過這個功能產(chǎn)生的日志來監(jiān)視和優(yōu)化查詢速度

·設(shè)置慢日志記錄閾值

超過這個值的命令會被記錄到慢日志中，默認10000微秒。

slowlog-log-slower-than <microseconds>

·慢日志文件大小

可以通過這個配置改變慢日志文件的最大長度，超過這個長度后最舊的記錄會被刪除。默認128。

slowlog-max-len 128

15. LATENCY MONITOR 延遲監(jiān)控

Redis延遲監(jiān)控子系統(tǒng)在運行時對不同的操作進行采樣，以收集與Redis實例可能的延遲源相關(guān)的數(shù)據(jù)。

通過延遲命令，用戶可以打印圖表和獲取報告。

系統(tǒng)僅記錄在等于或大于通過延遲監(jiān)視器閾值配置指令指定的毫秒數(shù)的時間內(nèi)執(zhí)行的操作。當(dāng)其值設(shè)置為零時，延遲監(jiān)視器將關(guān)閉。

默認情況下，延遲監(jiān)控是禁用的，因為如果沒有延遲問題，通常不需要延遲監(jiān)控，而且收集數(shù)據(jù)會對性能產(chǎn)生影響，雖然影響很小，但可以在大負載下進行測量。如果需要，可以在運行時使用命令CONFIG SET latency-monitor-threshold <millists>輕松啟用延遲監(jiān)控。

·設(shè)置延遲閾值

latency-monitor-threshold 0

16.EVENT NOTIFICATION 事件通知

Redis keyspace notifications

作用：實時的監(jiān)控keys和values的更改。

Redis可以將key space中發(fā)生的事件通過發(fā)布/訂閱通知客戶端。

例如，如果notify-keyspace-events已經(jīng)啟用，并且客戶端對數(shù)據(jù)庫0中存儲的鍵foo執(zhí)行DEL操作，則將通過Pub/Sub發(fā)布兩條消息：

• • PUBLISH _keyspace@0_:foo del
  • PUBLISH _keyevent@0_:del foo

可以在一組類中選擇Redis將通知的事件。每個類由一個字符標(biāo)識：

• K Keyspace事件，通過__keyspace@<db>__前綴發(fā)布。
• E Keyevent事件，通過__keyevent@<db>__ 前綴發(fā)布。
• g 通用命令（非特定類型），例如DEL，EXPIRE，RENAME…
• $ String相關(guān)命令
• l List相關(guān)命令
• s Set相關(guān)命令
• h Hash相關(guān)命令
• z Sorted Set（ZSet）相關(guān)命令
• x 過期事件（每次key過期時生成的事件）
• e 回收事件（達到maxmemory時回收key的事件）
• t Stream相關(guān)命令
• m Key-miss events，訪問的key不存在時觸發(fā)
• A g$lshzxet的別名，因此AKE代表了除了m之外的所有事件。

默認情況下所有事件通知都是關(guān)閉的，因為大多數(shù)用戶不需要這些特性。且需要至少有K或者E時事件通知才會生效。

notify-keyspace-events ""

17. GOPHER SERVER Gopher協(xié)議

開啟Gopher協(xié)議，大體意思就是說這是一個90年代很流行的Web協(xié)議，客戶端和服務(wù)端實現(xiàn)都非常簡單，Redis服務(wù)器只需要100行代碼就能支持它。一些人想要一個更簡單的互聯(lián)網(wǎng)，另一些人認為主流互聯(lián)網(wǎng)變得過于受控，為想要一點新鮮空氣的人創(chuàng)造一個替代空間是很酷的。總之，為了慶祝🎉Redis誕生10周年，Redis的作者將這個協(xié)議支持作為禮物🎁送給了Redis。

# Redis contains an implementation of the Gopher protocol, as specified in # the RFC 1436 (https://www.ietf.org/rfc/rfc1436.txt). # # The Gopher protocol was very popular in the late '90s. It is an alternative # to the web, and the implementation both server and client side is so simple # that the Redis server has just 100 lines of code in order to implement this # support. # # What do you do with Gopher nowadays? Well Gopher never *really* died, and # lately there is a movement in order for the Gopher more hierarchical content # composed of just plain text documents to be resurrected. Some want a simpler # internet, others believe that the mainstream internet became too much # controlled, and it's cool to create an alternative space for people that # want a bit of fresh air. # # Anyway for the 10nth birthday of the Redis, we gave it the Gopher protocol # as a gift. # # --- HOW IT WORKS? --- # # The Redis Gopher support uses the inline protocol of Redis, and specifically # two kind of inline requests that were anyway illegal: an empty request # or any request that starts with "/" (there are no Redis commands starting # with such a slash). Normal RESP2/RESP3 requests are completely out of the # path of the Gopher protocol implementation and are served as usual as well. # # If you open a connection to Redis when Gopher is enabled and send it # a string like "/foo", if there is a key named "/foo" it is served via the # Gopher protocol. # # In order to create a real Gopher "hole" (the name of a Gopher site in Gopher # talking), you likely need a script like the following: # # https://github.com/antirez/gopher2redis # # --- SECURITY WARNING --- # # If you plan to put Redis on the internet in a publicly accessible address # to server Gopher pages MAKE SURE TO SET A PASSWORD to the instance. # Once a password is set: # # 1. The Gopher server (when enabled, not by default) will still serve # content via Gopher. # 2. However other commands cannot be called before the client will # authenticate. # # So use the 'requirepass' option to protect your instance. # # Note that Gopher is not currently supported when 'io-threads-do-reads' # is enabled. # # To enable Gopher support, uncomment the following line and set the option # from no (the default) to yes. # # gopher-enabled no

18. ADVANCED CONFIG 高級設(shè)置

·設(shè)置Hash底層數(shù)據(jù)結(jié)構(gòu)由ziplist轉(zhuǎn)為hashtable的閾值

當(dāng)Hash類型的keys只包含了少量的實體并且實體的大小沒有超過給定的閾值時，Hash底層會使用ziplist來存儲數(shù)據(jù)而不是使用hashtable以節(jié)省空間。

hash-max-ziplist-entries 512 hash-max-ziplist-value 64

當(dāng)一個Hash類型的key包含的實體數(shù)量超過了hash-max-ziplist-entries的值或者某個實體的大小超過了hash-max-ziplist-value的值（單位字節(jié)），那么底層編碼就會升級成hashtable。

·設(shè)置List底層數(shù)據(jù)結(jié)構(gòu)quicklist中單個ziplist的大小

Redis中List數(shù)據(jù)結(jié)構(gòu)的底層使用的是quicklist的數(shù)據(jù)結(jié)構(gòu)，本質(zhì)上是ziplist作為節(jié)點串起來的linkedlist。可以通過該項設(shè)置來改變每個ziplist的最大大小（ziplist中的fill屬性，超過這個值就會開啟一個新的ziplist）。總共提供了-5到-1五個選項：

• -5：最大大小為64Kb，不推薦作為正常情況下的負載
• -4：最大大小為32Kb，不推薦
• -3：最大大小為16Kb，大概可能估計好像不是很推薦（原話：probably not recommended）
• -2：最大大小為8Kb，good（原話）
• -1：最大大小為4Kb，good（原話）

默認值是-2

list-max-ziplist-size -2

·設(shè)置壓縮List中ziplist為quicklistLZF結(jié)構(gòu)

大神們覺著ziplist不夠zip啊，所以再壓縮一下吧。實際上是考慮了這樣的場景，即List數(shù)據(jù)結(jié)構(gòu)兩端訪問頻率比較高，但是中間部分訪問頻率不是很高的情況，那么使用ziplist存放這部分結(jié)構(gòu)就有點浪費，是不是可以把這部分結(jié)構(gòu)進行壓縮（LZF算法壓縮）呢？這個選項就是進行這個操作的。有下面幾個值：

• 0：代表不壓縮，默認值
• 1：兩端各一個節(jié)點不壓縮
• 2：兩端各兩個節(jié)點不壓縮
• ...：依次類推。。。

list-compress-depth 0

·設(shè)置Set底層intset最大entities個數(shù)/intset升級為hashtable的閾值

Set數(shù)據(jù)結(jié)構(gòu)只有在一種情況下會使用intset來存儲：set由能轉(zhuǎn)成10進制且數(shù)值在64bit有符號整形數(shù)值組成時。下面的配置設(shè)置了intset能存儲的最大entities數(shù)量，超過這個數(shù)量會轉(zhuǎn)成hashtable存儲。默認512個。

set-max-intset-entries 512

·設(shè)置ZSet底層數(shù)據(jù)結(jié)構(gòu)由ziplist轉(zhuǎn)為skiplist的閾值

當(dāng)超過下面設(shè)置的閾值時，ZSet底層存儲結(jié)構(gòu)會由ziplist轉(zhuǎn)為skiplist。

zset-max-ziplist-entries 128 zset-max-ziplist-value 64

·設(shè)置HyperLogLog底層稀疏矩陣轉(zhuǎn)為稠密矩陣的閾值

HyperLogLog當(dāng)在計數(shù)比較小時會使用稀疏矩陣來存儲，只有當(dāng)計數(shù)達到閾值時，才會轉(zhuǎn)為稠密矩陣。

超過16000的值是完全無用的，因為這種情況下使用稠密矩陣更加節(jié)省內(nèi)存。

建議的值是3000左右，以便在不降低太多PFADD速度的情況下獲取空間有效編碼的好處，稀疏編碼的PFADD的時間復(fù)雜度為O(N)。當(dāng)不考慮CPU占用時而考慮內(nèi)存占用時，這個值可以升到10000左右。

hll-sparse-max-bytes 3000

·自定義Stream宏節(jié)點大小

可以通過stream-node-max-bytes選項修改Stream中每個宏節(jié)點能夠占用的最大內(nèi)存，或者通過stream-node-max-entries參數(shù)指定每個宏節(jié)點中可存儲條目的最大數(shù)量。

stream-node-max-bytes 4096 stream-node-max-entries 100

·開啟Rehash

Redis將在每100毫秒時使用1毫秒的CPU時間來對redis的hash表進行重新hash，可以降低內(nèi)存的使用。當(dāng)你的使用場景中，有非常嚴格的實時性需要，不能夠接受Redis時不時的對請求有2毫秒的延遲的話，把這項配置為no。如果沒有這么嚴格的實時性要求，可以設(shè)置為yes，以便能夠盡可能快的釋放內(nèi)存。

activerehashing yes

·客戶端輸出緩存控制

客戶端輸出緩沖區(qū)限制可用于強制斷開由于某種原因從服務(wù)器讀取數(shù)據(jù)速度不夠快的客戶端（一個常見原因是發(fā)布/訂閱客戶端不能像發(fā)布服務(wù)器生成消息那樣快地使用消息）。

對于三種不同類型的客戶端，克制設(shè)置不同的限制：

• • normal：一般客戶端包含監(jiān)控客戶端
  • replica：副本客戶端（slave）
  • pubsub：客戶端至少訂閱了一個pubsub通道或模式。

每個客戶端輸出緩沖區(qū)限制指令語法：

client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>

一旦達到<hard limit>限制或者達到<soft limit>之后又過了<soft seconds>秒，那么客戶端會立即被斷開連接。

例如：

如果<hard limit>為32兆字節(jié)，<soft limit>和<soft seconds>分別為16兆字節(jié)，10秒，則如果輸出緩沖區(qū)的大小達到32兆字節(jié)，客戶端將立即斷開連接，但如果客戶端達到16兆字節(jié)并連續(xù)超過限制10秒，客戶端也將斷開連接。

默認情況下，普通客戶端不受限制，因為它們不會在沒有請求（以推送方式）的情況下接收數(shù)據(jù)，而是在請求之后接收數(shù)據(jù)，因此只有異步客戶端可能會創(chuàng)建一個場景，其中請求數(shù)據(jù)的速度比讀取數(shù)據(jù)的速度快。

相反，pubsub和副本客戶端有一個默認限制，因為訂閱者和副本以推送方式接收數(shù)據(jù)。

硬限制或軟限制都可以通過將其設(shè)置為零來禁用。

client-output-buffer-limit normal 0 0 0 client-output-buffer-limit replica 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60

·配置客戶端query buffer大小

客戶端query buffer大小不能超過該項配置的值。

每個Client都有一個query buffer(查詢緩存區(qū)或輸入緩存區(qū)), 它用于保存客戶端的發(fā)送命令，redis server從query buffer獲取命令并執(zhí)行。如果程序的Key設(shè)計不合理，客戶端使用大量的query buffer，這會導(dǎo)致redis server比較危險，很容易達到maxmeory限制，導(dǎo)致緩存數(shù)據(jù)被清空、數(shù)據(jù)無法寫入和oom.

client-query-buffer-limit 1gb

·Redis協(xié)議批量請求單個字符串限制

默認512mb，可以通過下面選項修改

proto-max-bulk-len 512mb

·Redis執(zhí)行任務(wù)頻率

Redis調(diào)用一個內(nèi)部函數(shù)來執(zhí)行許多后臺任務(wù)，比如在超時時關(guān)閉客戶端連接，清楚從未被請求過的過期key…

并非所有任務(wù)都已相同的頻率執(zhí)行，但Redis根據(jù)指定的hz值檢查要執(zhí)行的任務(wù)。

默認情況下，hz的值為10.提高這個值會讓Redis在空閑的時候占用更多的CPU，但同時也會讓Redis在有很多keys同時過期時響應(yīng)更快并且可以更精確的處理超時。

范圍在1到500之間，但是超過100通常不是一個好主意。大多數(shù)用戶應(yīng)該使用缺省值10，只有在需要非常低延遲的環(huán)境中才應(yīng)該將值提高到100。

hz 10

·動態(tài)hz配置

根據(jù)客戶端連接的數(shù)量動態(tài)的調(diào)整hz的值，當(dāng)有更多的客戶端連接時，會臨時以hz設(shè)置基準(zhǔn)提高該hz的值。默認開啟。

dynamic-hz yes

·AOF重寫時執(zhí)行fsync刷盤策略

當(dāng)一個子系統(tǒng)重寫AOF文件時，如果啟用了以下選項，則該文件將每生成32MB的數(shù)據(jù)進行fsync同步。這對于以更增量的方式將文件提交到磁盤并避免較大的延遲峰值非常有用。

aof-rewrite-incremental-fsync yes

·保存RDB文件時執(zhí)行fsync刷盤策略

當(dāng)redis保存RDB文件時，如果啟用以下選項，則每生成32 MB的數(shù)據(jù)，文件就會同步一次。這對于以更增量的方式將文件提交到磁盤并避免較大的延遲峰值非常有用。

rdb-save-incremental-fsync yes

·LFU設(shè)置

設(shè)置Redis LFU相關(guān)。Redis LFU淘汰策略實現(xiàn)有兩個可調(diào)整參數(shù)：lfu-log-factor和lfu-decay-time。

lfu-log-factor 10 lfu-decay-time 1

19. ACTIVE DEFRAGMENTATION 碎片整理

主動（在線）碎片整理允許Redis服務(wù)器壓縮內(nèi)存中數(shù)據(jù)的少量分配和釋放之間的空間（內(nèi)存碎片），從而回收內(nèi)存。

碎片化是每個分配器（幸運的是，Jemalloc比較少發(fā)生這種情況）和某些工作負載都會發(fā)生的自然過程。通常需要重啟服務(wù)器以降低碎片，或者至少清除所有數(shù)據(jù)并重新創(chuàng)建。然而，多虧了Oran Agra為Redis 4.0實現(xiàn)的這一功能，這個過程可以在服務(wù)器運行時以“hot”的方式在運行時發(fā)生（類似熱部署的意思，不需要停止服務(wù)）。

基本上，當(dāng)碎片超過某個級別（參見下面的配置選項）時，Redis將通過利用特定的Jemalloc功能（以了解分配是否導(dǎo)致碎片并將其分配到更好的位置）開始在連續(xù)內(nèi)存區(qū)域中創(chuàng)建值的新副本，同時釋放數(shù)據(jù)的舊副本。對所有鍵遞增地重復(fù)該過程將導(dǎo)致碎片降至正常值。

需要了解的重要事項：

默認情況下，此功能被禁用，并且僅當(dāng)您編譯Redis以使用我們隨Redis源代碼提供的Jemalloc副本時，此功能才有效。這是Linux版本的默認設(shè)置。

如果沒有碎片問題，則無需啟用此功能。

一旦遇到內(nèi)存碎片，可以在需要時使用命令CONFIG SET activedefrag yes啟用此功能。

配置參數(shù)能夠微調(diào)碎片整理過程的行為。如果你不確定它們是什么意思，最好不要改變默認值。

#開啟活動碎片整理 activedefrag no#啟動活動碎片整理的最小內(nèi)存碎片閾值 active-defrag-ignore-bytes 100mb#啟動活動碎片整理的最小內(nèi)存碎片百分比 active-defrag-threshold-lower 10#嘗試釋放的最大百分比 active-defrag-threshold-upper 100#最少CPU使用率 active-defrag-cycle-min 1#最大CPU使用率 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-bg-thread yes

總結(jié)

以上是生活随笔為你收集整理的【Redis】Redis配置文件详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。