#是否作為守護進程運行 yes 或者 no
daemonize yes
#監聽IP,redis一般監聽127.0.0.1 網段訪問，集群模式需要指定IP地址。
bind 192.168.1.115
# 當 Redis 以守護進程的方式運行的時候，Redis 默認會把 pid 文件放在/var/run/redis.pid
# 可配置到其他地址，當運行多個 redis 服務時，需要指定不同的 pid 文件和端口
# 指定存儲Redis進程號的文件路徑
pidfile /var/run/redis-6379.pid
#端口
port 6379
# TCP 監聽的最大容納數量
# 此參數確定了TCP連接中已完成隊列(完成三次握手之后)的長度，
# 當系統並發量大並且客戶端速度緩慢的時候，你需要把這個值調高以避免客戶端連接緩慢的問題。
# Linux 內核會一聲不響的把這個值縮小成 /proc/sys/net/core/somaxconn 對應的值，默認是511，而Linux的默認參數值是128。
# 所以可以將這二個參數一起參考設定，你以便達到你的預期。
tcp-backlog 511
# 客戶端和Redis服務端的連接超時時間，默認是0，表示永不超時。
timeout 0
# 推薦一個合理的值就是60秒
tcp-keepalive 0
# 日志記錄等級，4個可選值debug,verbose,notice,warning
# 可以是下面的這些值：
# debug (適用於開發或測試階段)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (適用於生產環境)
# warning (僅僅一些重要的消息被記錄)
loglevel notice
#配置 log 文件地址,默認打印在命令行終端的窗口上，也可設為/dev/null屏蔽日志、
logfile "/opt/redis/logs/redis-6379.log"
# 可用的數據庫數，默認值為16，默認數據庫為0，數據庫范圍在0-（database-1）之間
databases 16
# 在 900 秒內最少有 1 個 key 被改動，或者 300 秒內最少有 10 個 key 被改動，又或者 60 秒內最少有 1000 個 key 被改動，以上三個條件隨便滿足一個，就觸發一次保存操作。
# if(在60秒之內有10000個keys發生變化時){
# 進行鏡像備份
# }else if(在300秒之內有10個keys發生了變化){
# 進行鏡像備份
# }else if(在900秒之內有1個keys發生了變化){
# 進行鏡像備份
# }
save 900 1
save 300 10
save 60 10000000
# 默認情況下，如果 redis 最后一次的后台保存失敗，redis 將停止接受寫操作，這樣以一種強硬的方式讓用戶知道數據不能正確的持久化到磁盤，
# 否則就會沒人注意到災難的發生。如果后台保存進程重新啟動工作了，redis 也將自動的允許寫操作。
# 然而你要是安裝了靠譜的監控，你可能不希望 redis 這樣做，那你就改成 no 好
stop-writes-on-bgsave-error no
# 在進行備份時,是否進行壓縮 是否在 dump .rdb 數據庫的時候使用 LZF 壓縮字符串默認都設為 yes 如果你希望保存子進程節省點 cpu ，你就設置它為 no ，
# 不過這個數據集可能就會比較大
rdbcompression yes
# 讀取和寫入的時候是否支持CRC64校驗，默認是開啟的
rdbchecksum yes
# 備份文件的文件名
dbfilename dump.rdb
# 數據庫備份的文件放置的路徑 路徑跟文件名分開配置是因為 Redis 備份時，先會將當前數據庫的狀態寫入到一個臨時文件
# 等備份完成時，再把該臨時文件替換為上面所指定的文件而臨時文件和上面所配置的備份文件都會放在這個指定的路徑當中
# 默認值為 ./
dir /opt/redis/data
# 當slave服務器和master服務器失去連接后，或者當數據正在復制傳輸的時候，如果此參數值設置“yes”，slave服務器可以繼續接受客戶端的請求，
#否則，會返回給請求的客戶端如下信息“SYNC with master in progress”,除了INFO，SLAVEOF這兩個命令
slave-serve-stale-data yes
# 是否允許slave服務器節點只提供讀服務
slave-read-only yes
#全量同步時,是否把快照先存於磁盤,如果存於磁盤,會有10性能,但是可以復用RDB文件
#如果不存於磁盤,就會直接把RDB文件流發送給從節點,復用性降低,在從節點比較少的時候,建議開啟
repl-diskless-sync no
#與上一個參數相關,當上一個設置為yes ,采用不存儲磁盤時, master等待一定時間,等待更多的從節點要求增量復制,然后進行並行復制
repl-diskless-sync-delay 5
# 指定向slave同步數據時，是否禁用socket的NO_DELAY選 項。若配置為“yes”，則禁用NO_DELAY，則TCP協議棧會合並小包統一發送，這樣可以減少主從節點間的包數量並節省帶寬，
#但會增加數據同步到 slave的時間。若配置為“no”，表明啟用NO_DELAY，則TCP協議棧不會延遲小包的發送時機，這樣數據同步的延時會減少，但需要更大的帶寬。
#通常情況下，應該配置為no以降低同步延時，但在主從節點間網絡負載已經很高的情況下，可以配置為yes。
repl-disable-tcp-nodelay no
# 指定slave的優先級。在不只1個slave存在的部署環境下，當master宕機時，Redis
# Sentinel會將priority值最小的slave提升為master。
# 這個值越小，就越會被優先選中，需要注意的是，
# 若該配置項為0，則對應的slave永遠不會自動提升為master。
slave-priority 100
#內存滿了后的淘汰策略,默認為noeviction ,即沒有淘汰策略,直接返回錯誤給客戶端
#volatile-lru :利用lru算法淘汰設置過過期時間的key
#allkeys-lru :利用lru算法淘汰所有的key
#olatile-random :隨機的淘汰設置過過期時間的key
#allkeys-random :隨機的淘汰所有的keyvolatile-ttl :淘汰即將到達過期時間的key
#noeviction :沒有淘汰算法
maxmemory-policy allkeys-lru
# redis 默認每次更新操作后會在后台異步的把數據庫鏡像備份到磁盤，但該備份非常耗時，且備份不宜太頻繁
# redis 同步數據文件是按上面save條件來同步的
# 如果發生諸如拉閘限電、拔插頭等狀況,那么將造成比較大范圍的數據丟失
# 所以redis提供了另外一種更加高效的數據庫備份及災難恢復方式
# 開啟append only 模式后,redis 將每一次寫操作請求都追加到appendonly.aof 文件中
# redis重新啟動時,會從該文件恢復出之前的狀態。
# 但可能會造成 appendonly.aof 文件過大，所以redis支持BGREWRITEAOF 指令，對appendonly.aof重新整理,默認是不開啟的。
appendonly yes
# 默認為appendonly.aof
appendfilename "appendonly.aof"
# 設置對 appendonly.aof 文件進行同步的頻率,有三種選擇always、everysec、no，默認是everysec表示每秒同步一次。
# always 表示每次有寫操作都進行同步,everysec 表示對寫操作進行累積,每秒同步一次。
# no表示等操作系統進行數據緩存同步到磁盤，都進行同步,everysec 表示對寫操作進行累積,每秒同步一次
# appendfsync always
# appendfsync everysec
# appendfsync no
appendfsync everysec
# 指定是否在后台aof文件rewrite期間調用fsync，默認為no，表示要調用fsync（無論后台是否有子進程在刷盤）。
#Redis在后台寫RDB文件或重寫afo文件期間會存在大量磁盤IO，此時，在某些linux系統中，調用fsync可能會阻塞。
no-appendfsync-on-rewrite yes
# 指定Redis重寫aof文件的條件，默認為100，表示與上次rewrite的aof文件大小相比，當前aof文件增長量超過上次afo文件大小的100%時，
#就會觸發background rewrite。若配置為0，則會禁用自動rewrite
auto-aof-rewrite-percentage 100
# 指定觸發rewrite的aof文件大小。若aof文件小於該值，即使當前文件的增量比例達到auto-aof-rewrite-percentage的配置值，
#也不會觸發自動rewrite。即這兩個配置項同時滿足時，才會觸發rewrite。
auto-aof-rewrite-min-size 64mb
#指redis在恢復時，會忽略最后一條可能存在問題的指令。默認值yes。即在aof寫入時，
#可能存在指令寫錯的問題(突然斷電，寫了一半)，這種情況下，yes會log並繼續，而no會直接恢復失敗.
aof-load-truncated yes
# 一個Lua腳本最長的執行時間，單位為毫秒，如果為0或負數表示無限執行時間，默認為5000
lua-time-limit 5000
#開啟集群
cluster-enabled yes
#集群配置文件
cluster-config-file /opt/redis/conf/nodes-6379.conf
#集群節點超時時間
cluster-node-timeout 5000
#redis slow log是一個系統到日志的查詢，它超過了指定的執行時間。執行時間不包括I/O操作比如和客戶交談，發送回復等等，
#但實際執行命令所需的時間（這是執行命令的階段，其中線程被阻塞，無法提供服務同時提出其他要求）。
#您可以使用兩個參數配置慢日志：一個參數告訴redis執行時間是多少，以微秒為單位，以便獲取日志的命令，另一個參數是
#慢日志。當記錄新命令時，最舊的命令將從記錄的命令隊列。以下時間以微秒表示，因此1000000相當於到一秒鍾。注意，負數將禁用慢日志，而值為零會強制記錄每個命令。
slowlog-log-slower-than 10000
#這個長度沒有限制。只是要注意它會消耗內存。
#您可以使用slow log reset回收慢日志使用的內存。
slowlog-max-len 128
#redis延遲監控子系統對不同的操作進行采樣在運行時，以便收集與redis實例的延遲。通過延遲命令，用戶可以使用這些信息打印圖表並獲取報告。系統只記錄在時間等於或大於通過
#延遲監視器閾值配置指令。當它的值被設置時將延遲監視器關閉為零。默認情況下，延遲監視被禁用，因為它基本上不需要 如果沒有延遲問題，並且收集數據有性能沖擊雖然很小，
#但可以在大載荷下測量。延遲使用命令可以在運行時輕松啟用監視
#“config set latency monitor threshold<millishes>”如果需要。
latency-monitor-threshold 0
#事件通知 #零個或多個字符。空字符串表示通知已禁用。
notify-keyspace-events ""
# 當hash中包含超過指定元素個數並且最大的元素沒有超過臨界時，
# hash將以一種特殊的編碼方式（大大減少內存使用）來存儲，這里可以設置這兩個臨界值
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
# list數據類型多少節點以下會采用去指針的緊湊存儲格式。
# list數據類型節點值大小小於多少字節會采用緊湊存儲格式。
list-max-ziplist-entries 512
list-max-ziplist-value 64
# set數據類型內部數據如果全部是數值型，且包含多少節點以下會采用緊湊格式存儲。
set-max-intset-entries 512
# zsort數據類型多少節點以下會采用去指針的緊湊存儲格式。
# zsort數據類型節點值大小小於多少字節會采用緊湊存儲格式。
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
#建議值為3000
hll-sparse-max-bytes 3000
# Redis將在每100毫秒時使用1毫秒的CPU時間來對redis的hash表進行重新hash，可以降低內存的使用
# 當你的使用場景中，有非常嚴格的實時性需要，不能夠接受Redis時不時的對請求有2毫秒的延遲的話，把這項配置為no。
# 如果沒有這么嚴格的實時性要求，可以設置為yes，以便能夠盡可能快的釋放內存
activerehashing yes
#當某些客戶端由於處理速度不夠,服務器端會緩沖一部分數據,當超過緩沖硬緩沖的限制,則會把客戶端的連接關閉
#當超過軟限制( soft limit) ,並且達到一定的時間soft seconds ,則也會關閉連接
#client-output-buffer-limit normal 0 0 0 //normal代表常規客戶端,包括監控類型的客戶端
#client-output-buffer-limit slave 256mb 64mb 60 //slave代表主從結構的客戶端
#client-output-buffer-limit pubsub 32mb 8mb 60 //訂閱類型的客戶端
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
#hz默認設為10，提高它的值將會占用更多的cpu，當然相應的redis將會更快的處理同時到期的許多key，以及更精確的去處理超時。
#hz的取值范圍是1~500，通常不建議超過100，只有在請求延時非常低的情況下可以將值提升到100。
hz 10
# aof rewrite過程中,是否采取增量文件同步策略,默認為“yes”。 rewrite過程中,每32M數據進行一次文件同步,這樣可以減少aof大文件寫入對磁盤的操作次數
aof-rewrite-incremental-fsync yes
