linux 啟動 redis：cd /usr/local/redis-3.2.0
src/redis-server redis.conf //保證 redis 啟動時讀取的是配置完成的 redis.conf 文件
src/redis-cli //啟動客戶端
ps -ef|grep redis //查看 redis 進程狀態

默認的配置 redis.conf 文件中，首先約定了存儲單位：
1k => 1000 bytes
1kb => 1024 bytes
1m => 1000000 bytes
1mb => 10241024 bytes
1g => 1000000000 bytes
1gb => 10241024*1024 bytes
Redis 配置中對單位的大小寫不敏感，1GB、1Gb和1gB都是相同的。由此也說明，Redis 只支持 bytes，不支持 bit 單位。
Redis 支持以 “includes” 的方式引入其他配置文件，比如：
include/path/to/local.conf
include/path/to/other.conf
需要注意的是，假如多個一個配置項在不同配置文件中都有定義，則以最后一行讀入的為準，就是說后面的配置項會覆蓋前面的配置項。

1.1通用配置
默認情況下，Redis 并不是以 daemon 形式來運行的。通過 daemonize 配置項可以控制Redis的運行形式，如果改為 yes，那么 Redis 就會以 daemon 形式運行：
daemonize no
當以 daemon 形式運行時，Redis 會生成一個 pid 文件，默認會生成在 /var/run/Redis.pid 。當然，可以通過 pidfile 來指定 pid 文件生成的位置，比如：
pidfile /path/to/Redis.pid
默認情況下，Redis 會響應本機所有可用網卡的連接請求。當然，Redis 允許通過 bind 配置項來指定要綁定的IP，比如：
bind 192.168.1.2 10.8.4.2
Redis的默認服務端口是6379，可以通過 port 配置項來修改。如果端口設置為0的話，Redis 便不會監聽端口了。
port 6379
可是，如果Redis不監聽端口，還怎么與外界通信呢？其實Redis還支持通過 unix socket 方式來接收請求。可以通過 unix socket 配置項來指定 unix socket 文件的路徑，并通過 unix socket perm 來指定文件的權限。
unixsocket /tmp/Redis.sock
unixsocketperm 700

在高 QPS 的環境下需要提高 backlog 的值來避免 TCP 的慢連接問題。想要提高 backlog 的值，除了需要設置 Redis 的 tcp-backlog ，還要同時提高更改 Linux 的配置，否則，Linux內核會默認將其截取為 /proc/sys/net/core/somaxconn 的大小。
tcp-backlog 511
當一個 Redis-client 一直沒有請求發向 server 端，那么 server 端有權主動關閉這個連接，可以通過timeout 來設置“空閑超時時限”，0表示永不關閉。
timeout 0
TCP連接保活策略，可以通過 tcp-keepalive 配置項來進行設置，單位為秒，假如設置為60秒，則 server 端會每60秒向連接空閑的客戶端發起一次 ACK 請求，以檢查客戶端是否已經掛掉，對于無響應的客戶端則會關閉其連接。所以關閉一個連接最長需要120秒的時間。如果設置為0，則不會進行保活檢測。
tcp-keepalive 0
Redis支持通過 loglevel 配置項設置日志等級，共分四級，即 debug、verbose、notice、warning。
loglevel notice
Redis也支持通過 logfile 配置項來設置日志文件的生成位置。如果設置為空字符串，則 Redis 會將日志輸出到標準輸出。假如在 daemon 情況下將日志設置為輸出到標準輸出，則日志會被寫到 /dev/null 中。
logfile ""
如果希望日志打印到 syslog 中，也很容易，通過 syslog-enabled 來控制。另外，syslog-ident 還可以指定syslog 里的日志標志，比如：
syslog-ident Redis
而且還支持指定 syslog 設備，值可以是 USER 或 LOCAL0-LOCAL7 。具體可以參考 syslog 服務本身的用法。
syslog-facility local0
對于 Redis 來說，可以設置其數據庫的總數量，假如希望一個 Redis 包含16個數據庫，那么設置如下：
databases 16
這16個數據庫的編號將是0到15。默認的數據庫是編號為0的數據庫。用戶可以使用 select <DBid> 來選擇相應的數據庫。

