Redis進(jìn)階：配置文件（二）

繼續(xù)我們的配置文件的學(xué)習(xí)，上回我們已經(jīng)學(xué)習(xí)完了整個(gè) Redis 配置文件的前半部分，今天我們就向后半部分進(jìn)發(fā)。這一部分的內(nèi)容說(shuō)實(shí)話有更多的內(nèi)容是更偏門(mén)的，都不知道是干嘛用的。還是那句話，本著了解的態(tài)度，死磕也要過(guò)一遍，以后萬(wàn)一哪天用到了，再詳細(xì)深入的研究也不遲。

MEMORY MANAGEMENT 內(nèi)存管理

內(nèi)存管理的內(nèi)容我們?cè)谥暗奈恼乱埠?jiǎn)單地接觸過(guò)。主要就是最大內(nèi)存容量、內(nèi)存淘汰策略之類(lèi)的設(shè)置。

# 設(shè)置最大內(nèi)存可用數(shù)量
# 之前的文章中也已經(jīng)講到過(guò)了
# maxmemory <bytes>

# 內(nèi)存淘汰策略
# 當(dāng)內(nèi)存容量達(dá)到 maxmemory 設(shè)置的值之后，如何騰出新的內(nèi)存空間
# 就是 LFU 、LRU 那些的，也是在內(nèi)存優(yōu)化部分講過(guò)的，還記得吧
# maxmemory-policy noeviction

# 在進(jìn)行內(nèi)存淘汰的時(shí)候每次檢查幾個(gè)鍵
# LFU、LRU、最小過(guò)期時(shí)間這些算法都是近似算法而不是精確算法
# 它們的速度和準(zhǔn)確性是需要根據(jù)系統(tǒng)資源匹配的
# 一般來(lái)說(shuō) 5 就是比較合適的數(shù)值了
# 如果你想要更精確，比如 LFU 的 10 ，但這樣就需要更多的 CPU 資源
# 設(shè)置成 3 的話速度快，但是精確度就降低了
# maxmemory-samples 5

# 大量淘汰內(nèi)存時(shí)阻塞客戶端的時(shí)間
# maxmemory-eviction-tenacity 10

# 從庫(kù)是否忽略淘汰內(nèi)存限制
# replica-ignore-maxmemory yes

# 清理過(guò)期鍵時(shí)的CPU占比消耗
# 1-10 越大占用CPU資源越多
# active-expire-effort 1

LAZY FREEING 惰性刪除配置

與惰性刪除相對(duì)應(yīng)的就是主動(dòng)刪除。在早期的 Redis 版本中，DEL 之類(lèi)的命令是需要占用主進(jìn)程進(jìn)行刪除的，如果有大鍵需要?jiǎng)h除，那么就很容易出現(xiàn) KEYS * 的效果，也就是主進(jìn)程卡半天。在之后的版本中，出現(xiàn)了惰性刪除，也就是先切斷連接，然后再由子進(jìn)程或線程去進(jìn)行刪除，比如 UNLINK 命令。

# 針對(duì)有配置淘汰策略的情況下，發(fā)生內(nèi)存淘汰時(shí)，是否使用 LazyFree
lazyfree-lazy-eviction no
# 針對(duì)過(guò)期的Key，開(kāi)始刪除清理時(shí)，是否使用 LazyFree
lazyfree-lazy-expire no
# 有些指令在操作時(shí)，如 rename ，會(huì)隱性地帶一個(gè) del 操作，是否使用 LazyFree
lazyfree-lazy-server-del no
# 對(duì)于從庫(kù)，在剛啟動(dòng)，沒(méi)有同步主庫(kù)數(shù)據(jù)前，會(huì)先 FLUSHALL ，這時(shí)是否使用 LazyFree
replica-lazy-flush no

# 修改 del 的默認(rèn)行為，讓它變得和 unlink 一樣
lazyfree-lazy-user-del no

