3.redis配置

redis配置

Tags: redis

目录

redis内存设置单位

redis内存设置单位

  • 1k => 1000 bytes
  • 1kb => 1024 bytes
  • 1m => 1000000 bytes
  • 1mb => 1024*1024 bytes
  • 1g => 1000000000 bytes
  • 1gb => 102410241024 bytes

例:4k,6m,2GB等不去分大小写

include——引入配置文件

  引入外部配置文件,如果你有多个redis服务器,你可以将相同的配置写在一个共用的配置文件中,并通过下面这种方式应用。include引入的文件不会被管理员或Redis Sentinel执行“CONFIG REWRITE”命令重写。
  如果有出现相同的配置选项,redis总是使用最后一次配置替换之前的。
  如果include进来的文件是共享配置,那么最好放在开头的位置;反之,就要放在文件的末尾。
include /path/to/share.conf
include /path/to/local.conf

modules——模块

loadmodule——引入模块

  这个配置可在redis启动的时候加载指定的模块,如果模块加载失败redis将不能启动。  
  可以加载多个模块。
loadmodule /usr/lib/xx.so
loadmodule /usr/lib/yy.so

network——网络设置

bind——绑定IP

  如果没有使用`bind`设置,redis将绑定服务器上的所有可用的网络接口。  
  如果指定了一个或多个ip,那么ip对应的网络接口将会被绑定。  
  默认情况下,bind绑定的是127.0.0.1的地址,也就意味着只有本机才可以访问
#bind ip1 ip2 ip3 ...
bind 127.0.0.1

protected-mode——保护模式

  protected mode是一层安全保护,避免redis实例在互联网上被使用和访问。  
  在保护模式在打开的情况下:
 1. 服务器没有明确到绑定到一组使用地址
 2. 没有设置redis密码。
  满足以上条件的情况下redis直接收来自127.0.0.1和::1的客户端发起的连接  
  默认情况下是启用保护状态,如果准备被其它机器访问,需要设置为禁用保护状态
protected-mode yes

port——绑定端口

  redis一个实例只允许绑定到一个端口,如果想使用多个端口绑定到一个实例,可以使用nginx类似的工具进行端口转发。
  如果端口这是为0,redis将不能在tcp socket上进行监听
port 6379

tcp-backlog——tcp每秒连接数

  设置listen队列的长度。
  同时需要修改系统`somaxconn`和`tcp_max_syn_backlog`的值进行网络调优,以确保redis达到预期的性能。*默认情况下这两个值小于redis中设置的值*
tcp-backlog 511

Unix socket

  指定用于监听Unix套接字的路径
  默认情况下redis不使用Unix socket

Unix socket与Tcp socket的区别:

  1. 在访问量不大的情况下Unix socket比Tcp socket效率高点,因为前者不走tcp,所以避免了tcp的封包、解包的过程,因此会快一些。
  2. Unix socket使用长连接,所以有效提高了端口的复用率(貌似不需要端口),Tcp socket会使用大量的临时端口。在访问量较大时采用tcp与短链接会更稳定。
  3. Unix socket要求客户端和服务端能同时访问指定的文件,所以一般用于本地服务间的通信。
#配置sock文件路径:/dev/shm/redis.sock 
#/dev/shm是内存文件系统,所以会比放在/tmp下快点
unixsocket /tmp/redis.sock
#配置文件权限
unixsocketperm 700

timeout——连接超时时间

  设置客户端连接redis空闲多久后自动断开连接
  设置为0时,理论上连接不会自动断开,除非有防火墙或者其它工具导致连接断开,那么连接redis的客户端数量少的情况下,保持长连接岂不是效率更高,减少端口的使用,减少tcp的握手
timeout 0

tcp-keepalive——心跳检测时间

  如果设置为非0,这在客户端与服务器间超过指定的时间没有通信时,由服务器主动发起向客户端的询问。
  上述询问的作用:
 1. 检测客户端的连接状态
 2. 从中间的网络设备观察客户端连接是否有效
  Redis从3.2.1版本起默认为300