1.2快照配置
快照，主要涉及的是 Redis 的 RDB 持久化相關的配置。
可以用如下的指令來讓數據保存到磁盤上，即控制 RDB 快照功能：
save <seconds> <changes>
舉例來說：
save 900 1 //表示每15分鐘且至少有1個 key 改變，就觸發一次持久化
save 300 10 //表示每5分鐘且至少有10個 key 改變，就觸發一次持久化
save 60 10000 //表示每60秒至少有10000個 key 改變，就觸發一次持久化
如果想禁用 RDB 持久化的策略，只要不設置任何 save 指令就可以，或者給 save 傳入一個空字符串參數也可以達到相同效果，就像這樣：
save""
如果用戶開啟了 RDB 快照功能，那么在 Redis 持久化數據到磁盤時如果出現失敗，默認情況下，Redis 會停止接受所有的寫請求。這樣做的好處在于可以讓用戶很明確的知道內存中的數據和磁盤上的數據已經存在不一致了。如果 Redis 不顧這種不一致，一意孤行的繼續接收寫請求，就可能會引起一些災難性的后果。
如果下一次 RDB 持久化成功，Redis 會自動恢復接受寫請求。
當然，如果不在乎這種數據不一致或者有其他的手段發現和控制這種不一致的話完全可以關閉這個功能，以便在快照寫入失敗時，也能確保 Redis 繼續接受新的寫請求。配置項如下：
stop-writes-on-bgsave-error yes
對于存儲到磁盤中的快照，可以設置是否進行壓縮存儲。如果是的話，Redis 會采用 LZF 算法進行壓縮。如果不想消耗 CPU 來進行壓縮的話，可以設置為關閉此功能，但是存儲在磁盤上的快照會比較大。
rdbcompression yes
在存儲快照后，我們還可以讓 Redis 使用 CRC64 算法來進行數據校驗，但是這樣做會增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關閉此功能。
rdbchecksum yes
我們還可以設置快照文件的名稱，默認是這樣配置的：
dbfilename dump.rdb
還可以設置這個快照文件存放的路徑。比如默認設置就是：
dir ./db/

1.3主從配置
Redis 提供了主從同步功能。
通過 slaveof 配置項可以控制某一個 Redis 作為另一個 Redis 的從服務器，通過指定 IP 和端口來定位到主Redis 的位置。一般情況下建議用戶為從 Redis 設置一個不同頻率的快照持久化的周期，或者為從 Redis 配置一個不同的服務端口等等。
slaveof <masterip> <masterport>
如果主 Redis 設置了驗證密碼的話（使用 requirepass 來設置），則在從 Redis 的配置中要使用masterauth 來設置校驗密碼，否則的話，主 Redis 會拒絕從 Redis 的訪問請求。
masterauth <master-password>
當從 Redis 失去了與主 Redis 的連接，或者主從同步正在進行中時， Redis 該如何處理外部發來的訪問請求呢？這里，從 Redis 可以有兩種選擇：
第一種選擇：如果 slave-serve-stale-data 設置為 yes （默認），則從 Redis 仍會繼續響應客戶端的讀寫請求。
第二種選擇：如果 slave-serve-stale-data 設置為 no，則從 Redis 會對客戶端的請求返回 “SYNC with master inprogress” ，當然也有例外，當客戶端發來 INFO 請求和 SLAVEOF 請求，從 Redis 還是會進行處理。
可以控制一個從 Redis 是否可以接受寫請求。將數據直接寫入從 Redis ，一般只適用于那些生命周期非常短的數據，因為在主從同步時，這些臨時數據就會被清理掉。自從 Redis2.6 版本之后，默認從 Redis 為只讀。
slave-read-only yes
只讀的從 Redis 并不適合直接暴露給不可信的客戶端。為了盡量降低風險，可以使用 rename-command指令來將一些可能有破壞力的命令重命名，避免外部直接調用。比如：
rename-command CONFIG b8c02d524045429941cc15f59e41cb7be6c52
從 Redis 會周期性的向主 Redis 發出 PING 包。可以通過 repl_ping_slave_period 指令來控制其周期。默認是10秒。
repl-ping-slave-period 10
在主從同步時，可能在這些情況下會有超時發生：
（1）以從 Redis 的角度來看，當有大規模 IO 傳輸時。
（2）以從 Redis 的角度來看，當數據傳輸或 PING 時，主 Redis 超時
（3）以主 Redis 的角度來看，在回復從 Redis 的 PING 時，從 Redis 超時
用戶可以設置上述超時的時限，不過要確保這個時限比 repl-ping-slave-period 的值要大，否則每次主Redis 都會認為從 Redis 超時。
repl-timeout 60
我們可以控制在主從同步時是否禁用 TCP_NODELAY 。如果開啟 TCP_NODELAY ，那么主 Redis 會使用更少的 TCP 包和更少的帶寬來向從 Redis 傳輸數據。但是這可能會增加一些同步的延遲，大概會達到40毫秒左右。如果關閉了 TCP_NODELAY ，那么數據同步的延遲時間會降低，但是會消耗更多的帶寬。
repl-disable-tcp-nodelay no
我們還可以設置同步隊列長度。隊列長度（ backlog )是主 Redis 中的一個緩沖區，在與從 Redis 斷開連接期間，主 Redis 會用這個緩沖區來緩存應該發給從 Redis 的數據。這樣的話，當從 Redis 重新連接上之后，就不必重新全量同步數據，只需要同步這部分增量數據即可。
repl-backlog-size 1mb
如果主 Redis 等了一段時間之后，還是無法連接到從 Redis ，那么緩沖隊列中的數據將被清理掉。我們可以設置主 Redis 要等待的時間長度。如果設置為0，則表示永遠不清理。默認是1個小時。
repl-backlog-ttl 3600
我們可以給眾多的從 Redis 設置優先級，在主 Redis 持續工作不正常的情況，優先級高的從 Redis 將會升級為主 Redis 。而編號越小，優先級越高。比如一個主 Redis 有三個從 Redis ，優先級編號分別為10、100、25，那么編號為10的從 Redis 將會被首先選中升級為主 Redis 。當優先級被設置為0時，這個從Redis 將永遠也不會被選中。默認的優先級為100。
slave-priority 100
假如主 Redis 發現有超過M個從 Redis 的連接延時大于N秒，那么主 Redis 就停止接受外來的寫請求。這是因為從 Redis 一般會每秒鐘都向主Redis發出PING，而主Redis會記錄每一個從 Redis 最近一次發來 PING 的時間點，所以主 Redis 能夠了解每一個從 Redis 的運行情況。
min-slaves-to-write 3
min-slaves-max-lag 10
上面這個例子表示，假如有大于等于3個從 Redis 的連接延遲大于10秒，那么主 Redis 就不再接受外部的寫請求。上述兩個配置中有一個被置為0，則這個特性將被關閉。默認情況下 min-slaves-to-write 為0，而 min-slaves-max-lag 為10。

