# 注：我们通常会将KEYS（客户端使用KEY *进行查询会卡死Redis进程）、SHUTDOWN（关闭实例）、FLUSHALL（清除所有数据及文件信息，类似初始化）、FLUSHDB（清除当前数据库中所有数据）
####################### LIMITS ########################
# 设置同一时间的客户端最大连接数，默认限制是10000个客户端。
# 然而如果redis服务不设置这个限制值那么最大的用户数就是最大文件描述符数-32.
# 一旦连接的用户数超出了限制值，redis将会关闭新的连接并且发送
# 'max number of client reached'
# maxclients 10000
# 不使用超出指定大小的内存，
# 当redis使用到的内存达到限定值的时候，将会根据淘汰策略移除一部分key
# 如果根据相关策略无法移除key，或者策略被设置为 'noeviction'，redis将会对
# 使用到内存的命令返回错误，比如 SET LPUSH等，并且进入只读模式，仅仅响应只读的命令，如GET。
# 这个选项在你将redis当做一个LRU缓存和设置一个内存大小限制的时候十分有用。
# 注：如果你的Slave关联到一个开启最大内存限制的redis实例上，
# Master向Slave输出缓冲区属于被该服务器使用的内存的一部分。
# 因此网络问题和重新同步引发的复制，不会触发淘汰key的循环，
# 反过来，Slave的输出缓冲区将触发淘汰 key的DELs操作，直到数据库清空
# 简单来说，如果你拥有一个Slave，我们建议你将这个值
# 设置为少于系统可用的最大内存，以便系统可以腾出空间来安放Slave的输出缓存（但是如果策略是noeviction 那就没这个必要）
#
# maxmemory <bytes>
# 最大内存（MAXMEMORY）策略: 当redis使用的内存达到指定的最大值时，你可以使用如下的5种策略来应对：
#
# volatile-lru -> 使用LRU算法依据过期时间来移除key
# allkeys-lru -> 使用LRU算法来移除任何key
# volatile-random -> 根据过期时间设置随机移除key
# allkeys-random -> 随机移除任何一个key
# volatile-ttl -> 移除一个最近过期时间的key
# noeviction -> 所有key不过期(即不移除任何key)，对于任何写操作都返回一个错误信息
# 注: 在以上所有策略中，当不存在一个key满足以上的淘汰策略时(即无法空出内存时)，
# 任何写操作都会返回错误信息
#
# 目前为止具有写入操作的指令是: set setnx setex append
# incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
# sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
# zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
# getset mset msetnx exec sort
#
# 默认值为:
#
# maxmemory-policy volatile-lru
# LRU和最小TTL算法都不是精确的算法，只是近似的算法，
# 因此你可以选择一些样本大小来进行测试，对于一个默认的redis实例
# 将会选选择3个key，并且挑选其中之一作为最近最少的Key，你可以使用如下参数修改示例的数量大小
# maxmemory-samples 3
################# APPEND ONLY MODE ##################
# Redis默认使用异步存储数据到硬盘上.
#
# 这个模式非常合适一些应用，但是当redis的进程出现问题
# 或者停电的时候，会丢失一些写入的数据(丢失的多少根据保存点的设置)
#
# Append Only 文件(Append Only file)，是一个备选的持久化模型，
# 它提供了更好的续航能力，对于一个使用默认数据同步文件策略的实例，
# redis可能会因为一个戏剧性的灾难比如停电等丢失一秒钟的数据。
#
# 或者由于redis进程本身的错误仅仅写入一个数据，但操作系统一直运行。
#
# AOF和RDB可以毫无问题地共存，因此你可以同时开启他们，
#
# 但如果你开启了AOF，redis会在启动时加载AOF（默认是加载RDB），因为AOF有更好的鲁棒性。
# 可以从 获取更多的信息
appendonly no
# append file 的名称 (默认是: "appendonly.aof")
appendfilename "appendonly.aof"
# fsync() 函数调用告诉操作系统立即将数据写入到硬盘中，而不是写入到输出缓冲区
# 等待足够的数据再写入。一些操作系统会立即将数据写入到硬盘中，一些其他的
# 操作系统则只是尽可能快地将数据写入硬盘中。
# Redis支持三种不同写AOF文件的模式:
# no：不进行强制同步，仅仅让操作系统根据自身的决策写入到硬盘中。这种速度更快。
# always：在每一次追加写入操作都采用强制同步，特点是慢，安全。
# everysec：每间隔一秒钟强制同步数据。折中的方案。
#
# 默认采用"everysec"作为速度和安全性之间的平衡方案。
# 可以根据自己的需求决定采用更快的方案或者更安全的方案。
# 选择no，何时写入数据将由操作系统决定，你可以由此获取最快的速度。
# 选择always，数据将立即写入到硬盘中，你可以获得更高的数据安全性。
#
# 更多的信息可以从以下地址中获取:
#
#
# 如果不开启该选项默认使用"everysec".
# appendfsync always
appendfsync everysec
# appendfsync no
# 当AOF的强制写入策略设置为always 或者 everysec，并且一个后台保存进程
#（一个后台保存进程或者 AOF 日志后台重写）会占用硬盘的大量I/O资源，在一些linux
# 的配置中redis会因为 fsync() 调用而长期锁定。目前我们没法解决这个问题。
# 即使采用另外的线程来运行强制同步，也会锁定住我们的同步write(2)调用。
#
# 为了减轻这个问题，下面的选项将会在BGSAVE 或者BGREWRITEAOF运行时
# 预防主进程调用fsync()。
#
# 这意味着当另一个子进程在保存的时候，Redis的保存策略将处于"appendfsync none"这样的类似状态。
# 在实际应用中，这意味着在最坏的情况下将会失去30秒的日志(使用linux默认的设置)。
#
# 如果你采用yes，那么将会存在一个潜在的隐患，不然请设置它为 "no"，
# 这是一个为了稳定的安全性选择。
no-appendfsync-on-rewrite no
# 自动改写append only 文件.
#
# redis会在AOF日志文件增长到指定百分比的时候通过调用BGREWRITEAOF来自动重写日志文件。
#
# 它是这样工作的：redis会记住最后一次改写后AOF文件的大小(如果重写自重启以来
# 尚未发生，那么AOF文件的大小就是启动以来使用的大小)。
# 这个基准值将会和当前值进行比较，如果当前值比设定的百分比还要大，重写事件就会发生。
# 并且你需要指定一个AOF重写的最小值，用来避免当重写文件的百分比增长符合目标
# 但是整个文件依然很小的场景。
#
# 将 auto-aof-rewrite-percentage 设置为0则可以关闭掉AOF自动重写的功能
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# Redis在启动时会将AOF文件中的数据载入到内存中，载入时可能会出现载入的AOF 文件的最后被truncate的场景。