tcp-keepalive 300

general——常规设置

daemonize——守护进程模式

  默认情况下redis不是作为守护进程运行的,如果想后台运行,应改为yes
  在守护进程运行时,会生成将进程id写入一个pid文件中
daemonize no 

supervised——守护进程的管理模式

  如果你使用upstart或systemd运行redis,redis能与supervision tree交互。
  可选值:
 1. supervised no        - no supervision interaction
 2. supervised upstart   - signal upstart by putting Redis into SIGSTOP mode
 3. supervised systemd   - signal systemd by writing READY=1 to $NOTIFY_SOCKET
 4. supervised auto      - detect upstart or systemd method based on UPSTART_JOB or NOTIFY_SOCKET environment variables
  注意:这些管理方法是仅信号模式“进程是就绪的”。不能连续的发送信号给管理者(不理解)

pdifile——设置PID文件路径

  在守护进程运行时,会生成将进程id写入指定的pid文件中
pidfile /var/run/redis.pid

log——Redis日志

loglevel———日志级别

  设置服务记录日志的级别:
  1. debug        大量信息,用于开发/测试
  2. verbose      详细信息,但不像调试级别混乱
  3. notice       适度的冗长,可用在生产环境
  4. warning      仅记录非常重要/关键的日志
loglevel notice

logfile——设置日志文件

  1. 设置为文件名,输出到指定的文件
  2. 设置为`""`字符,输出到控制台
  3. 设置为/dev/null,丢弃所有输出
logfile ""

syslog——系统日志

syslog-enabled——系统日志开关

  日志记录到系统日志的开关,配置其它syslog参数一起使用
syslog-enabled no

syslog-ident——指定程序身份

  指定日志属于那个程序的日志
syslog-ident redis

syslog-facility——日志级别

  设置级别可选值为local0——local7。
syslog-facility local0

databases——多数据库

  databases设置数据库的数量,下标从0开始。
  应用场景:假设我们有多个客户端程序且彼此之间没有任何联系,但是同时连接一个数据库实例,那么问题来了,如果多个客户端程序中存在相同的key怎么解决,没错,这个设置就完美的解决了这个问题,是用`select 0`选择属于自己的空间,然后进行读写操作。
  设置databases避免了在一台服务器上开启多个redis实例来满足多个独立客户端的需求。
databases 16

always-show-logo——redis logo图标

  设置是否显示redis logo图标,在4.0之前要么在控制台,要么在日志中始终会显示这个图标,但从4.0开始我们可以选择是否显示这个图标。

这设置完全是个玩具,没有蛋用。

always-show-logo yes

snapshotting——快照,备份

save——生成快照,备份

  配置redis在何时生成快照,sava有两个参数:
  1. 第一个参数为时间,单位为秒
  2. 第二个参数为keys的变更数,单位为个
  例如:save 300 20,如果300秒有20个key发生了变更则生成快照
  禁用自动生成快照,只要注释调所有的save就行了,或者把save设置为`""`同样能达到禁止生成快照的效果
save 900 1
save 300 10
save 60 10000

stop-writes-on-bgsave-error——生成快照失败是否停止写

  默认情下如果在启用了save且生成快照时发生错误,redis将停止写操作。
stop-writes-on-bgsave-error yes

rdbcompression——压缩数据库

  是否启用压缩数据库来节省空间
rdbcompression yes

rdbchecksum——完整性校验

  是否对数据进行完整性校验。
rdbchecksum yes

dbfilename——数据库文件名

dbfilename dump.rdb

dir——数据库文件目录

  设置数据库文件的存储目录
dir ./

replication——主从/同步

slaveof——设置从机

slaveof ip port

masterauth——主机密码

masterauth password

slave-serve-stale-data——失去主从同步后是否继续服务

  如果与主机失去联系是否还继续对外提供服务