1.4 安全配置
我們可以要求 Redis 客戶端在向 Redis-server 發送請求之前，先進行密碼驗證。由于 Redis 性能非常高，每秒鐘可以完成多達15萬次的密碼嘗試，所以最好設置一個足夠復雜的密碼，否則很容易被黑客破解。
requirepass chenlongfei
這里通過 requirepass 將密碼設置成我的名字。
Redis 允許我們對 Redis 指令進行更名，比如將一些比較危險的命令改個名字，避免被誤執行。比如可以把 CONFIG 命令改成一個很復雜的名字，這樣可以避免外部的調用，同時還可以滿足內部調用的需要：
rename-command CONFIG b840fc02d5240454299c15f59e41cb7be6c89
我們甚至可以禁用掉 CONFIG 命令，那就是把 CONFIG 的名字改成一個空字符串：
rename-command CONFIG ""
但需要注意的是，如果使用 AOF 方式進行數據持久化，或者需要與從 Redis 進行通信，那么更改指令的名字可能會引起一些問題。

1.5 限制配置
我們可以設置 Redis 同時可以與多少個客戶端進行連接。默認情況下為10000個客戶端。當無法設置進程文件句柄限制時， Redis 會設置為當前的文件句柄限制值減去32，因為 Redis 會為自身內部處理邏輯留一些句柄出來。
如果達到了此限制， Redis 則會拒絕新的連接請求，并且向這些連接請求方發出 “max number of clients reached” 以作回應。
maxclients 10000
我們甚至可以設置 Redis 可以使用的內存量。一旦到達內存使用上限， Redis 將會試圖移除內部數據，移除規則可以通過 maxmemory-policy 來指定。
如果 Redis 無法根據移除規則來移除內存中的數據，或者我們設置了“不允許移除”，那么 Redis 則會針對那些需要申請內存的指令返回錯誤信息，比如 SET 、 LPUSH 等。但是對于無內存申請的指令，仍然會正常響應，比如 GET 等。
maxmemory <bytes>
需要注意的一點是，如果 Redis 是主 Redis （說明 Redis 有從 Redis ），那么在設置內存使用上限時，需要在系統中留出一些內存空間給同步隊列緩存，只有在設置的是“不移除”的情況下，才不用考慮這個因素。
對于內存移除規則來說， Redis 提供了多達6種的移除規則。他們是：
（1）volatile-lru：使用 LRU 算法移除過期集合中的 key
（2）allkeys-lru：使用 LRU 算法移除 key
（3）volatile-random：在過期集合中移除隨機的 key
（4）allkeys-random：移除隨機的 key
（5）volatile-ttl：移除那些 TTL 值最小的 key ，即那些最近才過期的 key
（6）noeviction：不進行移除。針對寫操作，只是返回錯誤信息
無論使用上述哪一種移除規則，如果沒有合適的 key 可以移除的話， Redis 都會針對寫請求返回錯誤信息。
maxmemory-policy volatile-lru
LRU算法和最小TTL算法都并非是精確的算法，而是估算值。所以可以設置樣本的大小。假如 Redis 默認會檢查三個 key 并選擇其中 LRU 的那個，那么可以改變這個 key 樣本的數量。
maxmemory-samples 3

