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网站上的可用文档。