slave-serve-stale-data yes

slave-read-only——从机是否只读

slave-read-only yes

relp-diskless-sync——无盘同步

redis有盘同步:

redis同步时通常先将同步的数据生成到物理磁盘上的rdb文件中,然后在读取rdb文件发送到其它同步机。

redis无盘同步:

省略向磁盘生成rdb的过程

repl-diskless-sync no

repl-diskless-sync-delay——无盘同步延迟时间

repl-diskless-sync-delay 5

repl-ping-slave-period——主从心跳

repl-ping-slave-period 10

repl-timout——同步超时时间

repl-timeout 60

repl-disable-tcp-nodelay——同步延迟

  启用后,redis将在指定时间内合并小的tcp包来减少请求次数从而减少带宽,同样,这也造成此段时间内主从数据的不一致。
repl-disable-tcp-nodelay no

repl-backlog-size——同步缓冲区大小

  主从失去连接时,此缓冲区越大,失去连接的时间就可以越长。
repl-backlog-size 1mb

repl-backlog-ttl——缓冲区数据保留时长

  主机和从机出现短暂的断开,此段时间产生的需要同步缓存数据可保留多长时间,在这个时间内如果主从还是不能连接,则清理同步缓冲区中这些要同步的缓存数据
  设置为0,则永不清理
repl-backlog-ttl 3600

slave-priority——从机的优先级

  当有多个从机时来指定从机变成主机的优先级,如果设置为0,永不可做主机
slave-priority 100

主机最小的可写从机

min-slaves-to-write , min-slaves-max-lag

  设置当一个master端的可用slave少于N个,延迟时间大于M秒时,不接收写操作
  `=0`禁用,`>0`且两个值必须同时`>0`才算启用
min-slaves-to-write 3
min-slaves-max-lag 10

slave-announce-ip,slave-announce-port

slave-announce-ip 5.5.5.5
slave-announce-port 1234

security——安全

requirepass——客户端连接密码

  由于redis太快,外部用户每秒可以尝试150K次密码,因此你需要一个很难破解的密码
requirepass foobared

rename-command——密令别名

  它用来改变共享环境中危险命令的名字,在这个例子中 CONFIG 命令被重命名为一个难以猜解的名字。
  这会对内部用户的工具有效,但是对一般的客户端无效。
  请注意,改变记录在AOF文件中的命令名称或者传输到从服务会导致问题
# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
# rename-command CONFIG "" //禁用这个命令

limits——限制

maxclients——最大连接数

  限制同时连接的客户数量。当连接数超过这个值时,redis 将不再接收其他连接请求,客户端尝试连接时将收到 error 信息
maxclients 10000

maxmemory——最大内存

  设置redis能够使用的最大内存。当内存满了的时候,如果还接收到set命令,redis将先尝试剔除设置过expire信息的key,而不管该key的过期时间还没有到达。在删除时,将按照过期时间进行删除,最早将要被过期的key将最先被删除。如果带有expire信息的key都删光了,那么将返回错误。这样,redis将不再接收写请求,只接收get请求。maxmemory的设置比较适合于把redis当作于类似memcached 的缓存来使用
maxmemory <bytes>

maxmemory-policy——内存策略

  当达到最大内存时redis将怎样移除,以下可选测移除策略:
  • volatile-lru:在使用了过期设置的集合中,尝试删除一个最近没在用的键。
  • volatile-tt:在使用了过期设置的集合中,尝试删除一个有较短expire时间的键。
  • volatile-random:在使用了过期设置的集合中随机删除一个键。
  • allkeys-lru:跟volatile-lru类似,但它会将每一种类型键都移除,不管是有效还是过期的只要设置了过期时间。
  • allkeys-random:跟volatile-random类似,但它会将每一种类型键都移除,不管是有效还是过期的只要设置了过期时间。
  • noeviction -> 根本就没过期,就返回一个错误写操作
maxmemory-policy noeviction