1.6 AOF配置
默認情況下， Redis 會異步的將數據持久化到磁盤。這種模式在大部分應用程序中已被驗證是很有效的，但是在一些問題發生時，比如斷電，則這種機制可能會導致數分鐘的寫請求丟失。
如上半部分中介紹的， AOF 是一種更好的保持數據一致性的方式。即使當服務器斷電時，也僅會有1秒鐘的寫請求丟失，當 Redis 進程出現問題且操作系統運行正常時，甚至只會丟失一條寫請求。
官方建議， AOF 機制和 RDB 機制可以同時使用，不會有任何沖突。
appendonly yes
我們還可以設置 AOF 文件的名稱：
appendfilename "appendonly.aof"
fsync()調用，用來告訴操作系統立即將緩存的指令寫入磁盤。一些操作系統會“立即”進行，而另外一些操作系統則會“盡快”進行。
Redis支持三種不同的模式：
（1）no：不調用 fsync() 。而是讓操作系統自行決定 sync 的時間。這種模式下， Redis 的性能會最快。
（2）always：在每次寫請求后都調用 fsync() 。這種模式下， Redis 會相對較慢，但數據最安全。
（3）everysec：每秒鐘調用一次 fsync() 。這是性能和安全的折衷。
默認情況下為 everysec 。
appendfsync everysec
當 fsync 方式設置為 always 或 everysec 時，如果后臺持久化進程需要執行一個很大的磁盤IO操作，那么 Redis 可能會在 fsync() 調用時卡住。目前尚未修復這個問題，這是因為即使我們在另一個新的線程中去執行 fsync() ，也會阻塞住同步寫調用。
為了緩解這個問題，我們可以使用下面的配置項，這樣的話，當 BGSAVE 或 BGWRITEAOF 運行時， fsync() 在主進程中的調用會被阻止。這意味著當另一路進程正在對 AOF 文件進行重構時， Redis 的持久化功能就失效了，就好像我們設置了 “appendsync none” 一樣。如果 Redis 有時延問題，那么可以將下面的選項設置為yes。否則請保持no，因為這是保證數據完整性的最安全的選擇。
no-appendfsync-on-rewrite no
我們允許 Redis 自動重寫 aof 。當 aof 增長到一定規模時， Redis 會隱式調用 BGREWRITEAOF 來重寫log文件，以縮減文件體積。
Redis 是這樣工作的： Redis 會記錄上次重寫時的 aof 大小。假如 Redis 自啟動至今還沒有進行過重寫，那么啟動時 aof 文件的大小會被作為基準值。這個基準值會和當前的 aof 大小進行比較。如果當前 aof 大小超出所設置的增長比例，則會觸發重寫。另外還需要設置一個最小大小，是為了防止在 aof 很小時就觸發重寫。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
如果設置 auto-aof-rewrite-percentage 為0，則會關閉此重寫功能。
指Redis在恢復時，會忽略最后一條可能存在問題的指令，默認值yes。即在 aof 寫入時，可能存在指令寫錯的問題(突然斷電，寫了一半)，這種情況下，yes會log并繼續，而no會直接恢復失敗。
aof-load-truncated yes

