上一篇博客咱們介紹瞭如何安裝Redis,在Redis的解壓目錄下有個很重要的配置文件 redis.conf (/opt/redis-4.0.9目錄下),關於Redis的不少功能的配置都在此文件中完成的,在上一講我也說過,通常爲了避免破壞安裝的文件,出廠默認配置最好不要去改,因此咱們將此配置文件複製到 /etc/redis/目錄下了。node
經過 vim /etc/redis/redis.conf 命令打開此文件。下面咱們將詳細介紹此配置文件。redis
ps:你們不懂這些配置意思不要緊,後面會在具體實例中進行介紹,先過個眼熟便可。算法
這裏沒什麼好說的,須要注意的是後面須要使用內存大小時,能夠指定單位,一般是以 k,gb,m的形式出現,而且單位不區分大小寫。數據庫
咱們知道Redis只有一個配置文件,若是多我的進行開發維護,那麼就須要多個這樣的配置文件,這時候多個配置文件就能夠在此經過 include /path/to/local.conf 配置進來,而本來的 redis.conf 配置文件就做爲一個總閘。vim
ps:若是用過struts2 開發的同窗,在項目組中多人開發的狀況下,一般會有多個struts2.xml 文件,這時候也會經過類時的配置引入進來。緩存
另外須要注意的時,若是將此配置寫在redis.conf 文件的開頭,那麼後面的配置會覆蓋引入文件的配置,若是想以引入文件的配置爲主,那麼須要將 include 配置寫在 redis.conf 文件的末尾。安全
redis3.0的爆炸功能是新增了集羣,而redis4.0就是在3.0的基礎上新增了許多功能,其中這裏的 自定義模塊配置就是其中之一。經過這裏的 loadmodule 配置將引入自定義模塊來新增一些功能。服務器
ps:這裏的配置較長,我只截取了一部分,下同。網絡
①、bind:綁定redis服務器網卡IP,默認爲127.0.0.1,即本地迴環地址。這樣的話,訪問redis服務只能經過本機的客戶端鏈接,而沒法經過遠程鏈接。若是bind選項爲空的話,那會接受全部來自於可用網絡接口的鏈接。併發
②、port:指定redis運行的端口,默認是6379。因爲Redis是單線程模型,所以單機開多個Redis進程的時候會修改端口。
③、timeout:設置客戶端鏈接時的超時時間,單位爲秒。當客戶端在這段時間內沒有發出任何指令,那麼關閉該鏈接。默認值爲0,表示不關閉。
④、tcp-keepalive :單位是秒,表示將週期性的使用SO_KEEPALIVE檢測客戶端是否還處於健康狀態,避免服務器一直阻塞,官方給出的建議值是300s,若是設置爲0,則不會週期性的檢測。
具體配置詳解:
①、daemonize:設置爲yes表示指定Redis以守護進程的方式啓動(後臺啓動)。默認值爲 no
②、pidfile:配置PID文件路徑,當redis做爲守護進程運行的時候,它會把 pid 默認寫到 /var/redis/run/redis_6379.pid 文件裏面
③、loglevel :定義日誌級別。默認值爲notice,有以下4種取值:
debug(記錄大量日誌信息,適用於開發、測試階段)
verbose(較多日誌信息)
notice(適量日誌信息,使用於生產環境)
warning(僅有部分重要、關鍵信息纔會被記錄)
④、logfile :配置log文件地址,默認打印在命令行終端的窗口上
⑤、databases:設置數據庫的數目。默認的數據庫是DB 0 ,能夠在每一個鏈接上使用select <dbid> 命令選擇一個不一樣的數據庫,dbid是一個介於0到databases - 1 之間的數值。默認值是 16,也就是說默認Redis有16個數據庫。
這裏的配置主要用來作持久化操做。
①、save:這裏是用來配置觸發 Redis的持久化條件,也就是何時將內存中的數據保存到硬盤。默認以下配置:
save 900 1:表示900 秒內若是至少有 1 個 key 的值變化,則保存 save 300 10:表示300 秒內若是至少有 10 個 key 的值變化,則保存 save 60 10000:表示60 秒內若是至少有 10000 個 key 的值變化,則保存
固然若是你只是用Redis的緩存功能,不須要持久化,那麼你能夠註釋掉全部的 save 行來停用保存功能。能夠直接一個空字符串來實現停用:save ""
②、stop-writes-on-bgsave-error :默認值爲yes。當啓用了RDB且最後一次後臺保存數據失敗,Redis是否中止接收數據。這會讓用戶意識到數據沒有正確持久化到磁盤上,不然沒有人會注意到災難(disaster)發生了。若是Redis重啓了,那麼又能夠從新開始接收數據了
③、rdbcompression ;默認值是yes。對於存儲到磁盤中的快照,能夠設置是否進行壓縮存儲。若是是的話,redis會採用LZF算法進行壓縮。若是你不想消耗CPU來進行壓縮的話,能夠設置爲關閉此功能,可是存儲在磁盤上的快照會比較大。
④、rdbchecksum :默認值是yes。在存儲快照後,咱們還可讓redis使用CRC64算法來進行數據校驗,可是這樣作會增長大約10%的性能消耗,若是但願獲取到最大的性能提高,能夠關閉此功能。
⑤、dbfilename :設置快照的文件名,默認是 dump.rdb
⑥、dir:設置快照文件的存放路徑,這個配置項必定是個目錄,而不能是文件名。使用上面的 dbfilename 做爲保存的文件名。
①、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:配置Redis的Slave實例是否接受寫操做,即Slave是否爲只讀Redis。默認值爲yes。
③、repl-diskless-sync:主從數據複製是否使用無硬盤複製功能。默認值爲no。
④、repl-diskless-sync-delay:當啓用無硬盤備份,服務器等待一段時間後纔會經過套接字向從站傳送RDB文件,這個等待時間是可配置的。 這一點很重要,由於一旦傳送開始,就不可能再爲一個新到達的從站服務。從站則要排隊等待下一次RDB傳送。所以服務器等待一段 時間以期更多的從站到達。延遲時間以秒爲單位,默認爲5秒。要關掉這一功能,只需將它設置爲0秒,傳送會當即啓動。默認值爲5。
⑤、repl-disable-tcp-nodelay:同步以後是否禁用從站上的TCP_NODELAY 若是你選擇yes,redis會使用較少許的TCP包和帶寬向從站發送數據。但這會致使在從站增長一點數據的延時。 Linux內核默認配置狀況下最多40毫秒的延時。若是選擇no,從站的數據延時不會那麼多,但備份須要的帶寬相對較多。默認狀況下咱們將潛在因素優化,但在高負載狀況下或者在主從站都跳的狀況下,把它切換爲yes是個好主意。默認值爲no。
①、rename-command:命令重命名,對於一些危險命令例如:
flushdb(清空數據庫)
flushall(清空全部記錄)
config(客戶端鏈接後可配置服務器)
keys(客戶端鏈接後可查看全部存在的鍵)
做爲服務端redis-server,經常須要禁用以上命令來使得服務器更加安全,禁用的具體作法是是:
也能夠保留命令可是不能輕易使用,重命名這個命令便可:
這樣,重啓服務器後則須要使用新命令來執行操做,不然服務器會報錯unknown command。
①、maxclients :設置客戶端最大併發鏈接數,默認無限制,Redis能夠同時打開的客戶端鏈接數爲Redis進程能夠打開的最大文件。 描述符數-32(redis server自身會使用一些),若是設置 maxclients爲0 。表示不做限制。當客戶端鏈接數到達限制時,Redis會關閉新的鏈接並向客戶端返回max number of clients reached錯誤信息
①、maxmemory:設置客戶端最大併發鏈接數,默認無限制,Redis能夠同時打開的客戶端鏈接數爲Redis進程能夠打開的最大文件。描述符數-32(redis server自身會使用一些),若是設置 maxclients爲0 。表示不做限制。當客戶端鏈接數到達限制時,Redis會關閉新的鏈接並向客戶端返回max number of clients reached錯誤信息。
②、maxmemory-policy :當內存使用達到最大值時,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 :LRU 和 minimal TTL 算法都不是精準的算法,可是相對精確的算法(爲了節省內存)。隨意你能夠選擇樣本大小進行檢,redis默認選擇3個樣本進行檢測,你能夠經過maxmemory-samples進行設置樣本數。
①、appendonly:默認redis使用的是rdb方式持久化,這種方式在許多應用中已經足夠用了。可是redis若是中途宕機,會致使可能有幾分鐘的數據丟失,根據save來策略進行持久化,Append Only File是另外一種持久化方式, 能夠提供更好的持久化特性。Redis會把每次寫入的數據在接收後都寫入appendonly.aof文件,每次啓動時Redis都會先把這個文件的數據讀入內存裏,先忽略RDB文件。默認值爲no。
②、appendfilename :aof文件名,默認是"appendonly.aof"
③、appendfsync:aof持久化策略的配置;no表示不執行fsync,由操做系統保證數據同步到磁盤,速度最快;always表示每次寫入都執行fsync,以保證數據同步到磁盤;everysec表示每秒執行一次fsync,可能會致使丟失這1s數據
④、no-appendfsync-on-rewrite:在aof重寫或者寫入rdb文件的時候,會執行大量IO,此時對於everysec和always的aof模式來講,執行fsync會形成阻塞過長時間,no-appendfsync-on-rewrite字段設置爲默認設置爲no。若是對延遲要求很高的應用,這個字段能夠設置爲yes,不然仍是設置爲no,這樣對持久化特性來講這是更安全的選擇。 設置爲yes表示rewrite期間對新寫操做不fsync,暫時存在內存中,等rewrite完成後再寫入,默認爲no,建議yes。Linux的默認fsync策略是30秒。可能丟失30秒數據。默認值爲no。
⑤、auto-aof-rewrite-percentage:默認值爲100。aof自動重寫配置,當目前aof文件大小超過上一次重寫的aof文件大小的百分之多少進行重寫,即當aof文件增加到必定大小的時候,Redis可以調用bgrewriteaof對日誌文件進行重寫。當前AOF文件大小是上第二天志重寫獲得AOF文件大小的二倍(設置爲100)時,自動啓動新的日誌重寫過程。
⑥、auto-aof-rewrite-min-size:64mb。設置容許重寫的最小aof文件大小,避免了達到約定百分比但尺寸仍然很小的狀況還要重寫。
⑦、aof-load-truncated:aof文件可能在尾部是不完整的,當redis啓動的時候,aof文件的數據被載入內存。重啓可能發生在redis所在的主機操做系統宕機後,尤爲在ext4文件系統沒有加上data=ordered選項,出現這種現象 redis宕機或者異常終止不會形成尾部不完整現象,能夠選擇讓redis退出,或者導入儘量多的數據。若是選擇的是yes,當截斷的aof文件被導入的時候,會自動發佈一個log給客戶端而後load。若是是no,用戶必須手動redis-check-aof修復AOF文件才能夠。默認值爲 yes。
①、lua-time-limit:一個lua腳本執行的最大時間,單位爲ms。默認值爲5000.
①、cluster-enabled:集羣開關,默認是不開啓集羣模式。
②、cluster-config-file:集羣配置文件的名稱,每一個節點都有一個集羣相關的配置文件,持久化保存集羣的信息。 這個文件並不須要手動配置,這個配置文件有Redis生成並更新,每一個Redis集羣節點須要一個單獨的配置文件。請確保與實例運行的系統中配置文件名稱不衝突。默認配置爲nodes-6379.conf。
③、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:默認狀況下,集羣所有的slot有節點負責,集羣狀態才爲ok,才能提供服務。 設置爲no,能夠在slot沒有所有分配的時候提供服務。不建議打開該配置,這樣會形成分區的時候,小分區的master一直在接受寫請求,而形成很長時間數據不一致。