maxmemory-samples

  LRU和minimal TTL算法不是最精确的,但是最接近的算法(为了节省内存),这样你能调节精确度。
  默认检查5个key选择1个最少用的,默认5个已经是很精确的了,10个则更加精确但是耗费cpu,3个是非常快,但是不精确
maxmemory-samples 5

append only mode——AOF模式

appendonly——AOF模式开关

  默认redis使用RDB模式,这种模式数据首先存储在内存中,如果突然断电等情况会丢失一个写入磁盘周期的数据。
  AOF模式是将每次命令追加到文件的末尾,但是可以设置每执行一条命令就向aof文件中写入这条命令。
  AOF看起来效率低于RDB,但却能最大的保证数据的完整行,实际使用中可以选择两种模式共存。
appendonly no

appendfilename——AOF文件名称

appendfilename "appendonly.aof"

appendfsync——命令写入磁盘策略

fsync() 调用告诉操作系统立即将数据写入到硬盘中,而不是写入到输出缓冲区等待足够的数据再写入。一些操作系统会立即将数据写入到硬盘中,一些其他的操作系统则只是尽可能快地将数据写入硬盘中

Redis支持三种不同的模式:

  • no:不进行强制同步,仅仅让操作系统根据自身的决策写入到硬盘中。这种速度更快
  • always:在每一次追加写入操作都采用强制同步,特点是慢,安全。
  • everysec:每间隔一秒钟强制同步数据。折中的方案

默认采用 "everysec"作为速度和安全性之间的平衡方案
你将根据自己的需求决定采用更快的方案或者更安全的方案。
选择no,何时写入数据将由操作系统决定,你可以由此获取最快的速度
选择always,数据将立即写入到硬盘中,你可以获得更高的数据安全性
更多的信息可以从以下地址中获取:
http://antirez.com/post/redis-persistence-demystified.html
如果不开启该选项默认使用"everysec".

appendfsync everysec

no-appendfsync-on-rewrites

当AOF的强制写入策略设置为 always 或者 everysec,并且一个后台保存进程会占用硬盘的大量I/O资源,在一些linux的配置中redis会因为 fsync() 调用而长期锁定。特别的是在目前我们没法解决这个问题
即使采用另外的线程来运行强制同步也会锁定住我们的 同步 write(2)调用。
为了减轻这个问题,下面的选项将会在GBSAVE 或者BGREWRITEAOF运行时预防主进程调用fsync(),这意味着当另一个子进程在保存的时候,Redis的保存策略将处于"appendfsync none"这样的类似状态,在实际应用当中,这意味着在最坏的情况下将会失去30秒的日志(使用linux默认的设置)

如果你采用yes,那么将会存在一个潜在的隐患,不然请设置它为 "no",

这是一个为了稳定的安全性选择

no-appendfsync-on-rewrite no

自动重写AOF的条件

auto-aof-rewrite-percentage

auto-aof-rewrite-min-size

自动改写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

aof-load-truncated——加载被截断的AOF文件

redis在启动的时候可以加载被截断的AOF文件,默认启用;

aof-load-truncated yes

LUA脚本

以毫秒为单位限定lua脚本的最大执行时间.
当lua脚本在超出最大允许执行时间之后,redis会记录下这个脚本到日志中,并且会向这个请求返回error的错误
仅当 SCRIPT KILL 和 SHUTDOWN NOSAVE 命令可用的时候
一个运行时间超过最大限定时间的脚本才会继续执行
SCRIPT KILL用来停止一个没有调用写入命令的脚本
当用户不想等待脚本的自然中止但脚本又在进行写操作的时候
采用 SHUTDOWN NOSAVE 是解决这个问题的唯一办法,他可以立即停掉整个脚本

设置为0 或者一个负数来取消时间限定.

lua-time-limit 5000

Redis集群

cluster-enabled——集群开关

cluster-enabled yes

cluster-config-file——集群配置文件

