Redis是一個高性能的key-value數據庫。
Redis支持數據的持久化，可以將內存中的數據保存在磁盤中，重啟的時候可以再次加載進行使用。
Redis不僅僅支持簡單的key-value類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。
Redis支持數據的備份，即master-slave模式的數據備份。
為了更好的使用redis,我們需要詳細的了解redis配置文件及相關參數作用。
include /path/to/local.conf
額外載入配置文件，如果有需要的話，可以開啟此配置
bind 127.0.0.1 bind 192.168.1.100
綁定redis服務器網卡IP，默認為127.0.0.1,即本地回環地址。這樣的話，訪問redis服務只能通過本機的客戶端連接，而無法通過遠程連接。如果bind選項為空的話，那會接受所有來自於可用網絡接口的連接。如上配置，綁定一個127.0.0.1的本機地址和192.168.1.100的外網地址。
protected-mode yes
保護模式，默認是開啟狀態，只允許本地客戶端連接， 可以設置密碼或添加bind來連接
port 6379
監聽端口號，默認為6379，如果設為0，redis將不在socket 上監聽任何客戶端連接
tcp-backlog 511
TCP監聽的最大容納數量，在高並發的環境下，你需要把這個值調高以避免客戶端連接緩慢的問題。Linux 內核會把這個值縮小成 /proc/sys/net/core/somaxconn對應的值，要提升並發量需要修改這兩個值才能達到目的
unixsocket /tmp/redis.sock unixsocketperm 700
指定redis監聽的unix socket路徑，默認不啟用，unixsocketper指定文件的權限
timeout 0
指定在一個 client 空閑多少秒之后關閉連接（0表示永不關閉）
tcp-keepalive 300
單位是秒，表示將周期性的使用SO_KEEPALIVE檢測客戶端是否還處於健康狀態，避免服務器一直阻塞，官方給出的建議值是300s，如果設置為0，則不會周期性的檢測
daemonize yes
默認情況下 redis 不是作為守護進程運行的，如果你想讓它在后台運行，你就把它改成 yes。當redis作為守護進程運行的時候，它會寫一個 pid 到 /var/run/redis.pid 文件里面
supervised no
可以通過upstart和systemd管理Redis守護進程
選項：
supervised no - 沒有監督互動
supervised upstart - 通過將Redis置於SIGSTOP模式來啟動信號
supervised systemd - signal systemd將READY = 1寫入$ NOTIFY_SOCKET
supervised auto - 檢測upstart或systemd方法基於 UPSTART_JOB或NOTIFY_SOCKET環境變量
pidfile /var/redis/run/redis_6379.pid
配置PID文件路徑，當redis作為守護進程運行的時候，它會把 pid 默認寫到 /var/redis/run/redis_6379.pid 文件里面
loglevel notice
定義日志級別。
可以是下面的這些值：
debug（記錄大量日志信息，適用於開發、測試階段）
verbose（較多日志信息）
notice（適量日志信息，使用於生產環境）
warning（僅有部分重要、關鍵信息才會被記錄）
logfile /var/redis/log/redis_6379.log
日志文件的位置，當指定為空字符串時，為標准輸出，如果redis已守護進程模式運行，那么日志將會輸出到/dev/null
syslog-enabled no
要想把日志記錄到系統日志，就把它改成 yes，也可以可選擇性的更新其他的syslog 參數以達到你的要求
syslog-ident redis
設置系統日志的ID
syslog-facility local0
指定系統日志設置，必須是 USER 或者是 LOCAL0-LOCAL7 之間的值
databases 16
設置數據庫的數目。默認的數據庫是DB 0 ，可以在每個連接上使用select <dbid> 命令選擇一個不同的數據庫，dbid是一個介於0到databases - 1 之間的數值。
save 900 1 save 300 10 save 60 10000
存 DB 到磁盤：
格式：save <間隔時間（秒）> <寫入次數>
根據給定的時間間隔和寫入次數將數據保存到磁盤
下面的例子的意思是：
900 秒內如果至少有 1 個 key 的值變化，則保存
300 秒內如果至少有 10 個 key 的值變化，則保存
60 秒內如果至少有 10000 個 key 的值變化，則保存
注意：你可以注釋掉所有的 save 行來停用保存功能。
也可以直接一個空字符串來實現停用：
save ""
stop-writes-on-bgsave-error yes
如果用戶開啟了RDB快照功能，那么在redis持久化數據到磁盤時如果出現失敗，默認情況下，redis會停止接受所有的寫請求。
這樣做的好處在於可以讓用戶很明確的知道內存中的數據和磁盤上的數據已經存在不一致了。
如果redis不顧這種不一致，一意孤行的繼續接收寫請求，就可能會引起一些災難性的后果。
如果下一次RDB持久化成功，redis會自動恢復接受寫請求。
如果不在乎這種數據不一致或者有其他的手段發現和控制這種不一致的話，可以關閉這個功能，
以便在快照寫入失敗時，也能確保redis繼續接受新的寫請求。
rdbcompression yes
對於存儲到磁盤中的快照，可以設置是否進行壓縮存儲。
如果是的話，redis會采用LZF算法進行壓縮。如果你不想消耗CPU來進行壓縮的話，
可以設置為關閉此功能，但是存儲在磁盤上的快照會比較大。
rdbchecksum yes
在存儲快照后，我們還可以讓redis使用CRC64算法來進行數據校驗，但是這樣做會增加大約10%的性能消耗，
如果希望獲取到最大的性能提升，可以關閉此功能。
dbfilename dump.rdb
設置快照的文件名
dir /var/redis/6379
設置快照文件的存放路徑，這個配置項一定是個目錄，而不能是文件名
slaveof <masterip> <masterport>
主從復制，使用 slaveof 來讓一個 redis 實例成為另一個reids 實例的副本，默認關閉
注意這個只需要在 slave 上配置
masterauth <master-password>
如果 master 需要密碼認證，就在這里設置，默認不設置
slave-serve-stale-data yes
當一個 slave 與 master 失去聯系，或者復制正在進行的時候，
slave 可能會有兩種表現：
1) 如果為 yes ，slave 仍然會應答客戶端請求，但返回的數據可能是過時，
或者數據可能是空的在第一次同步的時候
2) 如果為 no ，在你執行除了 info he salveof 之外的其他命令時，
slave 都將返回一個 "SYNC with master in progress" 的錯誤
slave-read-only yes
你可以配置一個 slave 實體是否接受寫入操作。
通過寫入操作來存儲一些短暫的數據對於一個 slave 實例來說可能是有用的，
因為相對從 master 重新同步數而言，據數據寫入到 slave 會更容易被刪除。
但是如果客戶端因為一個錯誤的配置寫入，也可能會導致一些問題。
從 redis 2.6 版起，默認 slaves 都是只讀的。
repl-diskless-sync no
主從數據復制是否使用無硬盤復制功能。
新的從站和重連后不能繼續備份的從站，需要做所謂的“完全備份”，即將一個RDB文件從主站傳送到從站。
這個傳送有以下兩種方式：
1）硬盤備份：redis主站創建一個新的進程，用於把RDB文件寫到硬盤上。過一會兒，其父進程遞增地將文件傳送給從站。
2）無硬盤備份：redis主站創建一個新的進程，子進程直接把RDB文件寫到從站的套接字，不需要用到硬盤。
在硬盤備份的情況下，主站的子進程生成RDB文件。一旦生成，多個從站可以立即排成隊列使用主站的RDB文件。
在無硬盤備份的情況下，一次RDB傳送開始，新的從站到達后，需要等待現在的傳送結束，才能開啟新的傳送。
如果使用無硬盤備份，主站會在開始傳送之間等待一段時間（可配置，以秒為單位），希望等待多個子站到達后並行傳送。
在硬盤低速而網絡高速（高帶寬）情況下，無硬盤備份更好。
repl-diskless-sync-delay 5
當啟用無硬盤備份，服務器等待一段時間后才會通過套接字向從站傳送RDB文件，這個等待時間是可配置的。
這一點很重要，因為一旦傳送開始，就不可能再為一個新到達的從站服務。從站則要排隊等待下一次RDB傳送。因此服務器等待一段
時間以期更多的從站到達。
延遲時間以秒為單位，默認為5秒。要關掉這一功能，只需將它設置為0秒，傳送會立即啟動。
repl-ping-slave-period 10
從redis會周期性的向主redis發出PING包，你可以通過repl_ping_slave_period指令來控制其周期，默認是10秒。
repl-timeout 60
接下來的選項為以下內容設置備份的超時時間：
1）從從站的角度，同步期間的批量傳輸的I/O
2）從站角度認為的主站超時（數據，ping）
3）主站角度認為的從站超時（REPLCONF ACK pings)
確認這些值比定義的repl-ping-slave-period要大，否則每次主站和從站之間通信低速時都會被檢測為超時。
repl-disable-tcp-nodelay no
同步之后是否禁用從站上的TCP_NODELAY
如果你選擇yes，redis會使用較少量的TCP包和帶寬向從站發送數據。但這會導致在從站增加一點數據的延時。
Linux內核默認配置情況下最多40毫秒的延時。
如果選擇no，從站的數據延時不會那么多，但備份需要的帶寬相對較多。
默認情況下我們將潛在因素優化，但在高負載情況下或者在主從站都跳的情況下，把它切換為yes是個好主意。
repl-backlog-size 1mb
設置備份的工作儲備大小。工作儲備是一個緩沖區，當從站斷開一段時間的情況時，它替從站接收存儲數據，
因此當從站重連時，通常不需要完全備份，只需要一個部分同步就可以，即把從站斷開時錯過的一部分數據接收。
工作儲備越大，從站可以斷開並稍后執行部分同步的斷開時間就越長。
只要有一個從站連接，就會立刻分配一個工作儲備。
repl-backlog-ttl 3600
主站有一段時間沒有與從站連接，對應的工作儲備就會自動釋放。
這個選項用於配置釋放前等待的秒數，秒數從斷開的那一刻開始計算，值為0表示不釋放。
slave-priority 100
從站優先級是可以從redis的INFO命令輸出中查到的一個整數。當主站不能正常工作時
redis sentinel使用它來選擇一個從站並將它提升為主站。
低優先級的從站被認為更適合於提升，因此如果有三個從站優先級分別是10，
100，25，sentinel會選擇優先級為10的從站，因為它的優先級最低。
然而優先級值為0的從站不能執行主站的角色，因此優先級為0的從站永遠不會被redis sentinel提升。
默認優先級是100
min-slaves-to-write 3 min-slaves-max-lag 10
主站可以停止接受寫請求，當與它連接的從站少於N個，滯后少於M秒，N個從站必須是在線狀態。
延遲的秒數必須<=所定義的值，延遲秒數是從最后一次收到的來自從站的ping開始計算。ping通常是每秒一次。
這一選項並不保證N個備份都會接受寫請求，但是會限制在指定秒數內由於從站數量不夠導致的寫操作丟失的情況。
如果想要至少3個從站且延遲少於10秒，如上配置即可
slave-announce-ip 5.5.5.5 slave-announce-port 1234
Redis master能夠以不同的方式列出所連接slave的地址和端口。
例如，“INFO replication”部分提供此信息，除了其他工具之外，Redis Sentinel還使用該信息來發現slave實例。
此信息可用的另一個地方在masterser的“ROLE”命令的輸出中。
通常由slave報告的列出的IP和地址,通過以下方式獲得：
IP：通過檢查slave與master連接使用的套接字的對等體地址自動檢測地址。
端口：端口在復制握手期間由slavet通信，並且通常是slave正在使用列出連接的端口。
然而，當使用端口轉發或網絡地址轉換（NAT）時，slave實際上可以通過(不同的IP和端口對)來到達。 slave可以使用以下兩個選項，以便向master報告一組特定的IP和端口，
以便INFO和ROLE將報告這些值。
如果你需要僅覆蓋端口或IP地址，則沒必要使用這兩個選項。
requirepass foobared
設置redis連接密碼
rename-command CONFIG ""
將命令重命名，為了安全考慮，可以將某些重要的、危險的命令重命名。
當你把某個命令重命名成空字符串的時候就等於取消了這個命令。
maxclients 10000
設置客戶端最大並發連接數，默認無限制，Redis可以同時打開的客戶端連接數為Redis進程可以打開的最大文件
描述符數-32（redis server自身會使用一些），如果設置 maxclients為0
表示不作限制。當客戶端連接數到達限制時，Redis會關閉新的連接並向客戶端返回max number of clients reached錯誤信息
maxmemory <bytes>
指定Redis最大內存限制，Redis在啟動時會把數據加載到內存中，達到最大內存后，Redis會先嘗試清除已到期或即將到期的Key
當此方法處理 后，仍然到達最大內存設置，將無法再進行寫入操作，但仍然可以進行讀取操作。Redis新的vm機制，
會把Key存放內存，Value會存放在swap區，格式：maxmemory <bytes>
maxmemory-policy noeviction
當內存使用達到最大值時，redis使用的清楚策略。有以下幾種可以選擇：
1）volatile-lru 利用LRU算法移除設置過過期時間的key (LRU:最近使用 Least Recently Used )
2）allkeys-lru 利用LRU算法移除任何key
3）volatile-random 移除設置過過期時間的隨機key
4）allkeys-random 移除隨機ke
5）volatile-ttl 移除即將過期的key(minor TTL)
6）noeviction noeviction 不移除任何key，只是返回一個寫錯誤 ，默認選項
maxmemory-samples 5
LRU 和 minimal TTL 算法都不是精准的算法，但是相對精確的算法(為了節省內存)
隨意你可以選擇樣本大小進行檢，redis默認選擇3個樣本進行檢測，你可以通過maxmemory-samples進行設置樣本數
appendonly no
默認redis使用的是rdb方式持久化，這種方式在許多應用中已經足夠用了。但是redis如果中途宕機，
會導致可能有幾分鍾的數據丟失，根據save來策略進行持久化，Append Only File是另一種持久化方式，
可以提供更好的持久化特性。Redis會把每次寫入的數據在接收后都寫入appendonly.aof文件，
每次啟動時Redis都會先把這個文件的數據讀入內存里，先忽略RDB文件。
appendfilename "appendonly.aof"
aof文件名
appendfsync always
appendfsync everysec
appendfsync no
aof持久化策略的配置
no表示不執行fsync，由操作系統保證數據同步到磁盤，速度最快。
always表示每次寫入都執行fsync，以保證數據同步到磁盤。
everysec表示每秒執行一次fsync，可能會導致丟失這1s數據
no-appendfsync-on-rewrite no
在aof重寫或者寫入rdb文件的時候，會執行大量IO，此時對於everysec和always的aof模式來說，
執行fsync會造成阻塞過長時間，no-appendfsync-on-rewrite字段設置為默認設置為no。
如果對延遲要求很高的應用，這個字段可以設置為yes，否則還是設置為no，這樣對持久化特性來說這是更安全的選擇。
設置為yes表示rewrite期間對新寫操作不fsync,暫時存在內存中,等rewrite完成后再寫入，默認為no，建議yes。
Linux的默認fsync策略是30秒。可能丟失30秒數據。
auto-aof-rewrite-percentage 100
aof自動重寫配置，當目前aof文件大小超過上一次重寫的aof文件大小的百分之多少進行重寫，
即當aof文件增長到一定大小的時候，Redis能夠調用bgrewriteaof對日志文件進行重寫。
當前AOF文件大小是上次日志重寫得到AOF文件大小的二倍（設置為100）時，自動啟動新的日志重寫過程。
auto-aof-rewrite-min-size 64mb
設置允許重寫的最小aof文件大小，避免了達到約定百分比但尺寸仍然很小的情況還要重寫
aof-load-truncated yes
aof文件可能在尾部是不完整的，當redis啟動的時候，aof文件的數據被載入內存。
重啟可能發生在redis所在的主機操作系統宕機后，尤其在ext4文件系統沒有加上data=ordered選項，出現這種現象
redis宕機或者異常終止不會造成尾部不完整現象，可以選擇讓redis退出，或者導入盡可能多的數據。
如果選擇的是yes，當截斷的aof文件被導入的時候，會自動發布一個log給客戶端然后load。
如果是no，用戶必須手動redis-check-aof修復AOF文件才可以。
lua-time-limit 5000
如果達到最大時間限制（毫秒），redis會記個log，然后返回error。當一個腳本超過了最大時限。
只有SCRIPT KILL和SHUTDOWN NOSAVE可以用。第一個可以殺沒有調write命令的東西。
要是已經調用了write，只能用第二個命令殺
cluster-enabled yes
集群開關，默認是不開啟集群模式
cluster-config-file nodes-6379.conf
集群配置文件的名稱，每個節點都有一個集群相關的配置文件，持久化保存集群的信息。
這個文件並不需要手動配置，這個配置文件有Redis生成並更新，每個Redis集群節點需要一個單獨的配置文件
請確保與實例運行的系統中配置文件名稱不沖突
cluster-node-timeout 15000
節點互連超時的閥值，集群節點超時毫秒數
cluster-slave-validity-factor 10
在進行故障轉移的時候，全部slave都會請求申請為master，但是有些slave可能與master斷開連接一段時間了，
導致數據過於陳舊，這樣的slave不應該被提升為master。該參數就是用來判斷slave節點與master斷線的時間是否過長。
判斷方法是：
比較slave斷開連接的時間和(node-timeout * slave-validity-factor) + repl-ping-slave-period
如果節點超時時間為三十秒, 並且slave-validity-factor為10,
假設默認的repl-ping-slave-period是10秒，即如果超過310秒slave將不會嘗試進行故障轉移
cluster-migration-barrier 1
master的slave數量大於該值，slave才能遷移到其他孤立master上，如這個參數若被設為2，
那么只有當一個主節點擁有2 個可工作的從節點時，它的一個從節點會嘗試遷移。
cluster-require-full-coverage yes
默認情況下，集群全部的slot有節點負責，集群狀態才為ok，才能提供服務。
設置為no，可以在slot沒有全部分配的時候提供服務。
不建議打開該配置，這樣會造成分區的時候，小分區的master一直在接受寫請求，而造成很長時間數據不一致
slowlog-log-slower-than 10000
slog log是用來記錄redis運行中執行比較慢的命令耗時。
當命令的執行超過了指定時間，就記錄在slow log中，slog log保存在內存中，所以沒有IO操作。
執行時間比slowlog-log-slower-than大的請求記錄到slowlog里面，單位是微秒，所以1000000就是1秒。
注意，負數時間會禁用慢查詢日志，而0則會強制記錄所有命令。
slowlog-max-len 128
慢查詢日志長度。當一個新的命令被寫進日志的時候，最老的那個記錄會被刪掉，這個長度沒有限制。
只要有足夠的內存就行，你可以通過 SLOWLOG RESET 來釋放內存
latency-monitor-threshold 0
延遲監控功能是用來監控redis中執行比較緩慢的一些操作，用LATENCY打印redis實例在跑命令時的耗時圖表。
只記錄大於等於下邊設置的值的操作，0的話，就是關閉監視。
默認延遲監控功能是關閉的，如果你需要打開，也可以通過CONFIG SET命令動態設置。
notify-keyspace-events ""
鍵空間通知使得客戶端可以通過訂閱頻道或模式，來接收那些以某種方式改動了 Redis 數據集的事件。因為開啟鍵空間通知功能需要消耗一些 CPU ，所以在默認配置下，該功能處於關閉狀態。
notify-keyspace-events 的參數可以是以下字符的任意組合，它指定了服務器該發送哪些類型的通知：
K 鍵空間通知，所有通知以 __keyspace@__ 為前綴
E 鍵事件通知，所有通知以 __keyevent@__ 為前綴
g DEL 、 EXPIRE 、 RENAME 等類型無關的通用命令的通知
$ 字符串命令的通知
l 列表命令的通知
s 集合命令的通知
h 哈希命令的通知
z 有序集合命令的通知
x 過期事件：每當有過期鍵被刪除時發送
e 驅逐(evict)事件：每當有鍵因為 maxmemory 政策而被刪除時發送
A 參數 g$lshzxe 的別名
輸入的參數中至少要有一個 K 或者 E，否則的話，不管其余的參數是什么，都不會有任何 通知被分發。
hash-max-ziplist-entries 512
hash類型的數據結構在編碼上可以使用ziplist和hashtable。
ziplist的特點就是文件存儲(以及內存存儲)所需的空間較小,在內容較小時,性能和hashtable幾乎一樣。
因此redis對hash類型默認采取ziplist。如果hash中條目的條目個數或者value長度達到閥值,將會被重構為hashtable。
這個參數指的是ziplist中允許存儲的最大條目個數，，默認為512，建議為128
hash-max-ziplist-value 64
ziplist中允許條目value值最大字節數，默認為64，建議為1024
list-max-ziplist-size -2
當取正值的時候，表示按照數據項個數來限定每個quicklist節點上的ziplist長度。比如，當這個參數配置成5的時候，表示每個quicklist節點的ziplist最多包含5個數據項。
當取負值的時候，表示按照占用字節數來限定每個quicklist節點上的ziplist長度。這時，它只能取-1到-5這五個值，每個值含義如下：
-5: 每個quicklist節點上的ziplist大小不能超過64 Kb。（注：1kb => 1024 bytes）
-4: 每個quicklist節點上的ziplist大小不能超過32 Kb。
-3: 每個quicklist節點上的ziplist大小不能超過16 Kb。
-2: 每個quicklist節點上的ziplist大小不能超過8 Kb。（-2是Redis給出的默認值）
-1: 每個quicklist節點上的ziplist大小不能超過4 Kb。
list-compress-depth 0
這個參數表示一個quicklist兩端不被壓縮的節點個數。
注：這里的節點個數是指quicklist雙向鏈表的節點個數，而不是指ziplist里面的數據項個數。
實際上，一個quicklist節點上的ziplist，如果被壓縮，就是整體被壓縮的。
參數list-compress-depth的取值含義如下：
0: 是個特殊值，表示都不壓縮。這是Redis的默認值。
1: 表示quicklist兩端各有1個節點不壓縮，中間的節點壓縮。
2: 表示quicklist兩端各有2個節點不壓縮，中間的節點壓縮。
3: 表示quicklist兩端各有3個節點不壓縮，中間的節點壓縮。
依此類推…
由於0是個特殊值，很容易看出quicklist的頭節點和尾節點總是不被壓縮的，以便於在表的兩端進行快速存取。
set-max-intset-entries 512
數據量小於等於set-max-intset-entries用intset，大於set-max-intset-entries用set
zset-max-ziplist-entries 128 zset-max-ziplist-value 64
數據量小於等於zset-max-ziplist-entries用ziplist，大於zset-max-ziplist-entries用zset
hll-sparse-max-bytes 3000
value大小小於等於hll-sparse-max-bytes使用稀疏數據結構（sparse）
大於hll-sparse-max-bytes使用稠密的數據結構（dense），一個比16000大的value是幾乎沒用的，
建議的value大概為3000。如果對CPU要求不高，對空間要求較高的，建議設置到10000左右
activerehashing yes
Redis將在每100毫秒時使用1毫秒的CPU時間來對redis的hash表進行重新hash，可以降低內存的使用。
當你的使用場景中，有非常嚴格的實時性需要，不能夠接受Redis時不時的對請求有2毫秒的延遲的話，把這項配置為no。
如果沒有這么嚴格的實時性要求，可以設置為yes，以便能夠盡可能快的釋放內存
client-output-buffer-limit normal 0 0 0
對客戶端輸出緩沖進行限制可以強迫那些不從服務器讀取數據的客戶端斷開連接，用來強制關閉傳輸緩慢的客戶端。
對於normal client，第一個0表示取消hard limit，第二個0和第三個0表示取消soft limit，normal client默認取消限制，因為如果沒有尋問，他們是不會接收數據的
client-output-buffer-limit slave 256mb 64mb 60
對於slave client和MONITER client，如果client-output-buffer一旦超過256mb，又或者超過64mb持續60秒，那么服務器就會立即斷開客戶端連接。
client-output-buffer-limit pubsub 32mb 8mb 60
對於pubsub client，如果client-output-buffer一旦超過32mb，又或者超過8mb持續60秒，那么服務器就會立即斷開客戶端連接。
hz 10
redis執行任務的頻率為1s除以hz
aof-rewrite-incremental-fsync yes
在aof重寫的時候，如果打開了aof-rewrite-incremental-fsync開關，系統會每32MB執行一次fsync。
這對於把文件寫入磁盤是有幫助的，可以避免過大的延遲峰值