# 与hash和list相似，有序荟萃也可以用一种出格的编码方法来节减大量空间。
# 这种编码只适合长度和元素都小于下面限制的有序荟萃：
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
# HyperLogLog sparse representation bytes limit. The limit includes the
# 16 bytes header. When an HyperLogLog using the sparse representation crosses
# this limit, it is converted into the dense representation.
#
# A value greater than 16000 is totally useless, since at that point the
# dense representation is more memory efficient.
#
# The suggested value is ~ 3000 in order to have the benefits of
# the space efficient encoding without slowing down too much PFADD,
# which is O(N) with the sparse encoding. The value can be raised to
# ~ 10000 when CPU is not a concern, but space is, and the data set is
# composed of many HyperLogLogs with cardinality in the 0 - 15000 range.
hll-sparse-max-bytes 3000
# 启用哈希刷新，每100个CPU毫秒会拿出1个毫秒来刷新Redis的主哈希表（顶级键值映射表）。
# redis所用的哈希表实现（见dict.c）回收延迟哈希刷新机制：你对一个哈希表操纵越多，哈希刷新
# 操纵就越频繁；反之，假如处事器是空闲的，那么哈希刷新就不会完成，哈希表就会占用更多的一些
# 内存罢了。
#
# 默认是每秒钟举办10次哈希表刷新，用来刷新字典，然后尽快释放内存。
#
# 发起：
# 假如你对延迟较量在意，不可以或许接管Redis时不时的对请求有2毫秒的延迟的话，就用
# "activerehashing no"，假如不太在意延迟而但愿尽快释放内存就配置"activerehashing yes"
activerehashing yes
# 客户端的输出缓冲区的限制，可用于强制断开那些因为某种原因从处事器读取数据的速度不足快的客户端，
# （一个常见的原因是一个宣布/订阅客户端消费动静的速度无法遇上出产它们的速度）
#
# 可以对三种差异的客户端配置差异的限制：
# normal -> 正常客户端
# slave -> slave和 MONITOR 客户端
# pubsub -> 至少订阅了一个pubsub channel或pattern的客户端
#
# 下面是每个client-output-buffer-limit语法:
# client-output-buffer-limit <class><hard limit> <soft limit> <soft seconds>
# 一旦到达硬限制客户端会当即被断开，可能到达软限制并一连到达指定的秒数（持续的）。
# 譬喻，假如硬限制为32兆字节和软限制为16兆字节/10秒，客户端将会当即断开
# 假如输出缓冲区的巨细到达32兆字节，或客户端到达16兆字节并持续高出了限制10秒，就将断开毗连。
#
# 默认normal客户端不做限制，因为他们在不主动请求时不吸收数据（以推的方法），只有异步客户端
# 大概会呈现请求数据的速度比它可以读取的速度快的场景。
#
# pubsub和slave客户端会有一个默认值，因为订阅者和slaves以推的方法来吸收数据
#
# 把硬限制和软限制都配置为0来禁用该成果
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
# Redis挪用内部函数来执行很多靠山任务，如封锁客户端超时的毗连，排除未被请求过的逾期Key等等。
#
# 不是所有的任务都以沟通的频率执行，但Redis依照指定的“hz”值来执行查抄任务。
#
# 默认环境下，“hz”的被设定为10。提高该值将在Redis空闲时利用更多的CPU时，但同时当有多个key
# 同时到期会使Redis的回响更敏捷，以及超时可以更准确地处理惩罚。
#
# 范畴是1到500之间，可是值高出100凡是不是一个好主意。
# 大大都用户应该利用10这个默认值，只有在很是低的延迟要求时有须要提高到100。
hz 10
# 当一个子历程重写AOF文件时，假如启用下面的选项，则文件每生成32M数据会被同步。为了增量式的
# 写入硬盘而且制止大的延迟岑岭这个指令长短常有用的
aof-rewrite-incremental-fsync yes
Linux公社的RSS地点：https://www.linuxidc.com/rssFeed.aspx