Redis版本
redis-5.0.4 3
追加模式
默認情況下，Redis異步將數據集轉儲到磁盤上。 此模式在許多應用程序中已經足夠好，但是Redis進程問題或斷電可能會導致幾分鐘的寫入丟失（取決於配置的保存點）。
僅附加文件是一種替代的持久性模式，可提供更好的持久性。 例如，使用默認數據fsync策略（請參閱配置文件中的後面部分），Redis在嚴重的事件（例如服務器斷電）中僅會丟失一秒鐘的寫入，如果Redis進程本身發生問題，則可能會丟失一次寫入，但是 操作系統仍在正常運行。
可以同時啟用AOF和RDB持久性，而不會出現問題。 如果在啟動時啟用了AOF，則Redis將加載AOF，即該文件具有更好的持久性保證。
請檢查http://redis.io/topics/persistence以獲取更多信息。
<code>appendonly no/<code>
僅附加文件的名稱（默認值：“ appendonly.aof”）
<code>appendfilename "appendonly.aof"/<code>
fsync（）調用告訴操作系統將數據實際寫在磁盤上，而不是等待輸出緩衝區中的更多數據。某些OS確實會刷新磁盤上的數據，而其他OS會嘗試儘快進行處理。
Redis支持三種不同的模式：
no：不要fsync，只要讓OS在需要時刷新數據即可。快點。
always：每次寫入僅附加日誌後，fsync。慢，最安全。
everysec：每秒僅同步一次fsync。妥協。
默認值為“ everysec”，因為這通常是速度和數據安全性之間的正確折衷。您可以瞭解是否可以將其放鬆為“ no”，這將使操作系統在需要時刷新輸出緩衝區，以獲得更好的性能（但是如果您可以忍受某些數據丟失的想法，請考慮使用默認的持久模式（即快照），或者相反，請使用“always”，該速度非常慢，但比秒安全。
更多詳細信息，請查看以下文章：
http://antirez.com/post/redis-persistence-demystified.html
如果不確定，請使用“ everysec”。
<code># appendfsync alwaysappendfsync everysec# appendfsync no/<code>
當AOF fsync策略設置為always或everysec，並且後臺保存進程（後臺保存或AOF日誌後臺重寫）對磁盤執行大量I / O時，在某些Linux配置中，Redis可能在磁盤上阻塞太長時間。 fsync（）調用。 請注意，目前尚無此修復程序，因為即使在其他線程中執行fsync也將阻塞我們的同步write（2）調用。
為了緩解此問題，可以使用以下選項來防止在BGSAVE或BGREWRITEAOF進行時在主進程中調用fsync（）。
這意味著當另一個孩子正在保存時，Redis的持久性與“ appendfsync none”相同。 實際上，這意味著在最壞的情況下（使用默認的Linux設置）可能會丟失多達30秒的日誌。
如果您有延遲問題，請將其設置為“是”。 否則，從耐用性的角度來看，將其保留為“最不安全”的選擇。
<code>no-appendfsync-on-rewrite no/<code>
自動重寫僅附加文件。當AOF日誌大小增加指定的百分比時，Redis能夠自動隱式調用BGREWRITEAOF重寫日誌文件。
它是這樣工作的：Redis在最近一次重寫後會記住AOF文件的大小（如果自重新啟動以來未發生任何重寫，則使用啟動時AOF的大小）。
將此基本大小與當前大小進行比較。 如果當前大小大於指定的百分比，則會觸發重寫。 另外，您需要指定要重寫的AOF文件的最小大小，這對避免重寫AOF文件很有用，即使達到百分比增加但它仍然很小。
指定零百分比以禁用自動AOF重寫功能。
<code>auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb/<code>
當AOF數據重新加載到內存中時，在Redis啟動過程中可能會發現AOF文件在末尾被截斷，這可能在運行Redis的系統崩潰時尤其是在沒有數據的情況下掛載ext4文件系統時發生= ordered選項（但是，當Redis本身崩潰或中止但操作系統仍然可以正常運行時，不會發生這種情況）。
發生這種情況時，Redis可以退出並顯示錯誤，也可以加載儘可能多的數據（當前為默認值），如果發現AOF文件最後被截斷，則Redis可以啟動。以下選項控制此行為。
如果aof-load-truncated設置為yes，則將加載截短的AOF文件，並且Redis服務器將開始發出日誌以將事件通知用戶。否則，如果該選項設置為no，則服務器將中止並顯示錯誤，並拒絕啟動。如果該選項設置為no，則用戶需要在重新啟動服務器之前使用“ redis-check-aof”實用程序修復AOF文件。
請注意，如果在中間發現AOF文件已損壞，則服務器仍將退出並出現錯誤。僅當Redis嘗試從AOF文件讀取更多數據但找不到足夠的字節時，此選項才適用。
<code>aof-load-truncated yes/<code>
重寫AOF文件時，Redis可以使用AOF文件中的RDB前同步碼來更快地進行重寫和恢復。 啟用此選項後，重寫的AOF文件由兩個不同的節組成：
[RDB文件] [AOF尾巴]
加載時，Redis會識別AOF文件以“ REDIS”字符串開頭並加載帶前綴的RDB文件，然後繼續加載AOF尾部。
<code>aof-use-rdb-preamble yes/<code>
LUA腳本
Lua腳本的最大執行時間（以毫秒為單位）。
如果達到了最大執行時間，Redis將記錄在允許的最大時間後腳本仍在執行中，並將開始以錯誤答覆查詢。
如果長時間運行的腳本超過了最大執行時間，則只有“ SCRIPT KILL”和“ SHUTDOWN NOSAVE”命令可用。 第一個可用於停止尚未調用寫命令的腳本。 第二種是在腳本已發出寫命令但用戶不想等待腳本自然終止的情況下關閉服務器的唯一方法。
將其設置為0或負值可無警告地無限執行。
<code>lua-time-limit 5000/<code>
REDIS集群
警告實驗：Redis Cluster被認為是穩定的代碼，但是為了將其標記為“成熟”，我們需要等待不小的用戶百分比將其部署到生產環境中。
普通Redis實例不能屬於Redis集群； 只有作為群集節點啟動的節點可以。 為了將Redis實例作為群集節點啟動，請在不註釋以下內容的情況下啟用群集支持：
<code># cluster-enabled yes/<code>
每個群集節點都有一個群集配置文件。 該文件不適合手工編輯。 它由Redis節點創建和更新。 每個Redis群集節點都需要一個不同的群集配置文件。確保在同一系統中運行的實例沒有重疊的群集配置文件名。
<code># cluster-config-file nodes-6379.conf/<code>
群集節點超時是節點必須處於不可達狀態的毫秒數，才能將其視為處於故障狀態。其他大多數內部時間限制是節點超時的倍數。
<code># cluster-node-timeout 15000/<code>
如果發生故障的主副本的數據看起來太舊，它將避免啟動故障轉移。
沒有一種簡單的方法可以使副本實際上具有對其“數據壽命”的精確度量，因此執行以下兩項檢查：
1）如果有多個副本可以進行故障轉移，它們會交換消息以嘗試利用複製偏移量最好的副本（從主副本中獲取更多數據）來獲得優勢，副本副本將嘗試按偏移量獲取其排名，並且向故障轉移的開始施加與它們的等級成比例的延遲。
2）每個單獨的副本都會計算與其母版之間最後一次交互的時間。這可以是最後一次收到的ping或命令（如果主服務器仍處於“已連接”狀態），也可以是自從與主服務器斷開連接以來經過的時間（如果複製鏈接當前已斷開）。如果最後一次交互也是舊版本，副本將完全不會嘗試故障轉移。
用戶可以調整點“ 2”。具體而言，如果自從上次與主服務器進行交互以來，經過的時間大於以下時間，則副本將不執行故障轉移：
（節點超時*複製有效性因子）+ repl-ping-replica-period
因此，例如，如果節點超時為30秒，並且副本有效性因子為10，並假設默認的repl-ping-replica-period值為10秒，則副本將無法嘗試進行故障轉移（如果無法進行對話）與主機的時間超過310秒。
較大的副本有效性因子可能會使數據太舊的副本無法對主副本進行故障轉移，而值太小可能會使群集根本無法選擇副本。
為了獲得最大可用性，可以將副本有效性因子設置為0，這意味著副本將始終嘗試對主副本進行故障轉移，而不考慮它們上次與主副本進行交互的時間。 （但是，他們將始終嘗試應用與其偏移等級成正比的延遲）。
零是唯一能夠保證當所有分區恢復正常後群集將始終能夠繼續運行的值。
<code># cluster-replica-validity-factor 10/<code>
群集副本能夠遷移到孤立的主數據庫，即那些沒有工作副本的主數據庫。 這樣可以提高群集抵禦故障的能力，因為如果沒有工作副本，孤立的主節點在發生故障的情況下將無法進行故障轉移。
僅當其舊主副本仍存在至少給定數量的其他工作副本時，副本副本才會遷移到孤立的主副本。 這個數字是“移民壁壘”。 遷移障礙為1意味著，僅當副本數據庫的主副本中至少有1個其他工作副本時，副本副本才會遷移。 它通常反映出集群中每個主數據庫所需的副本數。
缺省值為1（僅當其主副本保留至少一個副本副本時，副本副本才會遷移）。 要禁用遷移，只需將其設置為非常大的值即可。 可以將值設置為0，但僅用於調試和生產危險。
<code># cluster-migration-barrier 1/<code>
默認情況下，如果Redis Cluster節點檢測到至少發現了一個哈希槽（沒有可用的節點正在為其提供服務），它們將停止接受查詢。 這樣，如果集群部分關閉（例如，不再覆蓋哈希槽的範圍），則所有集群最終將變得不可用。 再次覆蓋所有插槽後，它將自動返回可用狀態。
但是，有時您希望正在工作的集群子集繼續接受對仍覆蓋的部分鍵空間的查詢。 為此，只需將cluster-require-full-coverage選項設置為no。
<code># cluster-require-full-coverage yes/<code>
設置為yes時，此選項可防止副本在主服務器發生故障時嘗試對其主服務器進行故障轉移。 但是，主服務器仍然可以執行手動故障轉移（如果被迫執行）。
這在不同的情況下很有用，尤其是在多個數據中心操作的情況下，在這種情況下，如果完全DC發生故障，我們不希望一側不被提升。
為了設置群集，請確保閱讀http://redis.io網站上的可用文檔。
