【Redis】Redis配置文件详解
目錄
1. Units
·配置數(shù)據(jù)單位換算關(guān)系
·包含其它配置文件的信息 include path
2. Network 網(wǎng)絡(luò)相關(guān)
·bind IP1 [IP2 …]
·保護(hù)模式 protected-mode
·端口號(hào) port
·TCP半連接隊(duì)列長度配置 tcp-backlog
·是否超時(shí)無操作關(guān)閉連接 timeout
·TCP連接?；畈呗?tcp-keepalive
3. GENERAL 通用配置
·啟動(dòng)方式 daemonize
·進(jìn)程pid文件 pidfile
·日志相關(guān) loglevel logfile
·指定數(shù)據(jù)庫的數(shù)量 databse
·啟動(dòng)是否顯示logo
4. SECURITY 安全相關(guān)
·配置ACL
描述用戶可以做的操作的ACL規(guī)則如下：
·ACL日志配置
·外部ACL文件配置
·配置默認(rèn)用戶default的密碼
5. CLIENTS 客戶端配置
·設(shè)置最大同時(shí)客戶端連接數(shù)
6. MEMORY MANAGEMENT 內(nèi)存管理
·最大內(nèi)存限制
·達(dá)到最大內(nèi)存限制時(shí)的策略
·使用LRU/LFU/TTL算法時(shí)采樣率
·從庫不淘汰數(shù)據(jù)
·過期keys駐留在內(nèi)存中的比例
7. LAZY FREEING 懶惰刪除
8. THREADED I/O
·配置IO線程數(shù)
9. KERNEL OOM CONTROL 設(shè)置OOM時(shí)終止哪些進(jìn)程
10. APPEND ONLY MODE AOF持久化配置
·開始/關(guān)閉aof
·aof文件名稱
·執(zhí)行fsync()系統(tǒng)調(diào)用刷盤的頻率
·當(dāng)有后臺(tái)保存任務(wù)時(shí)，關(guān)閉appendfsync
·自動(dòng)重寫aof文件
·AOF文件末尾被截?cái)?/p>
·開啟混合持久化
11. LUA SCRIPTING-LUA腳本相關(guān)
·配置LUA腳本最大執(zhí)行時(shí)長
12. REDIS CLUSTER 集群配置
·允許集群模式
·集群配置文件
·節(jié)點(diǎn)超時(shí)時(shí)間
·設(shè)置副本有效因子
·設(shè)置master故障轉(zhuǎn)移時(shí)保留的最少副本數(shù)
·哈希槽全覆蓋檢查
·是否自動(dòng)故障轉(zhuǎn)移
·集群失敗時(shí)允許節(jié)點(diǎn)處理讀請求
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 高級(jí)設(shè)置
·設(shè)置Hash底層數(shù)據(jù)結(jié)構(gòu)由ziplist轉(zhuǎn)為hashtable的閾值
·設(shè)置List底層數(shù)據(jù)結(jié)構(gòu)quicklist中單個(gè)ziplist的大小
·設(shè)置壓縮List中ziplist為quicklistLZF結(jié)構(gòu)
·設(shè)置Set底層intset最大entities個(gè)數(shù)/intset升級(jí)為hashtable的閾值
·設(shè)置ZSet底層數(shù)據(jù)結(jié)構(gòu)由ziplist轉(zhuǎn)為skiplist的閾值
·設(shè)置HyperLogLog底層稀疏矩陣轉(zhuǎn)為稠密矩陣的閾值
·自定義Stream宏節(jié)點(diǎn)大小
·開啟Rehash
·客戶端輸出緩存控制
·配置客戶端query buffer大小
·Redis協(xié)議批量請求單個(gè)字符串限制
·Redis執(zhí)行任務(wù)頻率
·動(dòng)態(tài)hz配置
·AOF重寫時(shí)執(zhí)行fsync刷盤策略
·保存RDB文件時(shí)執(zhí)行fsync刷盤策略
·LFU設(shè)置
19. ACTIVE DEFRAGMENTATION 碎片整理
1. Units
·配置數(shù)據(jù)單位換算關(guān)系
################## 該部分用于指定存儲(chǔ)單位的大小換算關(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.conf2. Network 網(wǎng)絡(luò)相關(guān)
·bind IP1 [IP2 …]
這項(xiàng)配置綁定的IP并不是遠(yuǎn)程訪問的客戶端的IP地址，而是本機(jī)的IP地址。
# bind 192.168.1.100 10.0.0.1 # bind 127.0.0.1 ::1 bind 127.0.0.1本機(jī)的IP地址是和網(wǎng)卡（network interfaces）綁定在一起的，配置這項(xiàng)后，Redis只會(huì)接收來自指定網(wǎng)卡的數(shù)據(jù)包。比如我的主機(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可以遠(yuǎn)程連接的話，就需要讓Redis監(jiān)聽eht0這塊網(wǎng)卡，也就是要加上配置bind 127.0.0.1 10.0.4.5，這樣既可以本地訪問，也能夠遠(yuǎn)程訪問。（主要bind只能有一行配置，如果有多個(gè)網(wǎng)卡要監(jiān)聽，就配置多個(gè)ip，用空格隔開，否者只有配置的最后一個(gè)bind生效）。
·保護(hù)模式 protected-mode
從注釋信息就可以看到，如果protected-mode是yes的話，如果沒有指定bind或者沒有指定密碼，那么只能本地訪問。
protected-mode yes·端口號(hào) port
配置Redis監(jiān)聽的端口號(hào)，默認(rè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半連接隊(duì)列長度配置 tcp-backlog
在進(jìn)行TCP/IP連接時(shí)，內(nèi)核會(huì)維護(hù)兩個(gè)隊(duì)列
- 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ù)配置里的注釋，需要同時(shí)提高somaxconn和tcp_max_syn_backlog的值來確保生效。
tcp-backlog 511·是否超時(shí)無操作關(guān)閉連接 timeout
客戶端經(jīng)過多少時(shí)間（單位秒）沒有操作就關(guān)閉連接，0代表永不關(guān)閉。
timeout 0·TCP連接?；畈呗?tcp-keepalive
TCP連接?；畈呗?#xff0c;可以通過tcp-keepalive配置項(xiàng)來進(jìn)行設(shè)置，單位為秒，假如設(shè)置為60秒，則server端會(huì)每60秒向連接空閑的客戶端發(fā)起一次ACK請求，以檢查客戶端是否已經(jīng)掛掉，對于無響應(yīng)的客戶端則會(huì)關(guān)閉其連接。如果設(shè)置為0，則不會(huì)進(jìn)行保活檢測。
tcp-keepalive 3003. GENERAL 通用配置
·啟動(dòng)方式 daemonize
是否以守護(hù)（后臺(tái)）進(jìn)程的方式啟動(dòng)，默認(rèn)no。
daemonize yes·進(jìn)程pid文件 pidfile
redis啟動(dòng)后會(huì)把pid寫入到pidfile指定的文件中。
pidfile /var/run/redis_6379.pid·日志相關(guān) loglevel logfile
loglevel用于配置日志打印機(jī)別，默認(rèn)notice：
- debug：能設(shè)置的最高的日志級(jí)別，打印所有信息，包括debug信息。
- verbose：打印除了debug日志之外的所有日志。
- notice：打印除了debug和verbose級(jí)別的所有日志。
- warning：僅打印非常重要的信息。
·指定數(shù)據(jù)庫的數(shù)量 databse
redis默認(rèn)有16個(gè)數(shù)據(jù)庫，編號(hào)從0開始。
databases 16·啟動(dòng)是否顯示logo
always-show-logo yes4. 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很快，所以被破解密碼時(shí)，性能也很好，如果你的密碼太渣渣了，那么可能很快就被破解了，因此盡量使用長且不容易被猜到的密碼作為redis的訪問密碼。
·配置ACL
ACL：訪問控制列表。
有兩種方法配置ACL：
-
-
- 在命令行通過ACL命令進(jìn)行配置
- 在Redis配置文件中開始，可以直接在redis.conf中配置，也可以通過外部aclfile配置。aclfile path。
-
配置語法：
user <username> ... acl rules ...，
例如： user worker +@list +@connection ~jobs:* on >ffa9203c493aa99
redis默認(rèn)有一個(gè)default用戶。如果default具有nopass規(guī)則（就是說沒有配置密碼），那么新連接將立即作為default用戶登錄，無需通過AUTH命令提供任何密碼。否則，連接會(huì)在未驗(yàn)證狀態(tài)下啟動(dòng)，并需要AUTH驗(yàn)證才能開始工作。
描述用戶可以做的操作的ACL規(guī)則如下：
- 啟用或禁用用戶（已經(jīng)建立的連接不會(huì)生效）
-
- on 啟用用戶，該用戶可以驗(yàn)證身份登陸。
- off 禁用用戶，該用戶不允許驗(yàn)證身份登陸。
- 允許/禁止用戶執(zhí)行某些命令
-
- +<command> 允許用戶執(zhí)行command指示的命令?
- -<command> 禁止用戶執(zhí)行command指示的命令🈲
- +@<category> 允許用戶執(zhí)行category分類中的所有命令?
- -@<category> 禁止用戶執(zhí)行category分類中的所有命令🈲
- +<command>|subcommand 允許執(zhí)行某個(gè)被禁止的command的子命令subcommand。沒有對應(yīng)的-規(guī)則。?
- allcommands +@all的別名，允許執(zhí)行所有命令。?
- nocommands -@all的別名，禁止執(zhí)行所有命令。🈲
- 允許/禁止用戶訪問某些Key
-
- ~<pattern> 添加用戶可以訪問的Key，比如~*代表用戶可以訪問所有key，~K*代表用戶可訪問以K開頭的key。?
- allkeys 等價(jià)于~*?
- resetkeys ~<pattern> 刷新允許模式的列表，會(huì)覆蓋之前設(shè)置的模式。例如 user test ~* resetkeys ~K*，則只允許訪問匹配K*的鍵，~*失效。?
- 為用戶配置有效密碼
-
- ><password> 將密碼添加到用戶的有效密碼列表中。例如user test >mypass on，則用戶test可以使用mypass驗(yàn)證。
- <<password> 將密碼從用戶的有效密碼列表中刪除，即不可以使用該密碼驗(yàn)證。
- nopass 使用任意密碼都可以成功驗(yàn)證。
- resetpass 清除用戶可用密碼列表的數(shù)據(jù)，并清除 nopass 狀態(tài)。之后該用戶不能登陸。直到重新設(shè)置密碼/設(shè)置nopass。
- reset 重置用戶到初始狀態(tài)。該命令會(huì)執(zhí)行以下操作：resetpass, resetkeys, off,-@all。
·ACL日志配置
設(shè)置ACL日志最大長度，默認(rèn)128個(gè)記錄。這個(gè)日志是存在內(nèi)存里的。
acllog-max-len 128·外部ACL文件配置
默認(rèn)位置etc/redis/users.acl，我們可以在這個(gè)文件中定義所有用戶的ACL控制信息。
aclfile /etc/redis/users.acl·配置默認(rèn)用戶default的密碼
該配置只對默認(rèn)用戶default生效。
requirepass yourpass5. CLIENTS 客戶端配置
·設(shè)置最大同時(shí)客戶端連接數(shù)
設(shè)置可以同時(shí)連接客戶端的最大數(shù)量。默認(rèn)該項(xiàng)設(shè)置為 10000 個(gè)客戶端。達(dá)到限制值后的連接會(huì)被拒絕并會(huì)返回錯(cuò)誤信息。
maxclients 100006. MEMORY MANAGEMENT 內(nèi)存管理
·最大內(nèi)存限制
指定Redis最大內(nèi)存限制。達(dá)到內(nèi)存限制時(shí)，Redis將嘗試刪除已到期或即將到期的Key。
maxmemory <bytes>·達(dá)到最大內(nèi)存限制時(shí)的策略
配置達(dá)到最大內(nèi)存限制后，Redis進(jìn)行何種操作。默認(rèn)noeviction
maxmemory-policy noeviction總共有8種策略可供選擇：
-
- volatile-lru 只對設(shè)置了過期時(shí)間的Key進(jìn)行淘汰，淘汰算法近似的LRU。
- allkeys-lru 對所有Key進(jìn)行淘汰，LRU。
- volatile-lfu 只對設(shè)置了過期時(shí)間的Key進(jìn)行淘汰，淘汰算法近似的LFU。
- allkeys-lfu 對所有Key進(jìn)行淘汰，LFU。
- volatile-random 只對設(shè)置了過期時(shí)間的Key進(jìn)行淘汰，淘汰算法為隨機(jī)淘汰。
- allkeys-random 對所有Key進(jìn)行淘汰，隨機(jī)淘汰。
- volatile-ttl 只對設(shè)置了過期時(shí)間的Key進(jìn)行淘汰，刪除即將過期的即ttl最小的。
- noeviction 永不刪除key，達(dá)到最大內(nèi)存再進(jìn)行數(shù)據(jù)裝入時(shí)會(huì)返回錯(cuò)誤。
對于可以通過刪除key來釋放內(nèi)存的策略，如果沒有key可以刪除了，那么也會(huì)報(bào)錯(cuò)。
·使用LRU/LFU/TTL算法時(shí)采樣率
Redis使用的是近似的LRU/LFU/minimal TTL算法。主要是為了節(jié)約內(nèi)存以及提升性能。Redis配置文件有maxmemory-samples選項(xiàng)，可以配置每次取樣的數(shù)量。Redis每次會(huì)選擇配置數(shù)量的key，然后根據(jù)算法從中淘汰最差的key。
maxmemory-samples 5可以通過修改這個(gè)配置來獲取更高的淘汰精度或者更好的性能。默認(rèn)值5就可以獲得很好的結(jié)果。選擇10可以非常接近真是的LRU算法，但是會(huì)耗費(fèi)更多的CPU資源。3的話更快但是淘汰結(jié)果不是特別準(zhǔn)確。
·從庫不淘汰數(shù)據(jù)
配置Redis主從復(fù)制時(shí)，從庫超過maxmemory也不淘汰數(shù)據(jù)。這個(gè)配置主要是為了保證主從庫的一致性，因?yàn)镽edis的淘汰策略是隨機(jī)的，如果允許從庫自己淘汰key，那么會(huì)導(dǎo)致主從不一致的現(xiàn)象出現(xiàn)（master節(jié)點(diǎn)刪除key的命令會(huì)同步給slave節(jié)點(diǎn)）。
replica-ignore-maxmemory yes·過期keys駐留在內(nèi)存中的比例
設(shè)置過期keys仍然駐留在內(nèi)存中的比重，默認(rèn)是為1，表示最多只能有10%的過期key駐留在內(nèi)存中，該值設(shè)置的越小，那么在一個(gè)淘汰周期內(nèi)，消耗的CPU資源也更多，因?yàn)樾枰獙?shí)時(shí)刪除更多的過期key。
active-expire-effort 17. 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有兩個(gè)刪除keys的原語。一個(gè)是DEL并且它是一個(gè)阻塞的刪除對象的操作。意味著server會(huì)停止處理新的command以便以同步的方式回收與對象關(guān)聯(lián)的所有內(nèi)存。如果被刪除的key關(guān)聯(lián)的是一個(gè)小對象，那么執(zhí)行DEL命令所需要的時(shí)間非常短，與Redis中其它O(1)或O(log_N)的命令時(shí)間開銷幾乎一樣。然而，如果key與包含了數(shù)百萬個(gè)元素的大對象相關(guān)聯(lián)，那么服務(wù)器為了完成刪除命令會(huì)阻塞很長時(shí)間（甚至幾秒鐘）。
出于以上原因，Redis提供了非阻塞的刪除原語，例如UNLINK(非阻塞式的DEL)和FLUSHALL、FLUSHDB命令的ASYNC選項(xiàng)，以便在后臺(tái)回收內(nèi)存。這些命令會(huì)在常量（固定的）時(shí)間內(nèi)執(zhí)行。另外一個(gè)線程會(huì)在后臺(tái)盡可能快的以漸進(jìn)式的方式釋放對象。
使用DEL,UNLINK以及FLUSHALL和FLUSHDB的ASYNC選項(xiàng)是由用戶來控制的。這應(yīng)該由應(yīng)用程序的設(shè)計(jì)來決定使用其中的哪一個(gè)。 然而，作為其它操作的副作用，Redis server有時(shí)不得不去刪除keys或者刷新整個(gè)數(shù)據(jù)庫。具體來說，Redis在以下情況下會(huì)獨(dú)立于用戶調(diào)用而刪除對象：
1） 由于maxmemory 和maxmemory policy的設(shè)置，為了在不超出指定的內(nèi)存限制而為新對象騰出空間而逐出舊對象；
2） 因?yàn)檫^期：當(dāng)一個(gè)key設(shè)置了過期時(shí)間且必須從內(nèi)存中刪除時(shí)；
3） 由于在已經(jīng)存在的key上存儲(chǔ)對象的命令的副作用。例如，RENAME命令可能會(huì)刪除舊的key的內(nèi)容，當(dāng)該key的內(nèi)容被其它內(nèi)容代替時(shí)。類似的，SUNIONSTORE或者帶STORE選項(xiàng)的SORT命令可能會(huì)刪除已經(jīng)存在的keys。SET命令會(huì)刪除指定鍵的任何舊內(nèi)容，以便使用指定字符串替換。
4）在復(fù)制過程中，當(dāng)從庫與主庫執(zhí)行完全重新同步時(shí)，整個(gè)數(shù)據(jù)庫的內(nèi)容將被刪除，以便加載剛剛傳輸?shù)腞DB文件。
在上述所有情況下，默認(rèn)情況是以阻塞方式刪除對象，就像調(diào)用DEL一樣。但是，你可以使用以下配置指令專門配置每種情況，以非阻塞的方式釋放內(nèi)存，就像調(diào)用UNLINK一樣。
相關(guān)的配置：
# 內(nèi)存達(dá)到設(shè)置的maxmemory時(shí)，是否使用惰性刪除，對應(yīng)上面 1） lazyfree-lazy-eviction no # 過期keys是否惰性刪除，對應(yīng)上面 2） lazyfree-lazy-expire no # 內(nèi)部刪除選項(xiàng)，對應(yīng)上面選項(xià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)用可能并不是一件 # 容易的事，因此可以使用以下選項(xiàng)，將DEL的行為替換為UNLINK lazyfree-lazy-user-del no8. THREADED I/O
Redis大體上是單線程的，但是也有一些場景使用額外的線程去做的，比如UNLINK、slow I/O accesses。
現(xiàn)在還可以在不同的I/O線程中處理Redis客戶端socket讀寫。（只是網(wǎng)絡(luò)IO這塊兒成了多線程，執(zhí)行命令的那個(gè)家伙，還是單線程！）特別是因?yàn)閷懖僮骱苈?#xff0c;通常Redis的用戶使用pipeline來提升每個(gè)核心下的Redis性能，并且運(yùn)行多個(gè)Redis實(shí)例來實(shí)現(xiàn)擴(kuò)展。使用多線程I/O，不需要使用pipeline和實(shí)例切分，就可以輕松的提升兩倍的性能。
默認(rèn)情況下，多線程是禁用的，我們建議只在至少有4個(gè)或更多內(nèi)核的機(jī)器中啟用多線程，至少保留一個(gè)備用內(nèi)核。使用超過8個(gè)線程不太可能有多大幫助。我們還建議僅當(dāng)您確實(shí)存在性能問題時(shí)才使用線程化I/O，因?yàn)槌荝edis實(shí)例能夠占用相當(dāng)大的CPU時(shí)間，否則使用此功能沒有意義。
·配置IO線程數(shù)
如果你的機(jī)器是4核的，可以配置2個(gè)或者3個(gè)線程。如果你有8核，可以配置6個(gè)線程。通過下面這個(gè)參數(shù)來配置線程數(shù)：
io-threads 4將io-threads設(shè)置為1將只使用主線程。當(dāng)啟用I/O線程時(shí)，我們只使用多線程進(jìn)行寫操作，也就是說，執(zhí)行write(2)系統(tǒng)調(diào)用并將Client緩沖區(qū)傳輸?shù)教捉幼?。但?#xff0c;也可以通過將以下配置指令設(shè)置為yes來啟用讀取線程和協(xié)議解析：
io-threads-do-reads no通常情況下多線程的read并沒有什么卵用。
需要注意的兩點(diǎn)是：
- 這兩個(gè)配置不能運(yùn)行時(shí)通過CONFIG SET來改變，而且開啟SSL功能時(shí)，多線程I/O同樣不會(huì)生效。
- 如果你想用benchmark腳本測試多線程下的性能提升，確保benchmark也是多線程模式，在后面加上--threads參數(shù)，來匹配Redis的線程數(shù)。不然看不到什么性能提升。
9. KERNEL OOM CONTROL 設(shè)置OOM時(shí)終止哪些進(jìn)程
KERNEL OOM CONTROL：
KERNEL ：核心
OOM：Out Of Memory(內(nèi)存溢出)
在Linux上，可以提示內(nèi)核OOM killer在OOM發(fā)生時(shí)應(yīng)該首先終止哪些進(jìn)程。
啟用此功能可使Redis根據(jù)其角色主動(dòng)控制其所有進(jìn)程的oom_score_adj值。默認(rèn)分?jǐn)?shù)將嘗試在所有其他進(jìn)程之前殺死背景子進(jìn)程，并在主進(jìn)程之前殺死從節(jié)點(diǎn)進(jìn)程。
Redis支持三個(gè)選項(xiàng)：
-
- no：對oom-score-adj不做任何修改（默認(rèn)值）
- yes：relative的別名
- absolute：oom-score-adj-values配置的值將寫入內(nèi)核
- relative：當(dāng)服務(wù)器啟動(dòng)時(shí)，使用相對于oom_score_adj初始值的值，然后將其限制在-1000到1000的范圍內(nèi)。因?yàn)槌跏贾低ǔ?，所以它們通常與絕對值匹配。
當(dāng)使用oom-score-adj選項(xiàng)（不為no）時(shí)，該指令控制用于主、從和后臺(tái)子進(jìn)程的特定值。數(shù)值范圍為-2000到2000（越高意味著死亡的可能性越大）。
非特權(quán)進(jìn)程（不是根進(jìn)程，也沒有CAP_SYS_RESOURCE功能）可以自由地增加它們的價(jià)值，但不能將其降低到初始設(shè)置以下。這意味著將oom score adj設(shè)置為“相對”，并將oom score adj值設(shè)置為正值將始終成功
# 分別控制主進(jìn)程、從進(jìn)程和后臺(tái)子進(jìn)程的值 oom-score-adj-values 0 200 80010. APPEND ONLY MODE AOF持久化配置
·開始/關(guān)閉aof
appendonly no·aof文件名稱
appendfilename "appendonly.aof"·執(zhí)行fsync()系統(tǒng)調(diào)用刷盤的頻率
appendfsync everysec-
- everysec：每秒執(zhí)行，可能會(huì)丟失最后一秒的數(shù)據(jù)。
- always：每次寫操作執(zhí)行，數(shù)據(jù)最安全，但是對性能有影響。
- no：不強(qiáng)制刷盤，由內(nèi)核決定什么時(shí)候刷盤，數(shù)據(jù)最不安全，性能最好。
·當(dāng)有后臺(tái)保存任務(wù)時(shí)，關(guān)閉appendfsync
當(dāng)后臺(tái)在執(zhí)行save任務(wù)或者aof文件的rewrite時(shí)，會(huì)對磁盤造成大量I/O操作，在某些Linux配置中，Redis可能會(huì)在fsync()系統(tǒng)調(diào)用上阻塞很長時(shí)間。需要注意的是，目前還沒有很好的解決方法，因?yàn)榧词故窃诓煌木€程中執(zhí)行fsync()調(diào)用也會(huì)阻塞write(2)調(diào)用。
為了緩解上述問題，可以使用以下選項(xiàng)，防止在進(jìn)行BGSAVE或者BGREWRITEAOF時(shí)在主進(jìn)程中調(diào)用fsync()。
-
- SAVE 直接調(diào)用 rdbSave函數(shù) ，阻塞 Redis 主進(jìn)程，直到保存完成為止。在主進(jìn)程阻塞期間，服務(wù)器不能處理客戶端的任何請求。（如果數(shù)據(jù)量小，用此命令可能感覺不出有什么區(qū)別，但是當(dāng)數(shù)據(jù)量很大的時(shí)候，就需要謹(jǐn)慎使用這個(gè)命令。）
- BGSAVE 命令執(zhí)行之后立即返回 OK ，然后 Redis fork 出一個(gè)新子進(jìn)程，原來的 Redis 進(jìn)程(父進(jìn)程)繼續(xù)處理客戶端請求，而子進(jìn)程則負(fù)責(zé)將數(shù)據(jù)保存到磁盤，然后退出。（BGSAVE方式比較適合線上的維護(hù)操作。）
這意味這如果有其它子進(jìn)程在執(zhí)行saving任務(wù)時(shí)，Redis的行為相當(dāng)于配置了appendfsync none。實(shí)際上，這意味著在最壞的情況下（使用Linux默認(rèn)設(shè)置），可能丟失最多30s的日志。
如果您有延遲的問題（性能問題），將此設(shè)置為“yes”，否則，設(shè)置為“no”。從持久化的角度看，這是最安全的選擇。
no-appendfsync-on-rewrite no·自動(dòng)重寫aof文件
在AOF文件大小增長到了指定的百分比（相對于上次AOF文件大小的增長量）或者最小體積時(shí)，自動(dòng)調(diào)用BGREWRITEAOF命令重寫AOF文件。
auto-aof-rewrite-percentage 100 #aof文件的大小超過基準(zhǔn)百分之多少后觸發(fā)重寫（100默認(rèn)值，2倍的意思） auto-aof-rewrite-min-size 64mb #當(dāng)前aof文件大于多少字節(jié)后才觸發(fā)重寫·AOF文件末尾被截?cái)?/h2>
在Redis啟動(dòng)過程的最后，當(dāng)AOF數(shù)據(jù)加載回內(nèi)存時(shí)，可能會(huì)發(fā)現(xiàn)AOF文件被截?cái)?。?dāng)運(yùn)行Redis的系統(tǒng)崩潰時(shí)，可能會(huì)發(fā)生這種情況，尤其是在安裝ext4文件系統(tǒng)時(shí)，沒有data=ordered選項(xiàng)（然而，當(dāng)Redis本身崩潰或中止，但操作系統(tǒng)仍然正常工作時(shí)，這種情況不會(huì)發(fā)生）。
Redis可以在出現(xiàn)這種情況時(shí)帶著錯(cuò)誤退出，也可以加載盡可能多的數(shù)據(jù)（現(xiàn)在是默認(rèn)值），并在發(fā)現(xiàn)AOF文件在最后被截?cái)鄷r(shí)啟動(dòng)。以下選項(xiàng)控制此行為。
如果aof load truncated設(shè)置為yes，則會(huì)加載一個(gè)被截?cái)嗟腶of文件，Redis服務(wù)器開始發(fā)送日志，通知用戶該事件。否則，如果該選項(xiàng)設(shè)置為“no”，服務(wù)器將因錯(cuò)誤而中止并拒絕啟動(dòng)。當(dāng)選項(xiàng)設(shè)置為“no”時(shí)，用戶需要使用“redis-check-aof”實(shí)用程序修復(fù)AOF文件，然后才能重新啟動(dòng)服務(wù)器。
請注意，如果在中間發(fā)現(xiàn)AOF文件已損壞，服務(wù)器仍將退出并出現(xiàn)錯(cuò)誤。此選項(xiàng)僅適用于Redis嘗試從AOF文件讀取更多數(shù)據(jù)，但找不到足夠字節(jié)的情況。
aof-load-truncated yes·開啟混合持久化
當(dāng)重寫AOF文件時(shí)，Redis能夠在AOF文件中使用RDB前導(dǎo)，以更快地重寫和恢復(fù)。啟用此選項(xiàng)后，重寫的AOF文件由兩個(gè)不同的節(jié)組成：
[RDB file][AOF tail]
加載時(shí)，Redis識(shí)別出AOF文件以“Redis”字符串開頭，并加載帶前綴的RDB文件，然后繼續(xù)加載AOF尾部。
aof-use-rdb-preamble yes11. LUA SCRIPTING-LUA腳本相關(guān)
·配置LUA腳本最大執(zhí)行時(shí)長
單位毫秒，默認(rèn)5s。當(dāng)腳本運(yùn)行時(shí)間超過限制后，Redis將開始接受其他命令當(dāng)不會(huì)執(zhí)行，而是會(huì)返回BUSY錯(cuò)誤。
lua-time-limit 500012. REDIS CLUSTER 集群配置
·允許集群模式
只有以集群模式啟動(dòng)的Redis實(shí)例才能作為集群的節(jié)點(diǎn)
cluster-enabled yes·集群配置文件
由Redis創(chuàng)建維護(hù)，不需要我們關(guān)心內(nèi)容，只需要配好位置即可
cluster-config-file nodes-6379.conf·節(jié)點(diǎn)超時(shí)時(shí)間
集群模式下，master節(jié)點(diǎn)之間會(huì)互相發(fā)送PING心跳來檢測集群master節(jié)點(diǎn)的存活狀態(tài)，超過配置的時(shí)間沒有得到響應(yīng)，則認(rèn)為該master節(jié)點(diǎn)主觀宕機(jī)。
cluster-node-timeout 15000·設(shè)置副本有效因子
副本數(shù)據(jù)太老舊就不會(huì)被選為故障轉(zhuǎn)移的啟動(dòng)者。
副本沒有簡單的方法可以準(zhǔn)確測量其“數(shù)據(jù)年齡”，因此需要執(zhí)行以下兩項(xiàng)檢查：
-
- 如果有多個(gè)復(fù)制副本能夠進(jìn)行故障切換，則它們會(huì)交換消息，以便嘗試為具有最佳復(fù)制偏移量的副本提供優(yōu)勢（已經(jīng)從master接收了盡可能多的數(shù)據(jù)的節(jié)點(diǎn)更可能成為新master）。復(fù)制副本將嘗試按偏移量獲取其排名，并在故障切換開始時(shí)應(yīng)用與其排名成比例的延遲（排名越靠前的越早開始故障遷移）。
- 每個(gè)副本都會(huì)計(jì)算最后一次與其主副本交互的時(shí)間。這可以是最后一次收到的PING或命令（如果主機(jī)仍處于“已連接”狀態(tài)），也可以是與主機(jī)斷開連接后經(jīng)過的時(shí)間（如果復(fù)制鏈路當(dāng)前已關(guān)閉）。如果最后一次交互太舊，復(fù)制副本根本不會(huì)嘗試故障切換。
第二點(diǎn)的值可以由用戶調(diào)整。特別的，如果自上次與master交互以來，經(jīng)過的時(shí)間大于(node-timeout * cluster-replica-validity-factor) + repl-ping-replica-period，則不會(huì)成為新的master。
較大的cluster-replica-validity-factor可能允許數(shù)據(jù)太舊的副本故障切換到主副本，而太小的值可能會(huì)阻止群集選擇副本。
為了獲得最大可用性，可以將cluster-replica-validity-factor設(shè)置為0，這意味著，無論副本上次與主機(jī)交互的時(shí)間是什么，副本都將始終嘗試故障切換主機(jī)。（不過，他們總是會(huì)嘗試應(yīng)用與其偏移等級(jí)成比例的延遲）。
0是唯一能夠保證當(dāng)所有分區(qū)恢復(fù)時(shí)，集群始終能夠繼續(xù)的值（保證集群的可用性）。
cluster-replica-validity-factor 10·設(shè)置master故障轉(zhuǎn)移時(shí)保留的最少副本數(shù)
群集某個(gè)master的slave可以遷移到孤立的master，即沒有工作slave的master。這提高了集群抵御故障的能力，因?yàn)槿绻铝aster沒有工作slave，則在發(fā)生故障時(shí)無法對其進(jìn)行故障轉(zhuǎn)移。
只有在slave的舊master的其他工作slave的數(shù)量至少為給定數(shù)量時(shí)，slave才會(huì)遷移到孤立的master。這個(gè)數(shù)字就是cluster-migration-barrier。值為1意味著slave只有在其master至少有一個(gè)其他工作的slave時(shí)才會(huì)遷移，以此類推。它通常反映集群中每個(gè)主機(jī)所需的副本數(shù)量。
默認(rèn)值為1（僅當(dāng)副本的主副本至少保留一個(gè)副本時(shí)，副本才會(huì)遷移）。要禁用遷移，只需將其設(shè)置為非常大的值。可以設(shè)置值0，但僅對調(diào)試有用，并且在生產(chǎn)中很危險(xiǎn)。
cluster-migration-barrier 1 # 一個(gè)主節(jié)點(diǎn)在擁有幾個(gè)從節(jié)點(diǎn)的時(shí)候，才會(huì)可能割讓一個(gè)從節(jié)點(diǎn)·哈希槽全覆蓋檢查
默認(rèn)情況下，如果Redis群集節(jié)點(diǎn)檢測到至少有一個(gè)未覆蓋的哈希槽（沒有可用的節(jié)點(diǎn)為其提供服務(wù)），它們將停止接受查詢。這樣，如果集群部分關(guān)閉（例如，一系列哈希槽不再被覆蓋），那么所有集群最終都將不可用。一旦所有插槽再次被覆蓋，它就會(huì)自動(dòng)返回可用狀態(tài)。
然而，有時(shí)您希望正在工作的集群的子集繼續(xù)接受對仍然覆蓋的密鑰空間部分的查詢。為此，只需將cluster-require-full-coverage選項(xiàng)設(shè)置為no。
cluster-require-full-coverage yes·是否自動(dòng)故障轉(zhuǎn)移
當(dāng)設(shè)置為“yes”時(shí)，此選項(xiàng)可防止副本在主機(jī)故障期間嘗試故障切換master。但是，如果被迫這樣做，主機(jī)仍然可以執(zhí)行手動(dòng)故障切換。
這在不同的場景中很有用，尤其是在多個(gè)數(shù)據(jù)中心運(yùn)營的情況下，如果不在DC（DataCenter？）完全故障的情況下，我們希望其中一方永遠(yuǎn)不會(huì)升級(jí)為master。
cluster-replica-no-failover no·集群失敗時(shí)允許節(jié)點(diǎn)處理讀請求
此選項(xiàng)設(shè)置為“yes”時(shí)，允許節(jié)點(diǎn)在集群處于關(guān)閉狀態(tài)時(shí)提供讀取流量，只要它認(rèn)為自己擁有這些插槽。
這對兩種情況很有用：
-
- 第一種情況適用于在節(jié)點(diǎn)故障或網(wǎng)絡(luò)分區(qū)期間應(yīng)用程序不需要數(shù)據(jù)一致性的情況。其中一個(gè)例子是緩存，只要節(jié)點(diǎn)擁有它應(yīng)該能夠?yàn)槠涮峁┓?wù)的數(shù)據(jù)。
- 第二個(gè)用例適用于不滿足三個(gè)分片集群，但又希望啟用群集模式并在以后擴(kuò)展的配置。不設(shè)置該選項(xiàng)而使用1或2分片配置中的master中斷服務(wù)會(huì)導(dǎo)致整個(gè)集群的讀/寫服務(wù)中斷。如果設(shè)置此選項(xiàng)，則只會(huì)發(fā)生寫中斷。如果達(dá)不到master的quorum（客觀宕機(jī)）數(shù)值，插槽所有權(quán)將不會(huì)自動(dòng)更改。
13. CLUSTER DOCKER/NAT support
·聲明訪問IP、port
以下三項(xiàng)設(shè)置對NAT網(wǎng)絡(luò)或者Docker的支持。
因?yàn)镹AT端口映射的IP地址在局域網(wǎng)之外是沒辦法訪問到的，因此在這種情況下，要聲明集群的公網(wǎng)網(wǎng)關(guān)（NAT映射）/宿主機(jī)的IP地址，以便局域網(wǎng)之外也可以訪問到NAT映射后的/Docker容器內(nèi)的Redis集群中的每個(gè)實(shí)例。
cluster-announce-bus-port集群節(jié)點(diǎn)之間進(jìn)行數(shù)據(jù)交換的額外端口。
cluster-announce-ip cluster-announce-port cluster-announce-bus-port14. SLOW LOG 慢日志
Redis的慢查詢?nèi)罩竟δ苡糜谟涗泩?zhí)行時(shí)間超過給定時(shí)長的命令請求，用戶可以通過這個(gè)功能產(chǎn)生的日志來監(jiān)視和優(yōu)化查詢速度
·設(shè)置慢日志記錄閾值
超過這個(gè)值的命令會(huì)被記錄到慢日志中，默認(rèn)10000微秒。
slowlog-log-slower-than <microseconds>·慢日志文件大小
可以通過這個(gè)配置改變慢日志文件的最大長度，超過這個(gè)長度后最舊的記錄會(huì)被刪除。默認(rèn)128。
slowlog-max-len 12815. LATENCY MONITOR 延遲監(jiān)控
Redis延遲監(jiān)控子系統(tǒng)在運(yùn)行時(shí)對不同的操作進(jìn)行采樣，以收集與Redis實(shí)例可能的延遲源相關(guān)的數(shù)據(jù)。
通過延遲命令，用戶可以打印圖表和獲取報(bào)告。
系統(tǒng)僅記錄在等于或大于通過延遲監(jiān)視器閾值配置指令指定的毫秒數(shù)的時(shí)間內(nèi)執(zhí)行的操作。當(dāng)其值設(shè)置為零時(shí)，延遲監(jiān)視器將關(guān)閉。
默認(rèn)情況下，延遲監(jiān)控是禁用的，因?yàn)槿绻麤]有延遲問題，通常不需要延遲監(jiān)控，而且收集數(shù)據(jù)會(huì)對性能產(chǎn)生影響，雖然影響很小，但可以在大負(fù)載下進(jìn)行測量。如果需要，可以在運(yùn)行時(shí)使用命令CONFIG SET latency-monitor-threshold <millists>輕松啟用延遲監(jiān)控。
·設(shè)置延遲閾值
latency-monitor-threshold 016.EVENT NOTIFICATION 事件通知
Redis keyspace notifications
作用：實(shí)時(shí)的監(jiān)控keys和values的更改。
Redis可以將key space中發(fā)生的事件通過發(fā)布/訂閱通知客戶端。
例如，如果notify-keyspace-events已經(jīng)啟用，并且客戶端對數(shù)據(jù)庫0中存儲(chǔ)的鍵foo執(zhí)行DEL操作，則將通過Pub/Sub發(fā)布兩條消息：
-
- PUBLISH _keyspace@0_:foo del
- PUBLISH _keyevent@0_:del foo
可以在一組類中選擇Redis將通知的事件。每個(gè)類由一個(gè)字符標(biāo)識(shí)：
- 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過期時(shí)生成的事件）
- e 回收事件（達(dá)到maxmemory時(shí)回收key的事件）
- t Stream相關(guān)命令
- m Key-miss events，訪問的key不存在時(shí)觸發(fā)
- A g$lshzxet的別名，因此AKE代表了除了m之外的所有事件。
默認(rèn)情況下所有事件通知都是關(guān)閉的，因?yàn)榇蠖鄶?shù)用戶不需要這些特性。且需要至少有K或者E時(shí)事件通知才會(huì)生效。
notify-keyspace-events ""17. GOPHER SERVER Gopher協(xié)議
開啟Gopher協(xié)議，大體意思就是說這是一個(gè)90年代很流行的Web協(xié)議，客戶端和服務(wù)端實(shí)現(xiàn)都非常簡單，Redis服務(wù)器只需要100行代碼就能支持它。一些人想要一個(gè)更簡單的互聯(lián)網(wǎng)，另一些人認(rèn)為主流互聯(lián)網(wǎng)變得過于受控，為想要一點(diǎn)新鮮空氣的人創(chuàng)造一個(gè)替代空間是很酷的。總之，為了慶祝🎉Redis誕生10周年，Redis的作者將這個(gè)協(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 no18. ADVANCED CONFIG 高級(jí)設(shè)置
·設(shè)置Hash底層數(shù)據(jù)結(jié)構(gòu)由ziplist轉(zhuǎn)為hashtable的閾值
當(dāng)Hash類型的keys只包含了少量的實(shí)體并且實(shí)體的大小沒有超過給定的閾值時(shí)，Hash底層會(huì)使用ziplist來存儲(chǔ)數(shù)據(jù)而不是使用hashtable以節(jié)省空間。
hash-max-ziplist-entries 512 hash-max-ziplist-value 64當(dāng)一個(gè)Hash類型的key包含的實(shí)體數(shù)量超過了hash-max-ziplist-entries的值或者某個(gè)實(shí)體的大小超過了hash-max-ziplist-value的值（單位字節(jié)），那么底層編碼就會(huì)升級(jí)成hashtable。
·設(shè)置List底層數(shù)據(jù)結(jié)構(gòu)quicklist中單個(gè)ziplist的大小
Redis中List數(shù)據(jù)結(jié)構(gòu)的底層使用的是quicklist的數(shù)據(jù)結(jié)構(gòu)，本質(zhì)上是ziplist作為節(jié)點(diǎn)串起來的linkedlist。可以通過該項(xiàng)設(shè)置來改變每個(gè)ziplist的最大大小（ziplist中的fill屬性，超過這個(gè)值就會(huì)開啟一個(gè)新的ziplist）?？偣蔡峁┝?5到-1五個(gè)選項(xiàng)：
- -5：最大大小為64Kb，不推薦作為正常情況下的負(fù)載
- -4：最大大小為32Kb，不推薦
- -3：最大大小為16Kb，大概可能估計(jì)好像不是很推薦（原話：probably not recommended）
- -2：最大大小為8Kb，good（原話）
- -1：最大大小為4Kb，good（原話）
默認(rèn)值是-2
list-max-ziplist-size -2·設(shè)置壓縮List中ziplist為quicklistLZF結(jié)構(gòu)
大神們覺著ziplist不夠zip啊，所以再壓縮一下吧。實(shí)際上是考慮了這樣的場景，即List數(shù)據(jù)結(jié)構(gòu)兩端訪問頻率比較高，但是中間部分訪問頻率不是很高的情況，那么使用ziplist存放這部分結(jié)構(gòu)就有點(diǎn)浪費(fèi)，是不是可以把這部分結(jié)構(gòu)進(jìn)行壓縮（LZF算法壓縮）呢？這個(gè)選項(xiàng)就是進(jìn)行這個(gè)操作的。有下面幾個(gè)值：
- 0：代表不壓縮，默認(rèn)值
- 1：兩端各一個(gè)節(jié)點(diǎn)不壓縮
- 2：兩端各兩個(gè)節(jié)點(diǎn)不壓縮
- ...：依次類推。。。
·設(shè)置Set底層intset最大entities個(gè)數(shù)/intset升級(jí)為hashtable的閾值
Set數(shù)據(jù)結(jié)構(gòu)只有在一種情況下會(huì)使用intset來存儲(chǔ)：set由能轉(zhuǎn)成10進(jìn)制且數(shù)值在64bit有符號(hào)整形數(shù)值組成時(shí)。下面的配置設(shè)置了intset能存儲(chǔ)的最大entities數(shù)量，超過這個(gè)數(shù)量會(huì)轉(zhuǎn)成hashtable存儲(chǔ)。默認(rèn)512個(gè)。
set-max-intset-entries 512·設(shè)置ZSet底層數(shù)據(jù)結(jié)構(gòu)由ziplist轉(zhuǎn)為skiplist的閾值
當(dāng)超過下面設(shè)置的閾值時(shí)，ZSet底層存儲(chǔ)結(jié)構(gòu)會(huì)由ziplist轉(zhuǎn)為skiplist。
zset-max-ziplist-entries 128 zset-max-ziplist-value 64·設(shè)置HyperLogLog底層稀疏矩陣轉(zhuǎn)為稠密矩陣的閾值
HyperLogLog當(dāng)在計(jì)數(shù)比較小時(shí)會(huì)使用稀疏矩陣來存儲(chǔ)，只有當(dāng)計(jì)數(shù)達(dá)到閾值時(shí)，才會(huì)轉(zhuǎn)為稠密矩陣。
超過16000的值是完全無用的，因?yàn)檫@種情況下使用稠密矩陣更加節(jié)省內(nèi)存。
建議的值是3000左右，以便在不降低太多PFADD速度的情況下獲取空間有效編碼的好處，稀疏編碼的PFADD的時(shí)間復(fù)雜度為O(N)。當(dāng)不考慮CPU占用時(shí)而考慮內(nèi)存占用時(shí)，這個(gè)值可以升到10000左右。
hll-sparse-max-bytes 3000·自定義Stream宏節(jié)點(diǎn)大小
可以通過stream-node-max-bytes選項(xiàng)修改Stream中每個(gè)宏節(jié)點(diǎn)能夠占用的最大內(nèi)存，或者通過stream-node-max-entries參數(shù)指定每個(gè)宏節(jié)點(diǎn)中可存儲(chǔ)條目的最大數(shù)量。
stream-node-max-bytes 4096 stream-node-max-entries 100·開啟Rehash
Redis將在每100毫秒時(shí)使用1毫秒的CPU時(shí)間來對redis的hash表進(jìn)行重新hash，可以降低內(nèi)存的使用。當(dāng)你的使用場景中，有非常嚴(yán)格的實(shí)時(shí)性需要，不能夠接受Redis時(shí)不時(shí)的對請求有2毫秒的延遲的話，把這項(xiàng)配置為no。如果沒有這么嚴(yán)格的實(shí)時(shí)性要求，可以設(shè)置為yes，以便能夠盡可能快的釋放內(nèi)存。
activerehashing yes·客戶端輸出緩存控制
客戶端輸出緩沖區(qū)限制可用于強(qiáng)制斷開由于某種原因從服務(wù)器讀取數(shù)據(jù)速度不夠快的客戶端（一個(gè)常見原因是發(fā)布/訂閱客戶端不能像發(fā)布服務(wù)器生成消息那樣快地使用消息）。
對于三種不同類型的客戶端，克制設(shè)置不同的限制：
-
- normal：一般客戶端包含監(jiān)控客戶端
- replica：副本客戶端（slave）
- pubsub：客戶端至少訂閱了一個(gè)pubsub通道或模式。
每個(gè)客戶端輸出緩沖區(qū)限制指令語法：
client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>一旦達(dá)到<hard limit>限制或者達(dá)到<soft limit>之后又過了<soft seconds>秒，那么客戶端會(huì)立即被斷開連接。
例如：
如果<hard limit>為32兆字節(jié)，<soft limit>和<soft seconds>分別為16兆字節(jié)，10秒，則如果輸出緩沖區(qū)的大小達(dá)到32兆字節(jié)，客戶端將立即斷開連接，但如果客戶端達(dá)到16兆字節(jié)并連續(xù)超過限制10秒，客戶端也將斷開連接。
默認(rèn)情況下，普通客戶端不受限制，因?yàn)樗鼈儾粫?huì)在沒有請求（以推送方式）的情況下接收數(shù)據(jù)，而是在請求之后接收數(shù)據(jù)，因此只有異步客戶端可能會(huì)創(chuàng)建一個(gè)場景，其中請求數(shù)據(jù)的速度比讀取數(shù)據(jù)的速度快。
相反，pubsub和副本客戶端有一個(gè)默認(rèn)限制，因?yàn)橛嗛喺吆透北疽酝扑头绞浇邮諗?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大小不能超過該項(xiàng)配置的值。
每個(gè)Client都有一個(gè)query buffer(查詢緩存區(qū)或輸入緩存區(qū)), 它用于保存客戶端的發(fā)送命令，redis server從query buffer獲取命令并執(zhí)行。如果程序的Key設(shè)計(jì)不合理，客戶端使用大量的query buffer，這會(huì)導(dǎo)致redis server比較危險(xiǎn)，很容易達(dá)到maxmeory限制，導(dǎo)致緩存數(shù)據(jù)被清空、數(shù)據(jù)無法寫入和oom.
client-query-buffer-limit 1gb·Redis協(xié)議批量請求單個(gè)字符串限制
默認(rèn)512mb，可以通過下面選項(xiàng)修改
proto-max-bulk-len 512mb·Redis執(zhí)行任務(wù)頻率
Redis調(diào)用一個(gè)內(nèi)部函數(shù)來執(zhí)行許多后臺(tái)任務(wù)，比如在超時(shí)時(shí)關(guān)閉客戶端連接，清楚從未被請求過的過期key…
并非所有任務(wù)都已相同的頻率執(zhí)行，但Redis根據(jù)指定的hz值檢查要執(zhí)行的任務(wù)。
默認(rèn)情況下，hz的值為10.提高這個(gè)值會(huì)讓Redis在空閑的時(shí)候占用更多的CPU，但同時(shí)也會(huì)讓Redis在有很多keys同時(shí)過期時(shí)響應(yīng)更快并且可以更精確的處理超時(shí)。
范圍在1到500之間，但是超過100通常不是一個(gè)好主意。大多數(shù)用戶應(yīng)該使用缺省值10，只有在需要非常低延遲的環(huán)境中才應(yīng)該將值提高到100。
hz 10·動(dòng)態(tài)hz配置
根據(jù)客戶端連接的數(shù)量動(dòng)態(tài)的調(diào)整hz的值，當(dāng)有更多的客戶端連接時(shí)，會(huì)臨時(shí)以hz設(shè)置基準(zhǔn)提高該hz的值。默認(rèn)開啟。
dynamic-hz yes·AOF重寫時(shí)執(zhí)行fsync刷盤策略
當(dāng)一個(gè)子系統(tǒng)重寫AOF文件時(shí)，如果啟用了以下選項(xiàng)，則該文件將每生成32MB的數(shù)據(jù)進(jìn)行fsync同步。這對于以更增量的方式將文件提交到磁盤并避免較大的延遲峰值非常有用。
aof-rewrite-incremental-fsync yes·保存RDB文件時(shí)執(zhí)行fsync刷盤策略
當(dāng)redis保存RDB文件時(shí)，如果啟用以下選項(xiàng)，則每生成32 MB的數(shù)據(jù)，文件就會(huì)同步一次。這對于以更增量的方式將文件提交到磁盤并避免較大的延遲峰值非常有用。
rdb-save-incremental-fsync yes·LFU設(shè)置
設(shè)置Redis LFU相關(guān)。Redis LFU淘汰策略實(shí)現(xiàn)有兩個(gè)可調(diào)整參數(shù)：lfu-log-factor和lfu-decay-time。
lfu-log-factor 10 lfu-decay-time 119. ACTIVE DEFRAGMENTATION 碎片整理
主動(dòng)（在線）碎片整理允許Redis服務(wù)器壓縮內(nèi)存中數(shù)據(jù)的少量分配和釋放之間的空間（內(nèi)存碎片），從而回收內(nèi)存。
碎片化是每個(gè)分配器（幸運(yùn)的是，Jemalloc比較少發(fā)生這種情況）和某些工作負(fù)載都會(huì)發(fā)生的自然過程。通常需要重啟服務(wù)器以降低碎片，或者至少清除所有數(shù)據(jù)并重新創(chuàng)建。然而，多虧了Oran Agra為Redis 4.0實(shí)現(xiàn)的這一功能，這個(gè)過程可以在服務(wù)器運(yùn)行時(shí)以“hot”的方式在運(yùn)行時(shí)發(fā)生（類似熱部署的意思，不需要停止服務(wù)）。
基本上，當(dāng)碎片超過某個(gè)級(jí)別（參見下面的配置選項(xiàng)）時(shí)，Redis將通過利用特定的Jemalloc功能（以了解分配是否導(dǎo)致碎片并將其分配到更好的位置）開始在連續(xù)內(nèi)存區(qū)域中創(chuàng)建值的新副本，同時(shí)釋放數(shù)據(jù)的舊副本。對所有鍵遞增地重復(fù)該過程將導(dǎo)致碎片降至正常值。
需要了解的重要事項(xiàng)：
配置參數(shù)能夠微調(diào)碎片整理過程的行為。如果你不確定它們是什么意思，最好不要改變默認(rèn)值。
#開啟活動(dòng)碎片整理 activedefrag no#啟動(dòng)活動(dòng)碎片整理的最小內(nèi)存碎片閾值 active-defrag-ignore-bytes 100mb#啟動(dòng)活動(dòng)碎片整理的最小內(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#使用后臺(tái)線程 jemalloc-bg-thread yes總結(jié)
以上是生活随笔為你收集整理的【Redis】Redis配置文件详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 红帽子linux2017安装,Firef
- 下一篇： spring boot 配置文件