# FLUSHDB, FLUSHALL, 和 SCRIPT FLUSH ，本來(lái)是支持用一個(gè)參數(shù) [SYNC|ASYNC] 來(lái)指定同步還是異步操作的
# 開(kāi)啟這個(gè)之后，就讓它們都變成異步的，不需要加參數(shù)了
lazyfree-lazy-user-flush no

THREADED I/O 線程IO配置

在線程相關(guān)的文章中，我們也已經(jīng)學(xué)習(xí)過(guò)了，就只有兩個(gè)配置。

# 線程數(shù)量
# io-threads 4

# 開(kāi)啟 IO 多線程功能，默認(rèn)是關(guān)閉的
# io-threads-do-reads no

KERNEL OOM CONTROL 內(nèi)核OOM控制

這一塊的配置主要是和 Linux 的 OOM 機(jī)制有關(guān)，下面的注釋中也已經(jīng)寫(xiě)了。對(duì)于 OOM Killer 我也不是太了解，將來(lái)學(xué)習(xí) Linux 相關(guān)的內(nèi)容時(shí)我們?cè)龠M(jìn)行深入的學(xué)習(xí)了解。

# 在 Linux 中，如果內(nèi)存不足會(huì)啟動(dòng) OOM Killer 去殺進(jìn)程
# 開(kāi)啟這個(gè)功能將可以讓 Redis 控制 oom_score_adj 函數(shù)的值
# 在主進(jìn)程被 kill 之前，根據(jù)數(shù)據(jù)庫(kù)的情況去 kill 子進(jìn)程
# 可以配置 no、yes、absolute、relative 等值
oom-score-adj no

# 當(dāng) oom-score-adj 被開(kāi)啟之后，這里就是它的參考值
oom-score-adj-values 0 200 800

KERNEL transparent hugepage CONTROL THP控制

同樣也是 Linux 中的一種機(jī)制，不多贅述，有興趣的小伙伴可以先去搜索了解一下 THP 是干嘛的，其實(shí)也是一種內(nèi)存相關(guān)的優(yōu)化策略。

# 是否啟用 thp 機(jī)制 
disable-thp yes

APPEND ONLY MODE AOF相關(guān)配置

AOF 相關(guān)的配置，我們?cè)诔志没奈恼轮幸矊W(xué)習(xí)過(guò)。一個(gè)是開(kāi)啟 AOF ，一個(gè)是 AOF 持久化方式，這兩個(gè)是比較重要的配置。

# 是否開(kāi)啟 AOF
appendonly no

# AOF 文件名稱
appendfilename "appendonly.aof"

# AOF 持久化方式
# appendfsync always
appendfsync everysec
# appendfsync no

# AOF 在自動(dòng)重寫(xiě)和命令行 bgrewarite 時(shí)會(huì)沖突
# 設(shè)置為 no ，會(huì)阻塞一個(gè)一個(gè)去寫(xiě)
# 設(shè)置為 yes ，先寫(xiě)入緩沖區(qū)，再寫(xiě)文件，如果這時(shí)出現(xiàn)問(wèn)題，可能會(huì)有丟失
no-appendfsync-on-rewrite no

# 重寫(xiě)時(shí)的文件擴(kuò)容優(yōu)化配置
# 學(xué)習(xí) AOF 的時(shí)候講到過(guò)
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# AOF 文件可能因?yàn)楦鞣N原因是不完整的
# 如果選擇的是yes，當(dāng)截?cái)嗟腶of文件被導(dǎo)入的時(shí)候，會(huì)自動(dòng)發(fā)布一個(gè)log給客戶端然后load
# 如果是no，用戶必須手動(dòng)redis-check-aof修復(fù)AOF文件才可以。默認(rèn)值為 yes。
aof-load-truncated yes

# 重寫(xiě)時(shí)是否進(jìn)行 RDB 壓縮
# 之前講過(guò)啦
aof-use-rdb-preamble yes

LUA SCRIPTING LUA腳本配置

LUA 腳本相關(guān)的配置，只有一個(gè)配置選項(xiàng)，就是 Lua 腳本執(zhí)行的超時(shí)時(shí)間。

# 一個(gè)lua腳本執(zhí)行的最大時(shí)間，單位為ms
lua-time-limit 5000