1.7 LUA腳本配置
lua 腳本的最大運行時間是需要被嚴格限制的，單位是毫秒：
lua-time-limit 5000
如果此值設置為0或負數，則既不會有報錯也不會有時間限制。

1.8 集群設置
平常的 Redis 實例不能作為集群的節點，只有作為集群節點啟動的實例才可以。下面的配置可以是 Redis 實例作為集群節點啟動：
cluster-enabled yes
每個集群節點都有一個集群配置文件，該文件是由集群節點來創建和維護的，不能人工參與。每個集群節點需要不同的配置文件，所以需要保證同一個系統下的集群節點沒有重名的配置文件，建議以端口號標記配置文件。
cluster-config-file nodes-6379.conf
當節點超時大于 cluster-node-timeout 的時候后，就會被認為宕機了，單位為毫秒。
cluster-node-timeout 15000
Redis 集群有一種 failover （故障轉移）機制，即當主 Redis 宕機之后，會有一個最合適的從 Redis 充當主 Redis 。但是，當從 Redis 的數據“太老”了，與住 Redis 的標準數據偏差很大，為了保證數據一致性， Redis 會放棄 failover 。判別從 Redis 的的數據是不是“太老”有兩種方法：
（1）如果有多個從 Redis 可以接替主 Redis 的工作，則它們會交換信息，選取“最佳復制偏移”（接受了原主 Redis 最多的數據同步）的從 Redis 作為下一任主 Redis 。
（2）每個從Redis計算與原主Redis最后一次數據同步的時間，當最短的時間間隔大于某個臨界點的時候，集群則放棄failover。
方法（2）當中的臨界點可以通過配置調節，臨界點的計算規則為：
(node-timeout * slave-validity-factor)+ repl-ping-slave-period
如node-timeout為30秒，slave-validity-factor為10秒，repl-ping-slave-period為10秒，當與原主Redis最后一次對話的時間間隔超過310秒的時候，集群就會放棄failover。
當slave-validity-factor太大會使一臺數據“太老”的從Redis充當主Redis；而slave-validity-factor太小可能會造成找不到合適的從Redis繼任。
默認的slave-validity-factor為10。
cluster-slave-validity-factor 10
考慮一種極端情況，集群有一臺主Redis和四臺從Redis，從Redis全部掛掉，failover機制有可能造成集群只有主Redis而無從Redis的尷尬境況。為了保證集群的名副其實，可以規定，當從Redis少于某個數量時，拒絕執行failover。
cluster-migration-barrier 1
默認情況下，當集群檢測到某個哈希槽（hash slot）沒有被覆蓋（沒有任何節點為此服務）會停止接受查詢服務，如果集群部分宕機最終會導致整個集群不可用，當哈希槽重新被全覆蓋的時候會自動變為可用。如果希望那些哈希槽被覆蓋的集群節點繼續接受查詢服務，需要將cluster-require-full-coverage設置為no。
cluster-require-full-coverage yes

1.9 慢日志配置
Redis慢日志是指一個系統進行日志查詢超過了指定的時長。這個時長不包括IO操作，比如與客戶端的交互、發送響應內容等，而僅包括實際執行查詢命令的時間。
針對慢日志可以設置兩個參數，一個是執行時長，單位是微秒，另一個是慢日志的長度。當一個新的命令被寫入日志時，最老的一條會從命令日志隊列中被移除。單位是微秒，即1000000表示一秒。負數則會禁用慢日志功能，而0則表示強制記錄每一個命令。
slowlog-log-slower-than 10000
慢日志最大長度，可以隨便填寫數值，沒有上限，但要注意它會消耗內存。可以使用SLOWLOG RESET來重設這個值。
slowlog-max-len 128

1.10 延遲監控配置
Redis的延遲監控子系統會在運行時對不同操作取樣，以此來收集與延遲相關的數據，這些信息可以通過LATENCY命令以報表的形式呈現給用戶。
系統只會記錄那些執行時間等于或大于atency-monitor-threshold的操作，該值默認為0，代表關閉監控，因為收集延遲數據多少會影響Redis的性能。
latency-monitor-threshold 0