cluster-config-file nodes-6379.conf

cluster-node-timeout——节点超时时间

  节点会定期给其他所有的节点发送Ping,在指定时间内没有收到对方的回复,则单方面认为对端节点宕机,将该节点标为PFAIL状态。
  单位毫秒
cluster-node-timeout 15000

cluster-slave-validity-factor

控制从节点FailOver相关的设置
设为0,从节点会一直尝试启动FailOver.
设为正数,失联大于一定时间(factor*节点TimeOut),不再进行FailOver

cluster-slave-validity-factor 10

cluster-migration-barrier

最小从节点连接数

cluster-migration-barrier 1

cluster-require-full-coverage

默认为Yes,丢失一定比例Key后(可能Node无法连接或者挂掉),集群停止接受写操作
设置为No,集群丢失Key的情况下仍提供查询服务

cluster-require-full-coverage yes

redis慢日志

Redis 提供了SLOWLOG指令来获取最近的慢日志,Redis 的慢日志是直接存在内存中的,所以它的慢日志开销并不大,在实际应用中,我们通过 crontab 任务执行 SLOWLOG 命令来获取慢日志,然后将慢日志存到文件中,并用Kibana生成实时的性能图表来实现性能监控。

值得一提的是,Redis 的慢日志记录的时间,仅仅包括 Redis 自身对一条命令的执行时间,不包括 IO 的时间,比如接收客户端数据和发送客户端数据这些时间。另外,Redis 的慢日志和其它数据库的慢日志有一点不同,其它数据库偶尔出现 100ms 的慢日志可能都比较正常,因为一般数据库都是多线程并发执行,某个线程执行某个命令的性能可能并不能代表整体性能,但是对 Redis 来说,它是单线程的,一旦出现慢日志,可能就需要马上得到重视,最好去查一下具体是什么原因了。

slowlog-log-slower-than

slow log(慢日志)用来记录执行时间超过指定值的查询。
执行时间不包含 I/O操作,比如和客户端交互,发送应答等等
仅仅是执行命令的真实时间,(仅仅是线程因为执行这个命令而锁定且无法处理其他请求的阶段)
你可以使用两个参数来配置 slow log,一个是以微秒为单位的命令执行时间值,
另一个是slow log 的长度(即记录的最大数量)
当一个新的命令被记录到slow log的时候,最旧的一条记录将会被移除。
下面的值将会被解释为 微秒 为单位,所以 1000000 微秒为 1秒
将这个值设置为一个负数,将关闭掉slow log ,如果设置为0,则记录所有的命令
(默认是10毫秒)

slowlog-log-slower-than 10000

slowlog-max-len

因为这会消耗内存,因此实际上并不是限制到这个长度.
你可以使用 SLOWLOG RESET来回收占用的内存

slowlog-max-len 128

redis 延迟监控

latency-monitor-threshold

redis延迟监控子系统例子与操作系统收集的redis实例相关的数据不同
通过LATENCY命令,可以为用户打印出相关信息的图形和报告
这个系统只会记录运行时间超出指定时间值的命令,如果设置为0,这个监控将会被关闭
默认的情况下,延迟监控是关闭,因为如果你没有延迟的问题大部分情况下不需要,并且收集数据的行为会对性能造成影响,虽然这个影响很小可以在大负荷下工作
延迟监控可以使用如下命令来打开

latency-monitor-threshold 0

redis事件通知

notify-keyspace-events

redis 可以在key 空间中采用发布订阅模式来通知事件的发生
这个功能的文档可以查看 http://redis.io/topics/keyspace-events
对于一个实例,如果键空间事件通知是启用状态,当一个客户端执行在一个
存储在Database 0名为"foo"的key的DEL(删除)操作时,
有如下两条信息将会通过发布订阅系统产生
PUBLISH keyspace@0:foo del
PUBLISH keyevent@0:del foo