REDIS CLUSTER 分布式相關(guān)配置

Cluster 的配置在相關(guān)的文章中也已經(jīng)學(xué)習(xí)過(guò)了。要注意的是，開(kāi)啟 Cluster 之后，會(huì)動(dòng)態(tài)寫(xiě)入一些 Cluster 中各節(jié)點(diǎn)的配置信息。

# 是否開(kāi)啟 Cluster 模式
# cluster-enabled yes

# node 文件名稱
# cluster-config-file nodes-6379.conf

# 節(jié)點(diǎn)超時(shí)時(shí)間
# cluster-node-timeout 15000

# 當(dāng)一個(gè)Master擁有多少個(gè)正常的Slave時(shí)就要割讓一個(gè)Slave出來(lái)
# 例如設(shè)置為2，表示當(dāng)一個(gè)Master擁有2個(gè)可用的Slave時(shí)，它的一個(gè)Slave會(huì)嘗試遷移
# cluster-migration-barrier 1

# 允許從庫(kù)遷移
# cluster-allow-replica-migration yes

# 默認(rèn)情況下，集群全部的slot有節(jié)點(diǎn)負(fù)責(zé)，集群狀態(tài)才為ok，才能提供服務(wù)
# 設(shè)置為no，可以在slot沒(méi)有全部分配的時(shí)候提供服務(wù)
# 不建議打開(kāi)該配置，這樣會(huì)造成分區(qū)的時(shí)候，小分區(qū)的master一直在接受寫(xiě)請(qǐng)求，而造成很長(zhǎng)時(shí)間數(shù)據(jù)不一致
# cluster-require-full-coverage yes

# 設(shè)置是否進(jìn)行故障轉(zhuǎn)移
# 設(shè)置為 yes 表示不會(huì)進(jìn)行自動(dòng)故障轉(zhuǎn)移
# cluster-replica-no-failover no

# 表示當(dāng)集群因主節(jié)點(diǎn)數(shù)量達(dá)不到最小值或有散列槽沒(méi)有分配而被標(biāo)記為失效時(shí), 節(jié)點(diǎn)將停止所有的客戶端通訊
# cluster-allow-reads-when-down no

CLUSTER DOCKER/NAT support 集群Docker/NAT環(huán)境支持

在通過(guò) Docker 使用 Cluster 時(shí)的一些配置，Docker 還了解不多，沒(méi)有太多解釋啦。

# cluster-announce-ip 10.1.1.5
# cluster-announce-tls-port 6379
# cluster-announce-port 0
# cluster-announce-bus-port 6380

SLOW LOG 慢日志配置

是的，你沒(méi)看錯(cuò)，Redis 中也有慢查詢，同樣也會(huì)有慢查詢?nèi)罩尽Ｖ徊贿^(guò)這些日志不會(huì)記錄在某個(gè)日志文件中，而是在 Redis 服務(wù)端直接保存在一個(gè)慢日志列表中。

# 指定執(zhí)行時(shí)間超過(guò)多少微秒(1秒等于1000 000微秒)的命令請(qǐng)求會(huì)被記錄到日志上
slowlog-log-slower-than 10000
# 日志最大保存數(shù)量
slowlog-max-len 128

如果 slowlog-log-slower-than 0 就會(huì)記錄所有的命令，slowlog-log-slower-than -1 則會(huì)對(duì)于任何命令都不進(jìn)行記錄，只要是小于 0 的數(shù)字都不會(huì)進(jìn)行記錄。在客戶端，我們可以通過(guò) SHOWLOG 命令進(jìn)行查看。

slowlog get [n]

LATENCY MONITOR 延遲監(jiān)控配置

# 超過(guò)配置的時(shí)間，將該事件記錄下來(lái)
latency-monitor-threshold 0

我們可以使用 DEBUG 命令模擬耗時(shí)操作，然后通過(guò) LATENCY LATEST 命令可以查看到事件名、最近延遲的Unix時(shí)間戳、最近的延遲、最大延遲等。