1.11事件通知配置
Redis可以向客戶端通知某些事件的發生。
例如，鍵空間（keyspace）時間通知如果開啟，一個客戶端對Database 0中的“foo”鍵執行了DEL操作，兩條信息會通過Pub/Sub發布出去：
PUBLISH__keyspace@0__:foo del
PUBLISH__keyevent@0__:del foo
可以選擇需要發送哪種類型的通知，每種類型用一個字母代表：
K 鍵空間事件,發布到“keyspace@<db> prefix”頻道
E 鍵事件, 發布到“ keyevent@<db> prefix”頻道
g 通用事件，比如 DEL,EXPIRE, RENAME, ...等操作都屬于
$ String操作
l List操作
s Set操作
h Hash操作
z Sorted set操作
x 過期操作
e 驅逐操作（因為內存不足數據被刪除）
A 代表“g$lshzxe”的組合, 所以“AKE”可以代表所有事件

notify-keyspace-events配置以上述的字母組合為參數，舉例說明：
（1）notify-keyspace-events Elg
當有List操作或通用操作，發布通知到“ keyevent@<db> prefix”頻道
（2）notify-keyspace-events Ex
當有鍵的過期操作時，發布通知到“keyevent@0:expired”頻道
默認情況下，notify-keyspace-events的參數為空字符串，代表關閉通知。
notify-keyspace-events ""

1.12 高級配置
Hash 在條目數量較小的時候會使用一種高效的內存數據結構編碼，當超過某個臨界點就會采用另一種存儲方式，該臨界點由下面的兩個配置決定：
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
與Hash類似，較小的List會以一種特殊的編碼方式來節省空間，只要List不超過下面的上限：
list-max-ziplist-entries 512
list-max-ziplist-value 64
Set只有在滿足下面的條件時才會采用特殊編碼方式：Set中存儲的恰好都是十進制的整數，而且長度不超過64位（有符號）。數量上限為：
set-max-intset-entries 512
同樣，有序集合也會采用特殊編碼來節省空間，只要不超過上限：
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
RedisHyperLogLog 是用來做基數統計的算法，HyperLogLog 的優點是，在輸入元素的數量或者體積非常非常大時，計算基數所需的空間總是固定并且很小的。當HyperLogLog用稀疏式表示法時所用內存超過下面的限制，就會轉換成稠密式表示，為了更高的內存利用率，官方建議值為3000。
hll-sparse-max-bytes 3000
Redis 在每 100 毫秒時使用 1 毫秒的 CPU時間來對 Redis 的 hash 表進行重新 hash 。當使用場景中有非常嚴格的實時性需要，不能夠接受 Redis 時不時的對請求有 2 毫秒的延遲的話，把這項配置為 no 。
如果沒有這么嚴格的實時性要求，可以設置為 yes ，以便能夠盡可能快的釋放內存。
activerehashing yes
客戶端的輸出緩沖區的限制，因為某種原因客戶端從服務器讀取數據的速度不夠快，可用于強制斷開連接（一個常見的原因是一個發布 / 訂閱客戶端消費消息的速度無法趕上生產它們的速度）。
可以三種不同客戶端的方式進行設置：
（1）normal -> 正常客戶端
（2）slave -> slave 和 MONITOR 客戶端
（3）pubsub -> 至少訂閱了一個 pubsub channel 或 pattern 的客戶端
每個client-output-buffer-limit 語法 :
client-output-buffer-limit<class> <hard limit> <soft limit> <soft seconds> 一旦達到硬限制客戶端會立即斷開，或者達到軟限制并保持達成的指定秒數（連續）。
例如，如果硬限制為 32 兆字節和軟限制為 16 兆字節 /10 秒，如果輸出緩沖區的大小達到 32 兆字節，客戶端將會立即斷開，客戶端達到 16 兆字節和連續超過了限制 10 秒，也將斷開連接。
默認 normal 客戶端不做限制，因為他們在一個請求后未要求時（以推的方式）不接收數據，只有異步客戶端可能會出現請求數據的速度比它可以讀取的速度快的場景。
把硬限制和軟限制都設置為 0 來禁用該特性
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
Redis 會按照一定的頻率來執行后臺任務，比如關閉超時的客戶端，清除過期鍵等。不是所有的任務都會按照相同的頻率來執行，但 Redis 依照指定的“ Hz ”值來執行檢查任務。
hz 10
aof rewrite 過程中，是否采取增量文件同步策略，默認為“yes”。 rewrite 過程中,每32M數據進行一次文件同步，這樣可以減少 aof 大文件寫入對磁盤的操作次數。
aof-rewrite-incremental-fsync yes