K Keyspace events, published with keyspace@ prefix.
E Keyevent events, published with keyevent@ prefix.
g Generic commands(non-type specific) like DEL, EXPIRE, RENAME
$ String commands
l List commands
s Set commands
h Hash commands
z Sorted set commands
x Expired events (events generated every time a key expires)
e Evicted events (events generated when a key is evicted for maxmemory)
A Alias for g$lshzxe, so that the "AKE" string means all the events.

例子1: 启用 list 和 generic 事件,

notify-keyspace-events Elg

例子2 2: 要想订阅通道名为__keyevent@0__:expired 上expired keys的事件:

notify-keyspace-events Ex

默认不启用所有的通知,因为大部分的用户不需要这些功能,而且这些功能会带来一些开销
如果你没有指定 K 或者 E,没有事件会被传递

notify-keyspace-events ""

redis高级配置

hash-max-ziplist-entries,hash-max-ziplist-value

创建空白哈希表时,程序默认使用 REDIS_ENCODING_ZIPLIST 编码,当以下任何一个条件被满
足时,程序将编码从切换为 REDIS_ENCODING_HT
哈希表中某个键或某个值的长度大于 server.hash_max_ziplist_value (默认值为 64)。
压缩列表中的节点数量大于 server.hash_max_ziplist_entries (默认值为 512 )。
ziplist是一个解决空间的紧凑的数据存储结构,但是当数据超过阈值时,将采用原生的数据存储结构

hash-max-ziplist-entries 512
hash-max-ziplist-value 64

list-max-ziplist-size

list-max-ziplist-size -2

list-compress-depth

list-compress-depth 0

list-max-ziplist-entries,list-max-ziplist-value

与hash表类似

list-max-ziplist-entries 512
list-max-ziplist-value 64

set-max-intset-entries

设置特殊编码的唯一情况:
当一个set仅仅由一个基数为10最大位数为64位的有符号整形的字符串构成的时候以下配置设置了set的限制大小,当小于这个值的时候将会使用一个更紧凑的数据结构来保存
以期减少内存占用

set-max-intset-entries 512

zset-max-ziplist-entries,zset-max-ziplist-value

与hash和list类似 zsort也采用如下的配置来选择是否进行特殊编码来节省空间

zset-max-ziplist-entries 128
zset-max-ziplist-value 64

hll-sparse-max-bytes

HyperLogLog 稀疏表示字节限制
这个限制包含了16个字节的头部,当一个HyperLogLog使用sparse representation
超过了这个显示,它就会转换到dense representation上

hll-sparse-max-bytes 3000

activerehashing

active rehashing使用CPU时间的每100毫秒中的1毫秒来进行rehashing工作

来rehash redis的主hash表(rehash的时候在代码种引入记时来保证)
lazy rehashing :逐步hash,每一次添加查找删除进行一次rehash的步骤
又称惰性hash
因为hash的再散列会导致整个进程的stop,为了避免长时间的stop,以上的策略都是在分散整个
rehash的过程(参照《redis设计与实现》的字典部分)

activerehashing yes

client-output-buffer-limit

客户端输出缓冲区显示可以用来解决由于某些原因导致的强制断线
而造成的不能读到足够的数据
一个比较常见的原因是发布订阅模式种,客户端不能足够快速地消费发布者生产的信息
这个限制可以设置为如下的三种类型:

normal -> 正常普通的客户端,包含监控客户端
slave -> 主从服务器的从客户端
pubsub -> 订阅了最少一个频道的客户端

每一个 client-output-buffer-limit 格式如下:
client-output-buffer-limit

在两种情况下服务器认为客户端不是意外临时掉线

1.缓冲区的数据达到硬限制

2.缓冲区的数据达到软限制,同时时间超过了指定值

因为一个客户离线,有可能是临时性的网络故障,或者传输问题
也有可能是永久性离线 或者强制性离线,此时服务器将不会保留他的缓存数据

以下的设置就是为了判断这一情况的
硬限制和软限制都可以通过将其设置为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

