Redis第十二篇【服务器管理、内存优化、管线】

ZhongFuCheng3y
508 阅读11分钟

tags: Redis title: Redis第十二篇【服务器管理、内存优化、管线】

服务器管理

  • Redis在设计之初就被定义为长时间不间断运行的服务进程，因此大多数系统配置参数都可以在不重新启动进程的情况下立即生效。即便是将当前的持久化模式从AOF切换到RDB也无需重启。
  • 在Redis中，提供了一组和服务器管理相关的命令，其中就包含和参数设置有关的CONFIG SET/GET command。

相关命令


CONFIG GET parameter 	 	主要用于读取服务器的运行时参数，但是并不是所有的配置参数都可以通过该命令进行读取。其中该命令的参数接受glob风格的模式匹配规则，因此如果参数中包含模式元字符，那么所有匹配的参数都将以key/value方式被列出。如果参数是*，那么该命令支持的所有参数都将被列出。最后需要指出的是，和redis.conf中不同的是，在命令中不能使用数量缩写格式，如GB、KB等，只能使用表示字节数量的整数值。	 
CONFIG SET parameter value 	 	该命令用于重新配置Redis服务器的运行时参数，在设置成功之后无需重启便可生效。然而并非所有的参数都可以通过该命令进行动态设置，如果需要获悉该命令支持哪些参数，可以查看CONFIG GET * 命令的执行结果。如果想在一个命令中设置多个同类型参数，如redis.conf配置文件中的save参数：save 900 1/save 300 10。在该命令中我们可以将多个key/value用双引号括起，并用空格符隔开，如：config set save "900 1 300 10"。 	OK表示设置成功，否则返回相关的错误信息。
CONFIG RESETSTAT 	O(1)	Reset INFO命令给出的统计数字。	始终返回OK。
DBSIZE	 	返回当前打开的数据库中Keys的数量。	Key的数量。
FLUSHALL	 	清空当前服务器管理的数据库中的所有Keys，不仅限于当前打开的数据库。	 
FLUSHDB	 	清空当前数据库中的所有Keys。	 
INFO	 	获取和服务器运行状况相关的一些列统计数字。	 
SAVE	 	设置RDB持久化模式的保存策略。	 
SHUTDOWN	 	停止所有的客户端，同时以阻塞的方式执行内存数据持久化。如果AOF模式被启用，则将缓存中的数据flush到AOF文件。退出服务器。 	 
SLAVEOF host port 	 	该命令用于修改SLAVE服务器的复制设置。如果一个Redis服务器已经处于SLAVE状态，SLAVEOF NO ONE命令将关闭当前服务器的被复制状态，与此同时将该服务器切换到MASTER状态。该命令的参数将指定MASTER服务器的监听IP和端口。还有一种情况是，当前服务器已经是另外一台MASTER的SLAVE了，在执行该命令后，当前服务器将终止和之前MASTER之间的复制关系，而将成为新MASTER的SLAVE，之前MASTER中的数据也将被清空，改为新MASTER中的数据。然而如果在当前SLAVE服务器上执行的是SLAVEOF NO ONE命令，那么该服务器只是中断与当前MASTER的复制关系，并升级为独立的MASTER，其中的数据也不会被清空。	 
SLOWLOG subcommand [argument] 	 	该命令主要用于读取执行时间较长的命令。其中执行时间的评判标准仅为命令本身的执行时间，并不包括网络交互时间。和该命令相关的配置参数主要有两个，第一个就是执行之间的阈值(以微秒为单位)，即执行时间超过该值的命令都会被存入slowlog队列，以供该命令读取。第二个是slowlog队列的长度，如果当前命令在存入之前，该队列中的命令已经等于该参数，在命令进入之前，需要将队列中最老的命令移出队列。这样可以保证该队列所占用的内存总量保持在一个相对恒定的大小。由于slowlog队列不会被持久化到磁盘，因此Redis在收集命令时不会对性能产生很大的影响。通常我们可以将参数"slowlog-log-slower-than"设置为0，以便收集所有命令的执行时间。该命令还包含以下几个子命令：
1). SLOWLOG GET N: 从slowlog队列中读取命令信息，N表示最近N条命令的信息。
2). SLOWLOG LEN：获取slowlog队列的长度。
3). SLOWLOG RESET：清空slowlog中的内容。
最后给出SLOWLOG GET命令返回信息的解释。
redis 127.0.0.1:6379> slowlog get 10
    1) 1) (integer) 5                 #唯一表示符，在Redis重启之前，该值保证唯一。
        2) (integer) 1330369320 #Unix Timestamp格式表示的命令执行时间。
        3) (integer) 13               #命令执行所用的微秒数。
        4) 1) "slowlog"               #以字符串数组的格式输出收集到的命令及其参数。
            2) "reset"

管线

Redis是一种典型的基于C/S模型的TCP服务器。在客户端与服务器的通讯过程中，通常都是客户端率先发起请求，服务器在接收到请求后执行相应的任务，最后再将获取的数据或处理结果以应答的方式发送给客户端。在此过程中，客户端都会以阻塞的方式等待服务器返回的结果。见如下命令序列：

  • Client: INCR X
  • Server: 1
  • Client: INCR X
  • Server: 2
  • Client: INCR X
  • Server: 3
  • Client: INCR X
  • Server: 4

在每一对请求与应答的过程中，我们都不得不承受网络传输所带来的额外开销。我们通常将这种开销称为RTT(Round Trip Time)。现在我们假设每一次请求与应答的RTT为250毫秒，而我们的服务器可以在一秒内处理100k的数据，可结果则是我们的服务器每秒至多处理4条请求。要想解决这一性能问题，我们该如何进行优化呢？