127.0.0.1:6379> CONFIG SET latency-monitor-threshold 100
OK
127.0.0.1:6379> debug sleep 1
OK
(1.07s)
127.0.0.1:6379> LATENCY latest
1) 1) "command"
   2) (integer) 1657240891
   3) (integer) 1073
   4) (integer) 1073

EVENT NOTIFICATION 事件通知

這個(gè)功能是讓客戶端通過(guò)發(fā)布/訂閱給定的頻道或者模式，來(lái)獲知數(shù)據(jù)庫(kù)中鍵的變化，以及數(shù)據(jù)庫(kù)中命令的執(zhí)行情況。它的參數(shù)比較多，包括 K 鍵空間通知、E 鍵事件通知、s Set命令等等。

# 默認(rèn)不開(kāi)啟，可以填入需要開(kāi)啟的通知內(nèi)容
notify-keyspace-events ""

假如我們想要接收鍵事件通知和Set命令通知，可以設(shè)置為 Es 。

GOPHER SERVER gopher服務(wù)支持

gopher 是啥？不是 Go 語(yǔ)言相關(guān)的東西，具體是啥我也沒(méi)查出來(lái)個(gè)所以然，所以這里就不多說(shuō)了。它的配置就是一個(gè)開(kāi)關(guān)，表示開(kāi)啟或關(guān)閉。

gopher-enabled no

ADVANCED CONFIG 高級(jí)配置

高級(jí)配置里面的東西比較多，不過(guò)大部分其實(shí)是我們之前學(xué)習(xí)的內(nèi)部數(shù)據(jù)結(jié)構(gòu)相關(guān)的配置，在 Redis進(jìn)階：內(nèi)存優(yōu)化https://mp.weixin.qq.com/s/QNsroDmtV7a4F2k68VNlmw 中有過(guò)詳細(xì)的說(shuō)明。

# Hash 類(lèi)型底層數(shù)據(jù)結(jié)構(gòu)使用 ziplist 的優(yōu)化限值
hash-max-ziplist-entries 512
hash-max-ziplist-value 64

# List 類(lèi)型使用 ziplist 大小限值
list-max-ziplist-size -2

# List 中 quicklist 兩端壓縮節(jié)點(diǎn)個(gè)數(shù)
# 0表示都不壓縮
list-compress-depth 0

# set 類(lèi)型中存儲(chǔ)純 int 數(shù)據(jù)時(shí)的最大數(shù)量
set-max-intset-entries 512

# sorted set 類(lèi)型底層數(shù)據(jù)結(jié)構(gòu)使用 ziplist 的優(yōu)化限值
zset-max-ziplist-entries 128
zset-max-ziplist-value 64

# HyperLogLog 使用稀疏數(shù)據(jù)結(jié)構(gòu)的限值
hll-sparse-max-bytes 3000

# Streams單個(gè)節(jié)點(diǎn)的字節(jié)數(shù)，以及切換到新節(jié)點(diǎn)之前可能包含的最大項(xiàng)目數(shù)
stream-node-max-bytes 4kb
stream-node-max-entries 100

# 主動(dòng)重新散列每100毫秒CPU時(shí)間使用1毫秒，以幫助重新散列主Redis散列表（將頂級(jí)鍵映射到值）
activerehashing yes

# 客戶端輸出緩沖配置 分別針對(duì)一般情況、復(fù)制、訂閱三種模式
# 超過(guò)限制的客戶端將斷開(kāi)連接，可優(yōu)化緩沖區(qū)溢出問(wèn)題
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

# 客戶端查詢緩沖區(qū)累積的新命令大小
# client-query-buffer-limit 1gb

# 在Redis協(xié)議中，批量請(qǐng)求（即表示單個(gè)字符串的元素）通常限制為512 MB
# proto-max-bulk-len 512mb

# 默認(rèn)情況下，hz設(shè)置為 10 及更高值時(shí)，在Redis處于空閑狀態(tài)下，將使用更多CPU
# 可以配置 1-500 僅在需要非常低延遲的環(huán)境中將此值提高到100
hz 10

