# 最大内存计策：假如到达内存限制了，Redis如何选择删除key。你可以在下面五个行为里选：
#
# volatile-lru -> 按照LRU算法生成的逾期时间来删除。
# allkeys-lru -> 按照LRU算法删除任何key。
# volatile-random -> 按照逾期配置来随机删除key。
# allkeys->random -> 无不同随机删。
# volatile-ttl -> 按照最近逾期时间来删除（辅以TTL）
# noeviction -> 谁也不删，直接在写操纵时返回错误。
#
# 留意：对所有计策来说，假如Redis找不到符合的可以删除的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然后取最旧的谁人，你可以通过下面的设置指令来配置样本的个数。
#
# maxmemory-samples 3
############################## APPEND ONLY MODE ###############################
# 默认环境下，Redis是异步的把数据导出到磁盘上。这种模式在许多应用里已经足够好，但Redis历程
# 出问题或断电时大概造成一段时间的写操纵丢失(这取决于设置的save指令)。
#
# AOF是一种提供了更靠得住的替代耐久化模式，譬喻利用默认的数据写入文件计策（拜见后头的设置）
# 在碰着像处事器断电或单写环境下Redis自身历程出问题但操纵系统仍正常运行等突发事件时，Redis
# 能只丢失1秒的写操纵。
#
# AOF和RDB耐久化能同时启动而且不会有问题。
# 假如AOF开启，那么在启动时Redis将加载AOF文件，它更能担保数据的靠得住性。
#
# 请查察 来获取更多信息.
appendonly no
# 纯累加文件名字（默认："appendonly.aof"）
appendfilename "appendonly.aof"
# fsync() 系统挪用汇报操纵系统把数据写到磁盘上，而不是等更多的数据进入输出缓冲区。
# 有些操纵系统会真的把数据顿时刷到磁盘上；有些则会尽快去实验这么做。
#
# Redis支持三种差异的模式：
#
# no：不要立即刷，只有在操纵系统需要刷的时候再刷。较量快。
# always：每次写操纵都立即写入到aof文件。慢，可是最安详。
# everysec：每秒写一次。折中方案。
#
# 默认的 "everysec" 凡是来说能在速度和数据安详性之间取得较量好的均衡。按照你的领略来
# 抉择，假如你能放宽该设置为"no" 来获取更好的机能(但假如你能忍受一些数据丢失，可以思量利用
# 默认的快照耐久化模式)，可能相反，用“always”会较量慢但比everysec要更安详。
#
# 请查察下面的文章来获取更多的细节
#
#
# 假如不能确定，就用 "everysec"
# appendfsync always
appendfsync everysec
# appendfsync no
# 假如AOF的同步计策配置成 "always" 可能 "everysec"，而且靠山的存储历程（靠山存储或写入AOF
# 日志）会发生许多磁盘I/O开销。某些Linux的设置下会使Redis因为 fsync()系统挪用而阻塞好久。
# 留意，今朝对这个环境还没有完美批改，甚至差异线程的 fsync() 会阻塞我们同步的write(2)挪用。
#
# 为了缓解这个问题，可以用下面这个选项。它可以在 BGSAVE 或 BGREWRITEAOF 处理惩罚时阻止fsync()。
#
# 这就意味着假如有子历程在举办生存操纵，那么Redis就处于"不行同步"的状态。
# 这实际上是说，在最差的环境下大概会丢掉30秒钟的日志数据。（默认Linux设定）
#
# 假如把这个配置成"yes"带来了延迟问题，就保持"no"，这是生存耐久数据的最安详的方法。
no-appendfsync-on-rewrite no
# 自动重写AOF文件
# 假如AOF日志文件增大到指定百分比，Redis可以或许通过 BGREWRITEAOF 自动重写AOF日志文件。
#
# 事情道理：Redis记着上次重写时AOF文件的巨细（假如重启后还没有写操纵，就直接用启动时的AOF巨细）
#
# 这个基准巨细和当前巨细做较量。假如当前巨细高出指定比例，就会触发重写操纵。你还需要指定被重写
# 日志的最小尺寸，这样制止了到达指定百分比但尺寸仍然很小的环境还要重写。
#
# 指定百分比为0会禁用AOF自动重写特性。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
################################ LUA SCRIPTING ###############################