Hash在条目数量较小的时候会使用一种高效的内存数据结构编码,当超过某个临界点就会采用另一种存储方式,该临界点由下面的两个配置决定:
-
hash-max-ziplist-entries 512
-
hash-max-ziplist-value 64
与Hash类似,较小的List会以一种特殊的编码方式来节省空间,只要List不超过下面的上限:
-
list-max-ziplist-entries 512
-
list-max-ziplist-value 64
Set只有在满足下面的条件时才会采用特殊编码方式:Set中存储的恰好都是十进制的整数,而且长度不超过64位(有符号)。数量上限为:
-
set-max-intset-entries 512
同样,有序集合也会采用特殊编码来节省空间,只要不超过上限:
-
zset-max-ziplist-entries 128
-
zset-max-ziplist-value 64
RedisHyperLogLog 是用来做基数统计的算法,HyperLogLog 的优点是,在输入元素的数量或者体积非常非常大时,计算基数所需的空间总是固定并且很小的。当HyperLogLog用稀疏式表示法时所用内存超过下面的限制,就会转换成稠密式表示,为了更高的内存利用率,官方建议值为3000。
-
hll-sparse-max-bytes 3000
Redis 在每 100 毫秒时使用 1 毫秒的 CPU时间来对 Redis 的 hash 表进行重新 hash 。当使用场景中有非常严格的实时性需要,不能够接受 Redis 时不时的对请求有 2 毫秒的延迟的话,把这项配置为 no 。
如果没有这么严格的实时性要求,可以设置为 yes ,以便能够尽可能快的释放内存。
-
activerehashing yes
客户端的输出缓冲区的限制,因为某种原因客户端从服务器读取数据的速度不够快,可用于强制断开连接(一个常见的原因是一个发布 / 订阅客户端消费消息的速度无法赶上生产它们的速度)。
可以三种不同客户端的方式进行设置:
(1)normal -> 正常客户端
(2)slave -> slave 和 MONITOR 客户端
(3)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 客户端不做限制,因为他们在一个请求后未要求时(以推的方式)不接收数据,只有异步客户端可能会出现请求数据的速度比它可以读取的速度快的场景。
把硬限制和软限制都设置为 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会按照一定的频率来执行后台任务,比如关闭超时的客户端,清除过期键等。不是所有的任务都会按照相同的频率来执行,但Redis 依照指定的“ Hz ”值来执行检查任务。
-
hz 10
aof rewrite过程中,是否采取增量文件同步策略,默认为“yes”。 rewrite过程中,每32M数据进行一次文件同步,这样可以减少aof大文件写入对磁盘的操作次数。
-
aof-rewrite-incremental-fsync yes