# 啟用動(dòng)態(tài)HZ時(shí)，實(shí)際配置的HZ將用作基線，但是一旦連接了更多客戶端，將根據(jù)實(shí)際需要使用配置的HZ值的倍數(shù)
dynamic-hz yes

# 當(dāng)一個(gè)子進(jìn)程重寫(xiě)AOF文件時(shí)，如果啟用下面的選項(xiàng)，則文件每生成32M數(shù)據(jù)會(huì)被同步
aof-rewrite-incremental-fsync yes

# 當(dāng)redis保存RDB文件時(shí)，如果啟用了以下選項(xiàng)，則每生成32 MB數(shù)據(jù)將對(duì)文件進(jìn)行fsync。 這對(duì)于以遞增方式將文件提交到磁盤(pán)并避免大延遲峰值非常有用
rdb-save-incremental-fsync yes

# 設(shè)置的越大，key的計(jì)數(shù)值就越難增長(zhǎng)，因此就要求key的訪問(wèn)頻度較高才能避免被淘汰
# lfu-log-factor 10
# 表示隔多久將計(jì)數(shù)器的值減一
# lfu-decay-time 1

ACTIVE DEFRAGMENTATION 活動(dòng)碎片整理

最后就是一些活躍碎片整理，其實(shí)就是內(nèi)存碎片的整理。這一塊又是基礎(chǔ)知識(shí)了，不知道大家有了解過(guò)內(nèi)存對(duì)齊不？完美的對(duì)齊肯定是不存在的，所以一塊內(nèi)存頁(yè)中多少都會(huì)有些閑置浪費(fèi)空間。另外還有刪除數(shù)據(jù)之后產(chǎn)生的碎片內(nèi)容。

這一塊的配置主要就是讓不讓 Redis 進(jìn)行內(nèi)存整理壓縮，針對(duì)內(nèi)存中數(shù)據(jù)的小分配和取消分配之間的剩余空間，從而讓內(nèi)存的利用更有效率。和大家在 Windows 上使用磁盤(pán)碎片整理是一個(gè)意思。

最后還有一小塊 CPU 綁定的配置，放在一起看了。

# 是否允許進(jìn)行碎片整理
# activedefrag no

# 啟動(dòng)活動(dòng)碎片整理的最小碎片浪費(fèi)量
# active-defrag-ignore-bytes 100mb

# 啟動(dòng)碎片整理的最小碎片百分比
# active-defrag-threshold-lower 10

# 使用最大消耗時(shí)的最大碎片百分比
# active-defrag-threshold-upper 100

# 在CPU百分比中進(jìn)行碎片整理的最小消耗
# active-defrag-cycle-min 1

# 在CPU百分比達(dá)到最大值時(shí)，進(jìn)行碎片整理
# active-defrag-cycle-max 25

# 從set / hash / zset / list 掃描的最大字段數(shù)
# active-defrag-max-scan-fields 1000

# 默認(rèn)情況下，用于清除的Jemalloc后臺(tái)線程是啟用的
jemalloc-bg-thread yes


# io線程 cpu 綁定到指定CPU核，可以減少CPU切換，后面幾個(gè)都是，能夠起到優(yōu)化速度效果
# server_cpulist 0-7:2
#
# 設(shè)置 bio 綁定到指定CPU核，后臺(tái)子線程
# bio_cpulist 1,3
#
# 設(shè)置 AOF REWRITE 子進(jìn)程 綁定到指定的CPU核
# aof_rewrite_cpulist 8-11
#
# 設(shè)置 BGSAVE 子進(jìn)程 綁定到指定的CPU核
# bgsave_cpulist 1,10-11

總結(jié)

好了，整個(gè)配置文件中的內(nèi)容咱們都過(guò)了一遍，當(dāng)然，并不是非常深入的每一個(gè)都去嘗試了一下。而且大部分注釋也是根據(jù)官方的英文翻譯的，有一些真的是不知道在講啥。不過(guò)就像最開(kāi)始說(shuō)的，咱們不管怎么樣，先過(guò)一遍，有個(gè)印象就夠了。