Redis叢集配置引數及優化
Redis的主要引數配置在redis.conf檔案中。
1. conf 記憶體值
2. bind ip
預設情況下,如果沒有指定“bind”配置指令,Redis將偵聽伺服器上可用的所有網路介面的連線。
預設情況:bind 127.0.0.1
實際配置:bind 本機ip
3. protected-mode yes
啟用預設保護模式。只有當您確定您希望其他主機的客戶端連線到Redis時,您才應該禁用它,即使沒有配置身份驗證,也沒有使用“bind”指令顯式列出特定的介面集。
4. tcp-keepalive300
如果非零,請使用SO_KEEPALIVE向沒有通訊的客戶傳送TCP協議。
這很有用,有兩個原因:
a) 檢測死同伴
b) 從中間的網路裝置的角度進行連線
在Linux上,指定的值(以秒為單位)是用於傳送ack的週期。
注意,要關閉連線,需要雙倍的時間。這個選項的合理值是300秒,這是新的Redis預設值,從Redis 3.2.1開始。
5. timeout0
在客戶機空閒N秒後關閉連線(0到禁用)
6. port 6379
在指定埠上接受連線,預設值是6379
7. daemonize yes
redis後臺執行
8. pidfile /var/run/redis_6379.pid
如果指定了一個pid檔案,Redis會在啟動時指定,並在退出時刪除它。
當伺服器執行非守護程序時,如果配置中沒有指定pid檔案,則不會建立pid檔案。當伺服器被守護時,即使沒有指定,也會使用pid檔案,預設為“/var/run/redis.pid”。
建立一個pid檔案是最好的工作:如果Redis不能建立它,那麼伺服器就會正常啟動和執行。
9. loglevel notice
指定伺服器冗餘級別
包括:
a) debug: 大量資訊,用於開發/測試
b) verbose: 許多很少有用的資訊,但不像debug級別那樣混亂
c) notice: 適度詳細,可能在生產中需要
d) warning: 只有非常重要/關鍵的訊息被記錄
10. logfile""
指定日誌檔名。還可以使用空字串強制Redis登入標準輸出。請注意,如果您使用標準輸出來記錄日誌,但是daemalize,日誌將被髮送到/dev/null。
11. databases 16
設定資料庫的數量。預設資料庫是DB 0,您可以使用select 在每個連線上選擇一個不同的資料庫,其中dbid是一個0和'databases'-1之間的數字。
12. always-show-logoyes
預設情況下,Redis只顯示了ASCII藝術標誌,當開始記錄到標準輸出時,如果標準輸出是TTY。基本上,這意味著通常只有在互動式會話中才會顯示徽標。但是,可以強制執行4.0的行為,並且在啟動日誌中始終顯示一個ASCII藝術標識,通過設定下面的選項為yes。
13. dbfilename dump.rdb
要轉儲資料庫的檔名,儲存檔案。
14. dir ./
工作目錄
將在這個目錄中寫入,使用“dbfilename”配置指令指定上面指定的檔名。
只在此目錄中建立附加檔案。
注意,您必須在這裡指定一個目錄,而不是檔名。
15. slaveof<masterip> <masterport>
主從複製。使用slaveof來讓一個Redis例項複製另一個Redis伺服器。
a) Redis複製是非同步的;
b) 如果複製連結在相對較小的時間內丟失,Redis的奴隸可以與主伺服器進行部分的重新同步。
c) 複製是自動的,不需要使用者干預。在網路分割槽後,奴隸會自動嘗試重新連線主人並與他們重新同步。
16. masterauth<master-password>
如果master是密碼保護的(使用下面的“requirepass”配置指令),在啟動複製同步程序之前,可以告訴奴隸進行身份驗證,否則主人將拒絕奴隸請求。
17. slave-serve-stale-datayes
當一個奴隸失去與主人的聯絡,或當複製仍在進行時,奴隸可以採取兩種不同的方式:
a) 如果slave-serve-stale-data被設定為“yes”(預設),則該slave仍然會回覆客戶端請求,可能是由於過時資料,或者如果這是第一次同步,資料集可能是空的。
b) 如果slave-serve-stale-data被設定為“不”,那麼slave將會以“與master同步”的錯誤來回復所有的命令,but toINFO and SLAVEOF。
18. slave-read-onlyyes
注:只讀奴隸不被設計成在網際網路上接觸不可信的客戶。它只是一個防止濫用例項的保護層。
在預設情況下,仍然只讀取奴隸的匯出,所有的管理命令,例如CONFIG、DEBUG等等。在一定程度上,您可以通過使用“rename-command”來對所有的管理/危險命令進行隱藏,從而提高讀取的安全性。
19. repl-backlog-size1mb
backlog是一個緩衝區
20. slave-priority100
它被Redis Sentinel所使用,以便在主人不再正確工作的情況下,選擇一個奴隸來提升為主人。
一個低優先順序的奴隸被認為是更好的晉升機會,例如,如果有三個優先順序為10、100、25個哨兵的奴隸將選擇優先順序為10的,這是最低的。然而,一個特殊的優先順序0標誌著奴隸不能執行主人的角色,因此,優先順序為0的奴隸將永遠不會被RedisSentinel選中來提升。
預設情況下,優先順序是100。
21. maxclients10000
設定同時連線客戶端的最大數量,預設情況下這個限制設定為10000個客戶,一旦達到限制,Redis將關閉所有新的連線,傳送錯誤的最大客戶數。
22. maxmemory<bytes>
將記憶體使用限制設定為指定的位元組數。
如果您有附加的奴隸,建議您為maxmemory設定一個較低的限制,以便在系統上有一些空閒RAM用於輸出緩衝區(但如果策略是“no驅逐”,則不需要這樣做)。
23. maxmemory-policynoeviction
MAXMEMORY策略:當達到MAXMEMORY時,Redis將選擇要刪除的內容。
volatile-lru: 在鍵中使用近似的LRU結束設定。
allkeys-lru: 使用近似的LRU清除任何鍵。
volatile-lfu: 在金鑰中使用近似的LFU結束設定。
allkeys-lfu: 使用近似的LFU清除任何金鑰。
volatile-random: 將一個隨機金鑰刪除,其中有一個過期設定。
allkeys-random: 刪除一個隨機金鑰,任何金鑰。
volatile-ttl: 刪除最近過期時間的鍵(小TTL)
noeviction: 不驅逐任何東西,只返回寫操作上的錯誤。
注:LRU的意思是最近使用最少,LFU的意思是最不常用,LRU、LFU和揮發性ttl均採用近似隨機演算法實現。在上面的任何一個策略中,Redis將返回一個寫操作上的錯誤,當沒有合適的鍵來驅逐時。
預設是: maxmemory-policynoeviction
24. maxmemory-samples5
LRU、LFU和最小TTL演算法不是精確的演算法,而是近似演算法(為了節省記憶體),所以你可以對它進行調優,以達到速度或精度。對於預設的Redis將檢查5個鍵並選擇最近使用較少的鍵,您可以使用下面的配置指令來更改示例的大小。
注:預設的5產生足夠好的結果。十分接近真實的LRU,但成本更大。3更快,但不太準確。
25. appendonly yes
只追加模式
aof日誌開啟 有需要就開啟,它會每次寫操作都記錄一條日誌
預設情況下,Redis會非同步地轉儲磁碟上的資料集。這種模式在許多應用程式中都很好,但是對於Redis程序或斷電可能會導致幾分鐘的寫入丟失(取決於配置的儲存點)。
Append檔案是一種替代永續性模式,它提供了更好的永續性。
AOF和RDB永續性可以同時啟用,沒有問題。
如果在啟動Redis上啟用了AOF,則會載入AOF,這是具有更好的耐久性保證的檔案。
appendfilename "appendonly.aof"
26. appendfsynceverysec
fsync()呼叫告訴作業系統在磁碟上實際寫入資料,而不是等待輸出緩衝區中的更多資料。有些作業系統會在磁碟上重新整理資料,有些作業系統會盡快處理。
Redis支援三種不同的模式:
no: 不要fsync,只需讓作業系統在需要的時候重新整理資料。Faster
always: fsync每次寫完後只新增日誌。Slow,Safest
everysec: fsync每秒鐘一次。Compromise
預設的是“everysec”,因為這通常是速度和資料安全之間的正確折衷。由你理解如果你能放鬆這個“不”字,讓作業系統重新整理輸出緩衝區時,為了更好的表現(但是如果你可以忍受一些資料丟失的想法考慮預設快照的永續性模式),或相反,使用“always”非常緩慢但比”everysec”更安全一點。
如果不確定,就用“everysec”。
27. no-appendfsync-on-rewriteno
如果您有延遲問題,請將其轉換為"yes"。否則,從永續性的角度來看,設定為"no"是最安全的選擇。
28. auto-aof-rewrite-percentage100
auto-aof-rewrite-min-size64 mb
自動重寫附加檔案
Redis能夠自動地重寫日誌檔案,當AOF日誌大小以指定的百分比增長時,隱式地呼叫BGREWRITEAOF。
工作方式:Redis記得在最近一次重寫後的AOF檔案的大小(如果在重啟後沒有重寫,那麼在啟動時AOF的大小就會被使用)。
此基礎大小與當前大小比較。如果當前的大小大於指定的百分比,則會觸發重寫。您還需要為AOF檔案指定一個最小的大小來重寫,這對於避免重寫AOF檔案是很有用的,即使增加了百分比,但是它仍然很小。
指定一個百分比為零,以禁用自動的重寫功能。
29. aof-load-truncatedyes
在Redis啟動過程中,當AOF資料被載入回記憶體時,可能會發現AOF檔案被截斷。
如果將aof-load-truncated設定為yes,將載入一個被截斷的AOF檔案,而Redis伺服器將開始發出日誌以通知使用者該事件。否則,如果選項被設定為no,伺服器會以錯誤中止並拒絕啟動。當選項設定為no時,使用者需要在重新啟動伺服器之前使用“redis-checkaof”工具修復AOF檔案。
注意,如果在中間發現AOF檔案被損壞,伺服器仍然會以錯誤退出。此選項只適用於Redis將嘗試從AOF檔案讀取更多資料,但不會找到足夠的位元組。
30. cluster-enabled yes
開啟叢集
31. cluster-config-file nodes-6379.conf
每個叢集節點都有一個叢集配置檔案。它是由Redis節點自動建立和更新的。每個Redis叢集節點都需要一個不同的叢集配置檔案。
注:確保在同一系統中執行的例項沒有重疊的叢集配置檔名。叢集的配置,配置檔案首次啟動自動生成。
32. cluster-node-timeout 5000
群集節點超時是指節點在失敗狀態下必須不可到達的毫秒數。大多數其他內部時間限制是節點超時的倍數。
注:請求超時,設定5秒夠了。
33. cluster-require-full-coverageyes
預設情況下,Redis叢集節點如果檢測到至少有一個雜湊槽(沒有可用的節點正在服務),就會停止接受查詢。這樣,如果叢集部分宕機(例如,不再覆蓋雜湊槽的範圍),那麼所有叢集最終都將不可用。當所有的插槽再次被覆蓋時,它會自動返回。
但是,有時您希望叢集的子集繼續工作,繼續接受仍然覆蓋的關鍵空間部分的查詢。為了做到這一點,只需將cluster-require-full-coverage選項設定為no。
34. slowlog-log-slower-than10000
“Redis慢速日誌”是一個記錄超過指定執行時間的查詢的系統。執行時間不包括I/O操作,比如與客戶端,傳送應答等等,但就實際執行命令所需的時間(這是唯一階段命令執行的執行緒被阻塞,不能同時處理其他請求)。
您可以使用兩個引數來配置慢速日誌:一個告訴Redis,在微秒內,執行時間超過了命令的執行時間,另一個引數是慢日誌的長度(第18條)。當新命令被記錄時,最老的命令將從已記錄的命令佇列中刪除。
單位:微秒
35. slowlog-max-len128
這個長度沒有限制。只要意識到它會消耗記憶體。可以回收利用慢速日誌重置的慢速日誌。
36. latency-monitor-threshold0
Redis延遲監控子系統在執行時對不同的操作進行取樣,以便收集與Redis例項可能的延遲來源相關的資料。
通過延遲命令,使用者可以使用這些資訊來列印圖表並獲取報告。
該系統只記錄在一個時間內執行的操作,該操作的時間等於或大於通過延遲監控閾值配置指令所指定的毫秒數。當它的值設定為0時,延遲監視器就關閉了。
預設情況下,延遲監視是禁用的,因為如果您沒有延遲問題,並且收集資料具有效能影響,那麼在很大的負載下可以度量資料的效能影響。在執行時,如果需要,可以很容易地使用命令"CONFIGSET latency-monitor-threshold <milliseconds>"來啟用延遲監視。
37. hash-max-ziplist-entries512
hash-max-ziplist-value64
Hashes使用記憶體有效的資料結構進行編碼,當它們有少量的條目時,最大的條目不超過給定的閾值。可以使用以下指令來配置這些閾值。
38. list-max-ziplist-size-2
列表也以一種特殊的方式編碼,以節省大量空間。每個內部列表節點允許的條目數可以指定為固定的最大大小或元素的最大數量。對於固定的最大尺寸,使用-5到-1,意思是:
-5:最大大小:64kb -> 不推薦用於正常工作負載
-4:最大尺寸:32kb -> 不推薦
-3:最大尺寸:16kb -> 可能不推薦
-2:最大尺寸:8kb -> 很好
-1:最大尺寸:4 Kb -> 很好
正數意味著儲存到每個列表節點上的元素數量。
最高執行選項通常是-2 (8kb大小)或-1 (4Kb大小),但如果您的用例是惟一的,則根據需要調整設定。
39. list-compress-depth0
列表也可能被壓縮
壓縮深度是列表的每個邊的quicklist ziplist節點的數量,以排除壓縮。列表的頭和尾總是為快速的push/pop操作而沒有壓縮。
設定:
0:禁用所有列表壓縮。
1:depth 1的意思是“在1個節點進入列表後,從頭部或尾部開始壓縮”
So:[head]->node->node->...->node->[tail],[head],[tail]將始終未壓縮;內部節點將壓縮。
2: [head]->[next]->node->node->...->node->[prev]->[tail]
2在這裡的意思是:不要壓縮head或head->next或tail->prev或tail,而是壓縮它們之間的所有節點。
3:[head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail]
40. set-max-intset-entries512
集合有一個特殊的編碼:當一個集合由剛好是在64位有符號整數範圍內的基數10中的整陣列成。
此配置設定設定了大小的限制。
41. zset-max-ziplist-entries128
zset-max-ziplist-value64
與雜湊和列表類似,排序集也是經過特殊編碼的,以節省大量空間。
注:此編碼僅當排序集的長度和元素低於以下限制時使用。
42. hll-sparse-max-bytes3000
HyperLogLog稀疏表示位元組限制。這個限制包括16個位元組的標題。當使用稀疏表示的超loglog跨越這個限制時,它被轉換為稠密表示。
注:一個大於16000的值是完全無用的,因為在那個點上,稠密表示的記憶體更有效。
建議值為3000,以便在不減速的情況下獲得空間有效編碼的好處,而PFADD是O(N),編碼稀疏。當CPU不受關注時,可將值提高到10000,但是空間、資料集由許多具有基數在0 -15000範圍內的超loglog組成。
43. activerehashingyes
Active rehashing每100毫秒使用1毫秒的CPU時間來幫助重散主Redis雜湊表(一個對映到值的頂級鍵)。
預設情況下,每秒鐘使用這個毫秒為10次,以便主動地對主字典進行重新處理,在可能的情況下釋放記憶體。
使用“activerehashing no”,如果您有很強的延遲需求,並且在您的環境中,Redis可以不時地以2毫秒的延遲來答覆查詢,這不是一件好事。
使用“activerehashing yes”如果您沒有這樣的硬性要求,但希望在可能的情況下儘快釋放記憶體。
44. client-output-buffer-limitnormal 0 0 0
client-output-buffer-limitslave 256mb 64mb 60
client-output-buffer-limitpubsub 32mb 8mb 60
客戶端輸出緩衝區的限制可以用來強迫那些由於某些原因而不能快速讀取伺服器資料的客戶斷開連線(一個常見的原因是,Pub/Sub客戶端不能像釋出伺服器那樣快速地使用訊息)。
對於三種不同型別的客戶,可以設定不同的限制:
normal : normal clients包括監控客戶端
slave : slave clients
pubsub : 客戶端訂閱了至少一個pubsub通道或模式
每個client-output-buffer-limit指令的語法如下:
client-output-buffer-limit <class> <hardlimit> <soft limit> <soft seconds>
當達到硬限值時,客戶端會立即斷開連線,或者如果達到了軟限制,並且持續達到指定的秒數(持續)。
例如如果硬限制是32位元組和軟限制是16 mb / 10秒,客戶端會立即斷開輸出緩衝區的大小達到32位元組,但也會斷開如果客戶達到16位元組,不斷克服了限制10秒鐘。
預設情況下,正常的客戶機不受限制,因為它們不會在沒有請求的情況下接收資料(按push方式),但是在請求之後,所以只有非同步客戶機可能會建立一個場景,在這個場景中,請求資料的速度比讀取的速度要快。相反,對於pubsub和從客戶端來說,這是一個預設的限制,因為訂閱者和奴隸會以推送的方式接收資料。
無論是強的還是弱的限制都可以通過設定為零來禁用。
45. hz 10
Redis呼叫一個內部函式來執行許多後臺任務,比如超時關閉客戶機連線、清除未請求的過期鍵等。不是所有的任務都以相同的頻率執行,但是Redis檢查任務是否按照指定的“hz”值執行。
預設的“hz”設定為10。當Redis空閒時,提高該值將使用更多的CPU,但同時,當有許多鍵同時到期時,將使Redis更加敏感,並且可以更精確地處理超時。
注:這個範圍在1到500之間,但是超過100通常不是一個好主意。大多數使用者應該使用預設的10,並且只在需要非常低延遲的環境中提高到100。
46. aof-rewrite-incremental-fsyncyes
當一個child重新編寫AOF檔案時,如果啟用了該選項,那麼這個檔案將被fsync-ed每32 MB的資料生成。這是有用的,以便更增量地將檔案提交到磁碟,並避免較大的延遲峰值。
47. 活動碎片整理(實驗階段)
Active(線上)碎片整理允許Redis伺服器壓縮記憶體中的小分配和資料分配之間的空間,從而允許回收記憶體。
分段是一個自然的過程,每個分配器都會發生(但是使用Jemalloc,幸運的是)和某些工作負載。通常需要重新啟動伺服器,以降低碎片化,或者至少要清除所有資料並重新建立。然而,由於OranAgra為Redis4.0實現的這個特性,這個過程可以在執行時以“熱”的方式執行,而伺服器正在執行。
基本上碎片超過一定水平時(見下面的配置選項)複述,將開始建立新副本的值在連續的記憶體區域利用特定Jemalloc特性(為了理解如果一個分配導致分裂和分配在一個更好的地方),同時,將舊的資料的副本。這個過程,對所有鍵重複地重複,將導致碎片返回到正常值。
注:
1) 預設情況下,該特性是禁用的,並且只有在您編譯Redis時才會使用Jemalloc的副本,我們使用的是Redis的原始碼。這是Linux構建的預設值。
2) 如果沒有碎片問題,則不需要啟用該特性。
3) 一旦您經歷了碎片化,您就可以在需要時啟用這個特性,而命令“CONFIG SETactivedefrag yes”。
配置引數能夠微調碎片整理過程的行為。如果您不確定它們的含義,那麼保留預設值是一個好主意。
配置:
a) activedefrag yes
啟用活躍碎片整理
b) active-defrag-ignore-bytes 100mb
最小的碎片浪費開始活動的碎片整理
c) active-defrag-threshold-lower 10
最小百分比的碎片開始活動的碎片整理
d) active-defrag-threshold-upper 100
我們使用最大努力的碎片的最大百分比
e) active-defrag-cycle-min 25
在CPU百分比中對defrag最小的效率
f) active-defrag-cycle-max 75
在CPU百分比中對defrag最大的效率