Redis对管线的支持

Redis在很早的版本中就已经提供了对命令管线的支持。在给出具体解释之前，我们先将上面的同步应答方式的例子改造为基于命令管线的异步应答方式，这样可以让大家有一个更好的感性认识。

  • Client: INCR X
  • Client: INCR X
  • Client: INCR X
  • Client: INCR X
  • Server: 1
  • Server: 2
  • Server: 3
  • Server: 4

从以上示例可以看出，客户端在发送命令之后，不用立刻等待来自服务器的应答，而是可以继续发送后面的命令。在命令发送完毕后，再一次性的读取之前所有命令的应答。这样便节省了同步方式中RTT的开销。 最后需要说明的是，如果Redis服务器发现客户端的请求是基于管线的，那么服务器端在接受到请求并处理之后，会将每条命令的应答数据存入队列，之后再发送到客户端。

Benchmark测试



复制代码
 1     require 'rubygems'
 2     require 'redis'
 3     
 4     def bench(descr)
 5         start = Time.now
 6         yield
 7         puts "#{descr} #{Time.now-start} seconds"
 8     end
 9     
10     def without_pipelining
11         r = Redis.new
12         10000.times {
13             r.ping
14         }
15     end
16     
17     def with_pipelining
18         r = Redis.new
19         r.pipelined {
20             10000.times {
21                 r.ping
22             }
23         }
24     end
25     
26     bench("without pipelining") {
27         without_pipelining
28     }
29     bench("with pipelining") {
30         with_pipelining
31     }
32     //without pipelining 1.185238 seconds
33     //with pipelining 0.250783 seconds 

内存优化

自从Redis 2.2之后，很多数据类型都可以通过特殊编码的方式来进行存储空间的优化。其中，Hash、List和由Integer组成的Sets都可以通过该方式来优化存储结构，以便占用更少的空间，在有些情况下，可以省去9/10的空间。 这些特殊编码对于Redis的使用而言是完全透明的，事实上，它只是CPU和内存之间的一个交易而言。如果内存使用率方面高一些，那么在操作数据时消耗的 CPU自然要多一些，反之亦然。在Redis中提供了一组配置参数用于设置与特殊编码相关的各种阈值，如：


#如果Hash中字段的数量小于参数值，Redis将对该Key的Hash Value采用特殊编码。
hash-max-zipmap-entries 64

#如果Hash中各个字段的最大长度不超过512字节，Redis也将对该Key的Hash Value采用特殊编码方式。
hash-max-zipmap-value 512

#下面两个参数的含义基本等同于上面两个和Hash相关的参数，只是作用的对象类型为List。
list-max-ziplist-entries 512
list-max-ziplist-value 64

#如果set中整型元素的数量不超过512时，Redis将会采用该特殊编码。
set-max-intset-entries 512

倘若某个已经被编码的值再经过修改之后超过了配置信息中的最大限制，那么Redis会自动将其转换为正常编码格式，这一操作是非常快速的，但是如果反过来操作，将一个正常编码的较大值转换为特殊编码，Redis的建议是，在正式做之前最好先简单测试一下转换效率，因为这样的转换往往是非常低效的。

二、BIT和Byte级别的操作：

从Redis 2.2开始，Redis提供了GETRANGE/SETRANGE/GETBIT/SETBIT四个用于字符串类型Key/Value的命令。通过这些命令，我们便可以像操作数组那样来访问String类型的值数据了。比如唯一标识用户身份的ID，可能仅仅是String值的其中一段子字符串。这样就可以通过GETRANGE/SETRANGE命令来方便的提取。再有就是可以使用BITMAP来表示用户的性别信息，如1表示male，0表示female。用这种方式来表示100,000,000个用户的性别信息时，也仅仅占用12MB的存储空间，与此同时，在通过SETBIT/GETBIT命令进行数据遍历也是非常高效的。

尽可能使用Hash

由于小的Hash类型数据占用的空间相对较少，因此我们在实际应用时应该尽可能的考虑使用Hash类型，比如用户的注册信息，这其中包括姓名、性别、email、年龄和口令等字段。我们当然可以将这些信息以Key的形式进行存储，而用户填写的信息则以String Value的形式存储。然而Redis则更为推荐以Hash的形式存储，以上信息则以Field/Value的形式表示。

现在我们就通过学习Redis的存储机制来进一步证明这一说法。在该篇博客的开始处已经提到了特殊编码机制，其中有两个和Hash类型相关的配置参数：hash-max-zipmap-entries和hash-max-zipmap-value。至于它们的作用范围前面已经给出，这里就不再过多的赘述了。现在我们先假设存储在Hash Value中的字段数量小于hash-max-zipmap-entries，而每个元素的长度又同时小于hash-max-zipmap-value。这样每当有新的Hash类型的Key/Value存储时，Redis都会为Hash Value创建定长的空间，最大可预分配的字节数为: total_bytes = hash-max-zipmap-entries * hash-max-zipmap-value

这样一来，Hash中所有字段的位置已经预留，并且可以像访问数组那样随机的访问Field/Value，他们之间的步长间隔为hash-max-zipmap-value。只有当Hash Value中的字段数量或某一新元素的长度分别超过以上两个参数值时，Redis才会考虑将他们以Hash Table的方式进行重新存储，否则将始终保持这种高效的存储和访问方式。不仅如此，由于每个Key都要存储一些关联的系统信息，如过期时间、LRU等，因此和String类型的Key/Value相比，Hash类型极大的减少了Key的数量(大部分的Key都以Hash字段的形式表示并存储了)，从而进一步优化了存储空间的使用效率。

如果您觉得这篇文章帮助到了您，可以给作者一点鼓励

avatar
文章
阅读
粉丝