aof-rewrite-incremental-fsync

redis会按照一定的频率来处理诸如 关闭超时连接,清理没有被使用的过期key等等此类后台任务
并不是所有的任务都以相同的频率来执行的,redis通过一个hz的值来决定处理这些(如上所述的后台任务)任务的频率
提高这个值会使用更多的cpu时间来在redis闲置的时候处理以上的,但是以此同时
超时的连接的处理和过期key的清理则会更精确
hz的取值范围在1到500,不建议设置为超过100的值,默认是10
hz 10
当子进程重写AOF文件的时候,以下选项将会允许等到存在32MB数据的时候才调用强制同步
这样可以降低IO上的延迟

aof-rewrite-incremental-fsync yes

redis虚拟内存

vm-enabled

在配置文件中添加以下配置项,以使当前Redis服务器在启动时打开虚存功能。
vm-enabled yes

vm-max-memory

在配置文件中设定Redis最大可用的虚存字节数。如果内存中的数据大于该值,则有部分对象被换出到磁盘中,其中被换出对象所占用内存将被释放,直到已用内存小于该值时才停止换出。
vm-max-memory (bytes)
Redis的交换规则是尽量考虑"最老"的数据,即最长时间没有使用的数据将被换出。如果两个对象的age相同,那么Value较大的数据将先被换出。需要注意的是,Redis不会将Keys交换到磁盘,因此如果仅仅keys的数据就已经填满了整个虚存,那么这种数据模型将不适合使用虚存机制,或者是将该值设置的更大,以容纳整个Keys的数据。在实际的应用,如果考虑使用Redis虚拟内存,我们应尽可能的分配更多的内存交给Redis使用,以避免频繁的换入换出。

vm-pages, vm-page-size

在配置文件中设定页的数量及每一页所占用的字节数。为了将内存中的数据传送到磁盘上,我们需要使用交换文件。这些文件与数据持久性无关,Redis会在退出前会将它们全部删除。由于对交换文件的访问方式大多为随机访问,因此建议将交换文件存储在固态磁盘上,这样可以大大提高系统的运行效率。
vm-pages 134217728
vm-page-size 32
在上面的配置中,Redis将交换文件划分为vm-pages个页,其中每个页所占用的字节为vm-page-size,那么Redis最终可用的交换文件大小为:vm-pages * vm-page-size。由于一个value可以存放在一个或多个页上,但是一个页不能持有多个value,鉴于此,我们在设置vm-page-size时需要充分考虑Redis的该特征。

vm-max-threads

在Redis的配置文件中有一个非常重要的配置参数,即:
vm-max-threads 4
该参数表示Redis在对交换文件执行IO操作时所应用的最大线程数量。通常而言,我们推荐该值等于主机的CPU cores。如果将该值设置为0,那么Redis在与交换文件进行IO交互时,将以同步的方式执行此操作。
对于Redis而言,如果操作交换文件是以同步的方式进行,那么当某一客户端正在访问交换文件中的数据时,其它客户端如果再试图访问交换文件中的数据,该客户端的请求就将被挂起,直到之前的操作结束为止。特别是在相对较慢或较忙的磁盘上读取较大的数据值时,这种阻塞所带来的影响就更为突兀了。然而同步操作也并非一无是处,事实上,从全局执行效率视角来看,同步方式要好于异步方式,毕竟同步方式节省了线程切换、线程间同步,以及线程拉起等操作产生的额外开销。特别是当大部分频繁使用的数据都可以直接从主内存中读取时,同步方式的表现将更为优异。
如果你的现实应用恰恰相反,即有大量的换入换出操作,同时你的系统又有很多的cores,有鉴于此,你又不希望客户端在访问交换文件之前不得不阻塞一小段时间,如果确实是这样,我想异步方式可能更适合于你的系统。

posted @ 2017-03-20 09:06  Net_win  阅读(1240)  评论(0编辑  收藏  举报