Redis 数据库入门教程

From:http://www.jb51.net/article/56448.htm    http://www.jb51.net/article/65246.htm    http://blog.csdn.net/u012152619/article/category/6419059

Redis 英文官网:https://redis.io/

Redis 中文官网:http://www.redis.cn/        Redis中文网:http://www.redis.net.cn/

Redis 命令参考:http://redisdoc.com/index.html

Redis 菜鸟教程:http://www.runoob.com/redis/redis-tutorial.html

Redis 设计与实现:http://redisbook.com/

Redis基础、高级特性与性能调优:https://www.jianshu.com/p/2f14bc570563



前言


NoSQL数据库(非关系型数据库)一度成为高并发、海量数据存储解决方案的代名词,与之相应的产品也呈现出雨后春笋般的生机。然而在众多产品中能够脱颖而出的却屈指可数,如Redis、MongoDB、BerkeleyDB和CouchDB等。由于每种产品所拥有的特征不同,因此它们的应用场景也存在着一定的差异,下面仅给出简单的说明:
1). BerkeleyDB是一种极为流行的开源嵌入式数据库,在更多情况下可用于存储引擎,比如BerkeleyDB在被Oracle收购之前曾作为MySQL的存储引擎,由此可以预见,该产品拥有极好的并发伸缩性,支持事务及嵌套事务,海量数据存储等重要特征,在用于存储实时数据方面具有极高的可用价值。然而需要指出的是,该产品的Licence为GPL,这就意味着它并不是在所有情况下都是免费使用的。
2). 对MongoDB的定义为Oriented-Document数据库服务器,和BerkeleyDB不同的是该数据库可以像其他关系型数据库服务器那样独立的运行并提供相关的数据服务。从该产品的官方文档中我们可以获悉,MongoDB主要适用于高并发的论坛或博客网站,这些网站具有的主要特征是并发访问量高、多读少写、数据量大、逻辑关系简单,以及文档数据作为主要数据源等。和BerkeleyDB一样,该产品的License同为GPL。
3). Redis,典型的NoSQL数据库服务器,和BerkeleyDB相比,它可以作为服务程序独立运行于自己的服务器主机。在很多时候,人们只是将Redis视为Key/Value数据库服务器,然而事实并非如此,在目前的版本中,Redis除了Key/Value之外还支持List、Hash、Set和Ordered Set等数据结构,因此它的用途也更为宽泛。对于此种误解,Redis官网也进行了相应的澄清。和以上两种产品不同的是,Redis的License是Apache License,就目前而言,它是完全免费。
4). memcached,数据缓存服务器。为什么在这里要给出该产品的解释呢?很简单,因为笔者认为它在使用方式上和Redis最为相似。毕竟这是一篇关于Redis的技术系列博客,有鉴于此,我们将简要的对比一下这两个产品。首先说一下它们之间的最大区别,memcached只是提供了数据缓存服务,一旦服务器宕机,之前在内存中缓存的数据也将全部消失,因此可以看出memcached没有提供任何形式的数据持久化功能,而Redis则提供了这样的功能。再有就是Redis提供了更为丰富的数据存储结构,如Hash和Set。至于它们的相同点,主要有两个,一是完全免费,再有就是它们的提供的命令形式极为接近。


redis 概述


redis 是 Remote Dictionary Server 的简称,是一个由意大利人Salvatore Sanfilippo开发的key-value存储系统,具有极高的读写性能,读的速度可达110000次/s,写的速度可达81000次/s 。与Redis类似的产品还有memcache,同样是一个基于内存的key-value存储系统,但是由于memcache数据结构单一,数据安全性低下等原因,大有被Redis取而代之的趋势。redis是一个开源的、使用C语言编写的、支持网络交互的、可基于内存也可持久化的Key-Value数据库。目前,Vmware在资助着redis项目的开发和维护。

redis的作者何许人也?开门见山,先看照片:


是不是出乎了你的意料,嗯,高手总会有些地方与众不同的。这位便是redis的作者,他叫Salvatore Sanfilippo,来自意大利的西西里岛,现在居住在卡塔尼亚。目前供职于Pivotal公司。他使用的网名是antirez,如果你有兴趣,可以去他的博客逛逛,地址是antirez.com,当然也可以去follow他的github,地址:http://github.com/antirez

Redis 与其他 key - value 缓存产品相比,有以下特点:

1、Redis支持数据的持久化,周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,重启的时候可以再次加载进行使用。
2、Redis不仅仅支持简单的key-value类型的数据,同时还提供list,set,zset,hash等数据结构的存储。
3、Redis支持数据的备份,即master-slave模式的数据备份。
4、Redis的所有操作都是原子性的,同时Redis还支持对几个操作合并后的原子性执行。
5、Redis还支持 publish/subscribe, 通知, key过期等高级特性。

互联网发展到现在,仅靠传统的关系型数据库已经远不能应对各种变态的需求,一个大型的互联网应用往往需要各类数据库相互合作,才能达到高可用、高性能的标准。


比如,使用 mysql/oracle/DB2 管理核心数据,使用 Memcache/Redis 管理热点数据,使用 Hbase/Hadoop 管理海量数据……总之,在合适的地方选择合适的数据库。


谁在使用redis

Blizzard、digg、stackoverflow、github、flickr …



Redis 管理工具


Redis安装好之后,进入安装目录的src文件夹,会发现里面有6个可执行文件:



它们对应着6个管理Redis的工具:


redis-server

该工具用于启动Redis服务器,处理与客户端的对话,一个服务器可以与多个客户端连接。
在终端输入该命令,如果启动成功,就会看到Redis那幅标志性的图片:


Redis提示说:

Warning: no config file specified, using the defaultconfig. In order to specify a config file use Redis-server /path/to/Redis.conf

没有指定配置文件,当前使用的是默认配置。假如想使用位于路径“/winner/setting/”下的Redis.conf作为配置文件,

使用命令 Redis-server /winner/setting/Redis.conf 即可。

最后一行,Redis提示服务器已经准备好在端口6379接受客户端的连接,6379是Redis的默认端口

至于为什么使用6379当做默认端口还有段传闻。写Redis的大神Antirez是意大利人,在意大利有个歌女名为Alessia Merz,长期以来被Antirez及其朋友当作愚蠢的代名词,MERZ对应的手机按键就是6379,后来Antirez开发Redis时就使用这四个数字来当做默认端口。


redis-cli

该工具用于启动Redis客户端,发起与服务器的对话。可以使用参数来指定目标服务器的详细信息,例如使用参数“-h”指定服务器IP地址、“-p”指定服务器端口、“-a”指定登录密码等,如:

Redis-cli –h 192.168.1.2 –p 6300

如不指定任何参数,则默认连接127.0.0.1的6379端口。

与Redis服务器取得连接后,就通过指令进行数据的存取、更改等操作了:


redis-benchmark

该工具用于测试Redis在本机的性能,类似于鲁大师的跑分程序。运行之后会得到一组数据存取效率的报告:


redis-check-aof

Redis虽然是基于内存的数据库,但是会创建并更新在硬盘上的备份,备份有两种方式,一个是把内存的数据导入dump.rdb文件中,另一中就是将每个执行过的命令记录到AOF文件中。该工具用于检查、修复AOF文件。


redis-check-dump

与Redis-check-aof类似,该工具用于检查dump.rdb文件。


redis-sentinel

该工具提供Redis实例的监控管理、通知和实例失效备援服务,是Redis集群的管理工具,监控各个其他节点的工作情况并且进行故障恢复,来提高集群的高可用性。


Redis GUI 工具

Redis Desktop Manager:https://redisdesktop.com/download



学会安装redis


下载地址http://redis.io/download,下载最新 Redis 版本。

$ wget http://download.redis.io/releases/redis-2.8.17.tar.gz  
$ tar xzf redis-2.8.17.tar.gz  
$ cd redis-2.8.17  
$ sudo make && sudo make install  

安装非常简单。make成功后会在src文件夹下产生一些二进制可执行文件,包括redis-server、redis-cli等等:

$ find . -type f -executable
./redis-benchmark //用于进行redis性能测试的工具
./redis-check-dump //用于修复出问题的dump.rdb文件
./redis-cli //redis的客户端
./redis-server //redis的服务端
./redis-check-aof //用于修复出问题的AOF文件
./redis-sentinel //用于集群管理

  

启动redis

下面启动redis服务.

[plain]  view plain  copy
  1. $ cd src  
  2. $ ./redis-server  

注意这种方式启动redis 使用的是默认配置。也可以通过启动参数告诉redis使用指定配置文件使用下面命令启动。

[plain]  view plain  copy
  1. $ cd src  
  2. $ ./redis-server redis.conf  

redis.conf是一个默认的配置文件。我们可以根据需要使用自己的配置文件。
启动redis服务进程后,就可以使用测试客户端程序redis-cli和redis服务交互了。 比如:

[plain]  view plain  copy
  1. $ cd src  
  2. $ ./redis-cli  
  3. redis> set foo bar  
  4. OK  
  5. redis> get foo  
  6. "bar"  

    

Ubuntu 系统安装 Redi 

使用以下命令:

[plain]  view plain  copy
  1. $sudo apt-get update  
  2. $sudo apt-get install redis-server  

启动 Redis

[plain]  view plain  copy
  1. $ redis-server  
查看 redis 是否启动?
[plain]  view plain  copy
  1. $ redis-cli  
以上命令将打开以下终端:
[plain]  view plain  copy
  1. redis 127.0.0.1:6379>  
127.0.0.1 是本机 IP ,6379 是 redis 服务端口。现在我们输入 PING 命令。
[plain]  view plain  copy
  1. redis 127.0.0.1:6379> ping  
  2. PONG  

以上说明我们已经成功安装了redis。


检查Redis服务器程序

# 检查Redis服务器系统进程
~ ps -aux|grep redis
redis     4162  0.1  0.0  10676  1420 ?        Ss   23:24   0:00 /usr/bin/redis-server /etc/redis/redis.conf
conan     4172  0.0  0.0  11064   924 pts/0    S+   23:26   0:00 grep --color=auto redis

# 通过启动命令检查Redis服务器状态
~ netstat -nlt|grep 6379
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN

# 通过启动命令检查Redis服务器状态
~ sudo /etc/init.d/redis-server status
redis-server is running

Windows安装Redis

redis-windows安装+配置介绍:https://www.cnblogs.com/sxdcgaq8080/p/7204878.html

win7x64下的redis安装与使用:https://www.cnblogs.com/koal/p/5484916.html

在Windows系统上安装Redis数据库是件非常简单的事情,下载可执行安装文件(exe),双击安装即可。下载地址:https://github.com/rgl/redis/downloads

  • Redis服务器运行命令:Redis安装目录/redis-server.exe
  • Redis客户端运行命令:Redis安装目录/redis-cli.exe



Redis 命令总结 和 Redis 客户端


概述

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


命令行客户端访问Redis

安装Redis服务器,会自动地一起安装Redis命令行客户端程序。在本机输入redis-cli命令就可以启动,客户端程序访问Redis服务器。

~ redis-cli
redis 127.0.0.1:6379>

# 命令行的帮助
redis 127.0.0.1:6379> help
redis-cli 2.2.12
Type: "help @" to get a list of commands in 
      "help " for help on 
      "help " to get a list of possible help topics
      "quit" to exit


# 查看所有的key列表
redis 127.0.0.1:6379> keys *
(empty list or set)


修改Redis的配置

使用Redis的访问账号

默认情况下,访问Redis服务器是不需要密码的,为了增加安全性我们需要设置Redis服务器的访问密码。设置访问密码为redisredis。
用vi打开Redis服务器的配置文件redis.conf

~ sudo vi /etc/redis/redis.conf

#取消注释requirepass
requirepass redisredis

让Redis服务器被远程访问

默认情况下,Redis服务器不允许远程访问,只允许本机访问,所以我们需要设置打开远程访问的功能。
用vi打开Redis服务器的配置文件redis.conf

~ sudo vi /etc/redis/redis.conf

#注释bind
#bind 127.0.0.1

修改后,重启Redis服务器。

~ sudo /etc/init.d/redis-server restart
Stopping redis-server: redis-server.
Starting redis-server: redis-server.

未使用密码登陆Redis服务器

~ redis-cli

redis 127.0.0.1:6379> keys *
(error) ERR operation not permitted
发现可以登陆,但无法执行命令了。

登陆Redis服务器,输入密码

~  redis-cli -a redisredis

redis 127.0.0.1:6379> keys *
1) "key2"
2) "key3"
3) "key4"
登陆后,一切正常。

检查Redis服务器占用端口

~ netstat -nlt|grep 6379
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN
我们看到从之间的网络监听从 127.0.0.1:3306 变成 0 0.0.0.0:3306,表示Redis已经允许远程登陆访问。

我们在远程的另一台Linux访问Redis服务器

~ redis-cli -a redisredis -h 192.168.1.199

redis 192.168.1.199:6379> keys *
1) "key2"
2) "key3"
3) "key4"
远程访问正常。

创建Redis配置目录 /etc/redis
    mkdir /etc/redis
拷贝配置文件:
    cp /opt/redis/redis-3.2.4/redis.conf/ /etc/redis

通过指定配置文件启动;
    redis-server /etc/redis/redis.conf

通过命令redis-server 启动,可在命令后加上`&`号使redis以后台程序方式运行;
    redis-server &
客户端登陆 
    redis-cli
关闭Redis服务 
    redis-cli 进入 Redis ,然后输入 shutdown 即可。

修改redis.conf(/etc/redis下)

#打开后台运行选项
daemonize yes
#设置日志文件路径
logfile "/var/log/redis/redis.log"


服务器管理命令总结

(1)ping:测定连接是否存活
(2)echo:在命令行打印一些内容
(3)select:选择数据库
(4)quit:退出连接
(5)dbsize:返回当前数据库中key的数目
(6)info:获取服务器的信息和统计
(7)monitor:实时转储收到的请求
(8)config get 配置项:获取服务器配置的信息
   config set 配置项  值:设置配置项信息
(9)flushdb:删除当前选择数据库中所有的key
(10)flushall:删除所有数据库中的所有的key
(11)time:显示服务器时间,时间戳(秒),微秒数
(12)bgrewriteaof:后台保存rdb快照
(13)bgsave:后台保存rdb快照
(14)save:保存rdb快照
(15)lastsave:上次保存时间
(16)shutdown [save/nosave]
    注意:如果不小心运行了flushall,立即shutdown nosave,关闭服务器,然后手工编辑aof文件,去掉文件中的flushall相关行,然后开启服务器,就可以倒回原来是数据。
              如果flushall之后,系统恰好bgwriteaof了,那么aof就清空了,数据丢失。
(17)showlog:显示慢查询
    问:多慢才叫慢?
    答:由slowlog-log-slower-than 10000,来指定(单位为微秒)
    问:服务器存储多少条慢查询记录
    答:由slowlog-max-len 128,来做限制  



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        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 客户端

直接看一个例子:

//这样来启动redis客户端了
$ ./redis-cli
//用set指令来设置key、value
127.0.0.1:6379> set name "roc" 
OK
//来获取name的值
127.0.0.1:6379> get name 
"roc"
//通过客户端来关闭redis服务端
127.0.0.1:6379> shutdown 
127.0.0.1:6379>



一、key pattern 查询相应的key

  (1)keys key_pattern   查询满足表达式的 所有 key。redis允许模糊查询key  有3个通配符  *、?、[]
  (2)randomkey:返回随机key  
  (3)type key:返回key存储的类型
  (4)exists key:判断某个key是否存在
  (5)del key:删除key
  (6)rename key newkey:改名
  (7)renamenx key newkey:如果newkey不存在则修改成功
  (8)move key 1:将key移动到1数据库
  (9)ttl key:查询key的生命周期(秒)
  (10)expire key 整数值:设置key的生命周期以秒为单位
  (11)pexpire key 整数值:设置key的生命周期以毫秒为单位
  (12)pttl key:查询key 的生命周期(毫秒)
  (13)perisist key:把指定key设置为永久有效

二、字符串类型的操作

  (1)set key value [ex 秒数] [px 毫秒数] [nx/xx]  
      如果ex和px同时写,则以后面的有效期为准
      nx:如果key不存在则建立
      xx:如果key存在则修改其值
  (2)get key:取值
  (3)mset key1 value1 key2 value2 一次设置多个值
  (4)mget key1 key2 :一次获取多个值
  (5)setrange key offset value:把字符串的offset偏移字节改成value
                  如果偏移量 > 字符串长度,该字符自动补0x00
  (6)append key value :把value追加到key 的原值上
  (7)getrange key start stop:获取字符串中[start, stop]范围的值
                  对于字符串的下标,左数从0开始,右数从-1开始
                  注意:当start>length,则返回空字符串
                     当stop>=length,则截取至字符串尾
                     如果start所处位置在stop右边,则返回空字符串
  (8)getset key nrevalue:获取并返回旧值,在设置新值
  (9)incr key:自增,返回新值,如果incr一个不是int的value则返回错误,incr一个不存在的key,则设置key为1
  (10)incrby key 2:跳2自增
  (11)incrbyfloat by 0.7: 自增浮点数 
  (12)setbit key offset value:设置offset对应二进制上的值,返回该位上的旧值
                 注意:如果offset过大,则会在中间填充0
                    offset最大到多少
                     2^32-1,即可推出最大的字符串为512M
  (13)bitop operation destkey key1 [key2..]    对key1 key2做opecation并将结果保存在destkey上
                          opecation可以是AND OR NOT XOR
  (14)strlen key:取指定key的value值的长度
   (15)setex key time value:设置key对应的值value,并设置有效期为time秒

三、链表操作

  Redis的list类型其实就是一个每个子元素都是string类型的双向链表,链表的最大长度是2^32。list既可以用做栈,也可以用做队列。
  list的pop操作还有阻塞版本,主要是为了避免轮询

  (1)lpush key value:把值插入到链表头部
  (2)rpush key value:把值插入到链表尾部
  (3)lpop key :返回并删除链表头部元素
  (4)rpop key: 返回并删除链表尾部元素
  (5)lrange key start stop:返回链表中[start, stop]中的元素
  (6)lrem key count value:从链表中删除value值,删除count的绝对值个value后结束
                count > 0 从表头删除  count < 0 从表尾删除  count=0 全部删除
  (7)ltrim key start stop:剪切key对应的链接,切[start, stop]一段并把改制重新赋给key
  (8)lindex key index:返回index索引上的值
  (9)llen key:计算链表的元素个数
  (10)linsert key after|before search value:在key 链表中寻找search,并在search值之前|之后插入value
  (11)rpoplpush source dest:把source 的末尾拿出,放到dest头部,并返回单元值
    应用场景: task + bak 双链表完成安全队列

 业务逻辑: rpoplpush task bak
         接收返回值并做业务处理
         如果成功则rpop bak清除任务,如果不成功,下次从bak表取任务
  (12)brpop,blpop key timeout:等待弹出key的尾/头元素
                timeout为等待超时时间,如果timeout为0则一直等待下去
      应用场景:长轮询ajax,在线聊天时能用到

四、hashes类型及操作

        Redis hash 是一个string类型的field和value的映射表,它的添加、删除操作都是O(1)(平均)。

        hash特别适用于存储对象,将一个对象存储在hash类型中会占用更少的内存,并且可以方便的存取整个对象。
        配置: hash_max_zipmap_entries 64 #配置字段最多64个
                    hash_max_zipmap_value 512 #配置value最大为512字节

  (1)hset myhash field value:设置myhash的field为value
  (2)hsetnx myhash field value:不存在的情况下设置myhash的field为value
  (3)hmset myhash field1 value1 field2 value2:同时设置多个field
  (4)hget myhash field:获取指定的hash field
  (5)hmget myhash field1 field2:一次获取多个field
  (6)hincrby myhash field 5:指定的hash field加上给定的值
  (7)hexists myhash field:测试指定的field是否存在
  (8)hlen myhash:返回hash的field数量
  (9)hdel myhash field:删除指定的field
  (10)hkeys myhash:返回hash所有的field
  (11)hvals myhash:返回hash所有的value
  (12)hgetall myhash:获取某个hash中全部的field及value 

五、集合结构操作

特点:无序性、确定性、唯一性

  (1)sadd key value1 value2:往集合里面添加元素
  (2)smembers key:获取集合所有的元素
  (3)srem key value:删除集合某个元素
  (4)spop key:返回并删除集合中1个随机元素(可以坐抽奖,不会重复抽到某人)   
  (5)srandmember key:随机取一个元素
  (6)sismember key value:判断集合是否有某个值
  (7)scard key:返回集合元素的个数
  (8)smove source dest value:把source的value移动到dest集合中
  (9)sinter key1 key2 key3:求key1 key2 key3的交集
  (10)sunion key1 key2:求key1 key2 的并集
  (11)sdiff key1 key2:求key1 key2的差集
  (12)sinterstore res key1 key2:求key1 key2的交集并存在res里 

六、有序集合

  概念:它是在set的基础上增加了一个顺序属性,这一属性在添加修改元素的时候可以指定,每次指定后,zset会自动按新的值调整顺序。可以理解为有两列的mysql表,一列存储value,一列存储顺序,操作中key理解为zset的名字。
  和set一样sorted,sets也是string类型元素的集合,不同的是每个元素都会关联一个double型的score。sorted set的实现是skip list和hash table的混合体。
  当元素被添加到集合中时,一个元素到score的映射被添加到hash table中,所以给定一个元素获取score的开销是O(1)。另一个score到元素的映射被添加的skip list,并按照score排序,所以就可以有序地获取集合中的元素。添加、删除操作开销都是O(logN)和skip list的开销一致,redis的skip list 实现是双向链表,这样就可以逆序从尾部去元素。sorted set最经常使用方式应该就是作为索引来使用,我们可以把要排序的字段作为score存储,对象的ID当元素存储。

  (1)zadd key score1 value1:添加元素
  (2)zrange key start stop [withscore]:把集合排序后,返回名次[start,stop]的元素  默认是升续排列  withscores 是把score也打印出来
  (3)zrank key member:查询member的排名(升序0名开始)
  (4)zrangebyscore key min max [withscores] limit offset N:集合(升序)排序后取score在[min, max]内的元素,并跳过offset个,取出N个
  (5)zrevrank key member:查询member排名(降序 0名开始)
  (6)zremrangebyscore key min max:按照score来删除元素,删除score在[min, max]之间
  (7)zrem key value1 value2:删除集合中的元素
  (8)zremrangebyrank key start end:按排名删除元素,删除名次在[start, end]之间的
  (9)zcard key:返回集合元素的个数
  (10)zcount key min max:返回[min, max]区间内元素数量
  (11)zinterstore dest numkeys key1[key2..] [WEIGHTS weight1 [weight2...]] [AGGREGATE SUM|MIN|MAX]
      求key1,key2的交集,key1,key2的权值分别是weight1,weight2
      聚合方法用 sum|min|max
      聚合结果 保存子dest集合内
      注意:weights,aggregate如何理解?
      答:如果有交集,交集元素又有score,score怎么处理?aggregate num->score相加,min最小score,max最大score,另外可以通过weights设置不同的key的权重,交集时  score*weight




Redis 管线 详解


请求应答协议和RTT:

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条请求。要想解决这一性能问题,我们该如何进行优化呢?


管线(pipelining):

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

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

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


Benchmark:

以下是来自Redis官网的测试用例和测试结果。需要说明的是,该测试是基于loopback(127.0.0.1)的,因此RTT所占用的时间相对较少,如果是基于实际网络接口,那么管线机制所带来的性能提升就更为显著了。 

下面 Ruby 代码示例:

require 'rubygems'
    require 'redis'
    
    def bench(descr)
        start = Time.now
        yield
        puts "#{descr} #{Time.now-start} seconds"
    end
    
    def without_pipelining
        r = Redis.new
        10000.times {
            r.ping
        }
    end
    
    def with_pipelining
        r = Redis.new
        r.pipelined {
            10000.times {
                r.ping
            }
        }
    end
    
    bench("without pipelining") {
        without_pipelining
    }
    bench("with pipelining") {
        with_pipelining
    }
    //without pipelining 1.185238 seconds
    //with pipelining 0.250783 seconds


redis数据结构 – 简介


redis 是一种高级的 key:value 存储系统,其中 value 支持五种数据类型:

1.字符串(strings)
2.字符串列表(lists)
3.字符串集合(sets)
4.有序字符串集合(sorted sets)
5.哈希(hashes)

redis定义了丰富的原语命令,可以直接与Redis服务器交互。实际应用中,我们不太会直接使用这些原语命令,Redis提供了Java,C/C++,C#,PHP,JavaScript,Perl,Object-C,Python,Ruby,Erlang等客户端,大多情况下我们是通过各式各样的客户端来操作Redis。但是,任何语言的客户端实际上都是对Redis原语命令的封装,了解原语命令有助于理解客户端的设计原理,知其然,知其所以然。

而关于key,有几个点要提醒大家:

1.key不要太长,尽量不要超过1024字节,这不仅消耗内存,而且会降低查找的效率;
2.key也不要太短,太短的话,key的可读性会降低;
3.在一个项目中,key最好使用统一的命名模式,例如user:10000:passwd。


Redis 的 Key操作命令详解


命令原型	时间复杂度		返回值
KEYS pattern	O(N)	       匹配模式的键列表。
        时间复杂度中的N表示数据库中Key的数量。获取所有匹配pattern参数的Keys。
        需要说明的是,在我们的正常操作中应该尽量避免对该命令的调用,
        因为对于大型数据库而言,该命令是非常耗时的,对Redis服务器的性能打击也是比较大的。
        pattern支持glob-style的通配符格式,如*表示任意一个或多个字符,?表示任意字符,[abc]表示方括号中任意一个字母。	

DEL key [key ...]	O(N)	   实际被删除的Key数量。
        时间复杂度中的N表示删除的Key数量。
        从数据库删除中参数中指定的keys,如果指定键不存在,则直接忽略。
        还需要另行指出的是,如果指定的Key关联的数据类型不是String类型,而是List、Set、Hashes和Sorted Set等容器类型,
        该命令删除每个键的时间复杂度为O(M),其中M表示容器中元素的数量。而对于String类型的Key,其时间复杂度为O(1)。	
EXISTS key 	        O(1)	   1表示存在,0表示不存在。
        判断指定键是否存在。	
MOVE key db 	    O(1)	   移动成功返回1,否则0。
        将当前数据库中指定的键Key移动到参数中指定的数据库中。
        如果该Key在目标数据库中已经存在,或者在当前数据库中并不存在,该命令将不做任何操作并返回0。  	
        RENAME key newkey 	O(1)	   如果newKey已经存在,则直接覆盖。 
        为指定指定的键重新命名,如果参数中的两个Keys的命令相同,或者是源Key不存在,该命令都会返回相关的错误信息。
	 
RENAMENX key newkey	O(1)	   1表示修改成功,否则0。
        如果新值不存在,则将参数中的原值修改为新值。其它条件和RENAME一致。	
PERSIST key	        O(1)	   1表示Key的过期时间被移出,0表示该Key不存在或没有过期时间。
        如果Key存在过期时间,该命令会将其过期时间消除,使该Key不再有超时,而是可以持久化存储。	
EXPIRE key seconds 	O(1) 	    1表示超时被设置,0则表示Key不存在,或不能被设置。
        该命令为参数中指定的Key设定超时的秒数,在超过该时间后,Key被自动的删除。
        如果该Key在超时之前被修改,与该键关联的超时将被移除。 	
EXPIREAT key timestamp 	O(1) 	 1表示超时被设置,0则表示Key不存在,或不能被设置。
        该命令的逻辑功能和EXPIRE完全相同,唯一的差别是该命令指定的超时时间是绝对时间,而不是相对时间。
        该时间参数是Unix timestamp格式的,即从1970年1月1日开始所流经的秒数。	 
TTL key 	            O(1)	    返回所剩描述,如果该键不存在或没有超时设置,则返回-1。
        获取该键所剩的超时描述。 	
RANDOMKEY	            O(1)  	    返回的随机键,如果该数据库是空的则返回nil。
        从当前打开的数据库中随机的返回一个Key。	
TYPE key 	            O(1) 	    返回的字符串为string、list、set、hash和zset,如果key不存在返回none。
        获取与参数中指定键关联值的类型,该命令将以字符串的格式返回。	

SORT key [BY pattern] [LIMIT offset count] [GET pattern [GET pattern ...]] [ASC|DESC] [ALPHA] [STORE destination] 	O(N+M*log(M)) 	
        这个命令相对来说是比较复杂的,因此我们这里只是给出最基本的用法,有兴趣的网友可以去参考redis的官方文档。	返回排序后的原始列表。

命令示例

1. KEYS/RENAME/DEL/EXISTS/MOVE/RENAMENX:
    #在Shell命令行下启动Redis客户端工具。
    /> redis-cli
    #清空当前选择的数据库,以便于对后面示例的理解。
    redis 127.0.0.1:6379> flushdb
    OK
    #添加String类型的模拟数据。
    redis 127.0.0.1:6379> set mykey 2
    OK
    redis 127.0.0.1:6379> set mykey2 "hello"
    OK
    #添加Set类型的模拟数据。
    redis 127.0.0.1:6379> sadd mysetkey 1 2 3
    (integer) 3
    #添加Hash类型的模拟数据。
    redis 127.0.0.1:6379> hset mmtest username "stephen"
    (integer) 1
    #根据参数中的模式,获取当前数据库中符合该模式的所有key,从输出可以看出,该命令在执行时并不区分与Key关联的Value类型。
    redis 127.0.0.1:6379> keys my*
    1) "mysetkey"
    2) "mykey"
    3) "mykey2"
    #删除了两个Keys。
    redis 127.0.0.1:6379> del mykey mykey2
    (integer) 2
    #查看一下刚刚删除的Key是否还存在,从返回结果看,mykey确实已经删除了。
    redis 127.0.0.1:6379> exists mykey
    (integer) 0
    #查看一下没有删除的Key,以和上面的命令结果进行比较。
    redis 127.0.0.1:6379> exists mysetkey
    (integer) 1
    #将当前数据库中的mysetkey键移入到ID为1的数据库中,从结果可以看出已经移动成功。
    redis 127.0.0.1:6379> move mysetkey 1
    (integer) 1
    #打开ID为1的数据库。
    redis 127.0.0.1:6379> select 1
    OK
    #查看一下刚刚移动过来的Key是否存在,从返回结果看已经存在了。
    redis 127.0.0.1:6379[1]> exists mysetkey
    (integer) 1
    #在重新打开ID为0的缺省数据库。
    redis 127.0.0.1:6379[1]> select 0
    OK
    #查看一下刚刚移走的Key是否已经不存在,从返回结果看已经移走。
    redis 127.0.0.1:6379> exists mysetkey
    (integer) 0
    #准备新的测试数据。    
    redis 127.0.0.1:6379> set mykey "hello"
    OK
    #将mykey改名为mykey1
    redis 127.0.0.1:6379> rename mykey mykey1
    OK
    #由于mykey已经被重新命名,再次获取将返回nil。
    redis 127.0.0.1:6379> get mykey
    (nil)
    #通过新的键名获取。
    redis 127.0.0.1:6379> get mykey1
    "hello"
    #由于mykey已经不存在了,所以返回错误信息。
    redis 127.0.0.1:6379> rename mykey mykey1
    (error) ERR no such key
    #为renamenx准备测试key
    redis 127.0.0.1:6379> set oldkey "hello"
    OK
    redis 127.0.0.1:6379> set newkey "world"
    OK
    #由于newkey已经存在,因此该命令未能成功执行。
    redis 127.0.0.1:6379> renamenx oldkey newkey
    (integer) 0
    #查看newkey的值,发现它也没有被renamenx覆盖。
    redis 127.0.0.1:6379> get newkey
    "world"
     
2. PERSIST/EXPIRE/EXPIREAT/TTL:    
    #为后面的示例准备的测试数据。
    redis 127.0.0.1:6379> set mykey "hello"
    OK
    #将该键的超时设置为100秒。
    redis 127.0.0.1:6379> expire mykey 100
    (integer) 1
    #通过ttl命令查看一下还剩下多少秒。
    redis 127.0.0.1:6379> ttl mykey
    (integer) 97
    #立刻执行persist命令,该存在超时的键变成持久化的键,即将该Key的超时去掉。
    redis 127.0.0.1:6379> persist mykey
    (integer) 1
    #ttl的返回值告诉我们,该键已经没有超时了。
    redis 127.0.0.1:6379> ttl mykey
    (integer) -1
    #为后面的expire命令准备数据。
    redis 127.0.0.1:6379> del mykey
    (integer) 1
    redis 127.0.0.1:6379> set mykey "hello"
    OK
    #设置该键的超时被100秒。
    redis 127.0.0.1:6379> expire mykey 100
    (integer) 1
    #用ttl命令看一下当前还剩下多少秒,从结果中可以看出还剩下96秒。
    redis 127.0.0.1:6379> ttl mykey
    (integer) 96
    #重新更新该键的超时时间为20秒,从返回值可以看出该命令执行成功。
    redis 127.0.0.1:6379> expire mykey 20
    (integer) 1
    #再用ttl确认一下,从结果中可以看出果然被更新了。
    redis 127.0.0.1:6379> ttl mykey
    (integer) 17
    #立刻更新该键的值,以使其超时无效。
    redis 127.0.0.1:6379> set mykey "world"
    OK
    #从ttl的结果可以看出,在上一条修改该键的命令执行后,该键的超时也无效了。
    redis 127.0.0.1:6379> ttl mykey
    (integer) -1

3. TYPE/RANDOMKEY/SORT:
    #由于mm键在数据库中不存在,因此该命令返回none。
    redis 127.0.0.1:6379> type mm
    none
    #mykey的值是字符串类型,因此返回string。
    redis 127.0.0.1:6379> type mykey
    string
    #准备一个值是set类型的键。
    redis 127.0.0.1:6379> sadd mysetkey 1 2
    (integer) 2
    #mysetkey的键是set,因此返回字符串set。
    redis 127.0.0.1:6379> type mysetkey
    set
    #返回数据库中的任意键。
    redis 127.0.0.1:6379> randomkey
    "oldkey"
    #清空当前打开的数据库。
    redis 127.0.0.1:6379> flushdb
    OK
    #由于没有数据了,因此返回nil。
    redis 127.0.0.1:6379> randomkey
    (nil)


redis数据结构 – strings


有人说,如果只使用redis中的字符串类型,且不使用redis的持久化功能,那么,redis就和memcache非常非常的像了。这说明strings类型是一个很基础的数据类型,也是任何存储系统都必备的数据类型。 字符串类型是Redis中最为基础的数据存储类型,它在Redis中是二进制安全的,这便意味着该类型可以接受任何格式的数据,如JPEG图像数据或Json对象描述信息等。在Redis中字符串类型的Value最多可以容纳的数据长度是512M。
看一个最简单的例子:

set mystr "hello world!" //设置字符串类型
get mystr //读取字符串类型


字符串类型的用法就是这么简单,因为是二进制安全的,所以你完全可以把一个图片文件的内容作为字符串来存储。
另外,我们还可以通过字符串类型进行数值操作:

127.0.0.1:6379> set mynum "2"
OK
127.0.0.1:6379> get mynum
"2"
127.0.0.1:6379> incr mynum
(integer) 3
127.0.0.1:6379> get mynum
"3"

看,在遇到数值操作时,redis会将字符串类型转换成数值。由于INCR等指令本身就具有原子操作的特性,所以我们完全可以利用redis的INCR、INCRBY、DECR、DECRBY等指令来实现原子计数的效果,假如,在某种场景下有3个客户端同时读取了mynum的值(值为2),然后对其同时进行了加1的操作,那么,最后mynum的值一定是5。不少网站都利用redis的这个特性来实现业务上的统计计数需求。

命令原型	        时间复杂度		返回值
APPEND key value	    O(1)	     追加后Value的长度。
        如果该Key已经存在,APPEND命令将参数Value的数据追加到已存在Value的末尾。
        如果该Key不存在,APPEND命令将会创建一个新的Key/Value。
	
DECR key	            O(1) 	     递减后的Value值。
        将指定Key的Value原子性的递减1。如果该Key不存在,其初始值为0,在decr之后其值为-1。
        如果Value的值不能转换为整型值,如Hello,该操作将执行失败并返回相应的错误信息。
        注意:该操作的取值范围是64位有符号整型。
	
INCR key	            O(1) 	     递增后的Value值。 
        将指定Key的Value原子性的递增1。如果该Key不存在,其初始值为0,在incr之后其值为1。
        如果Value的值不能转换为整型值,如Hello,该操作将执行失败并返回相应的错误信息。
        注意:该操作的取值范围是64位有符号整型。 	

DECRBY key decrement  	O(1)  	             减少后的Value值。
        将指定Key的Value原子性的减少decrement。如果该Key不存在,其初始值为0,在decrby之后其值为-decrement。
        如果Value的值不能转换为整型值,如Hello,该操作将执行失败并返回相应的错误信息。
        注意:该操作的取值范围是64位有符号整型。 
	
INCRBY key increment  	O(1) 	             增加后的Value值。
        将指定Key的Value原子性的增加increment。如果该Key不存在,其初始值为0,在incrby之后其值为increment。
        如果Value的值不能转换为整型值,如Hello,该操作将执行失败并返回相应的错误信息。
        注意:该操作的取值范围是64位有符号整型。 	

GET key 	            O(1) 	     与该Key相关的Value,如果该Key不存在,返回nil。
        获取指定Key的Value。如果与该Key关联的Value不是string类型,Redis将返回错误信息,因为GET命令只能用于获取string Value。 	

SET key value 	        O(1) 	             总是返回"OK"。
        设定该Key持有指定的字符串Value,如果该Key已经存在,则覆盖其原有值。	

GETSET key value	    O(1) 	     返回该Key的原有值,如果该Key之前并不存在,则返回nil。
        原子性的设置该Key为指定的Value,同时返回该Key的原有值。
        和GET命令一样,该命令也只能处理string Value,否则Redis将给出相关的错误信息。	

STRLEN key	            O(1)	     返回指定Key的Value字符长度,如果该Key不存在,返回0。
        返回指定Key的字符值长度,如果Value不是string类型,Redis将执行失败并给出相关的错误信息。	

SETEX key seconds value	    O(1)	
        原子性完成两个操作,一是设置该Key的值为指定字符串,同时设置该Key在Redis服务器中的存活时间(秒数)。
        该命令主要应用于Redis被当做Cache服务器使用时。	 
SETNX key value 	        O(1) 	   1表示设置成功,否则0。
        如果指定的Key不存在,则设定该Key持有指定字符串Value,此时其效果等价于SET命令。
        相反,如果该Key已经存在,该命令将不做任何操作并返回。	
SETRANGE key offset value 	O(1) 	   修改后的字符串Value长度。
        替换指定Key的部分字符串值。从offset开始,替换的长度为该命令第三个参数value的字符串长度,
        其中如果offset的值大于该Key的原有值Value的字符串长度,Redis将会在Value的后面补齐(offset - strlen(value))数量的0x00,
        之后再追加新值。如果该键不存在,该命令会将其原值的长度假设为0,并在其后添补offset个0x00后再追加新值。
        鉴于字符串Value的最大长度为512M,因此offset的最大值为536870911。
        最后需要注意的是,如果该命令在执行时致使指定Key的原有值长度增加,这将会导致Redis重新分配足够的内存以容纳替换后的全部字符串,
        因此就会带来一定的性能折损。 	
GETRANGE key start end	    O(1) 	          子字符串 
        如果截取的字符串长度很短,我们可以该命令的时间复杂度视为O(1),否则就是O(N),这里N表示截取的子字符串长度。
        该命令在截取子字符串时,将以闭区间的方式同时包含start(0表示第一个字符)和end所在的字符,
        如果end值超过Value的字符长度,该命令将只是截取从start开始之后所有的字符数据。	
SETBIT key offset value 	O(1) 	          在指定Offset上的BIT原有值。
        设置在指定Offset上BIT的值,该值只能为1或0,在设定后该命令返回该Offset上原有的BIT值。
		如果指定Key不存在,该命令将创建一个新值,并在指定的Offset上设定参数中的BIT值。
		如果Offset大于Value的字符长度,Redis将拉长Value值并在指定Offset上设置参数中的BIT值,中间添加的BIT值为0。
		最后需要说明的是Offset值必须大于0。 	
GETBIT key offset 	    O(1) 	           在指定Offset上的BIT值。
		返回在指定Offset上BIT的值,0或1。如果Offset超过string value的长度,该命令将返回0,所以对于空字符串始终返回0。	
 
MGET key [key ...] 	    O(N) 	           返回一组指定Keys的Values的列表。
		N表示获取Key的数量。返回所有指定Keys的Values,如果其中某个Key不存在,或者其值不为string类型,该Key的Value将返回nil。

MSET key value [key value ...] 	    O(N) 	    该命令不会失败,始终返回OK。
		N表示指定Key的数量。该命令原子性的完成参数中所有key/value的设置操作,其具体行为可以看成是多次迭代执行SET命令。 	
  
MSETNX key value [key value ...] 	O(N)	    1表示所有Keys都设置成功,0则表示没有任何Key被修改。
		N表示指定Key的数量。该命令原子性的完成参数中所有key/value的设置操作,其具体行为可以看成是多次迭代执行SETNX命令。
		然而这里需要明确说明的是,如果在这一批Keys中有任意一个Key已经存在了,那么该操作将全部回滚,即所有的修改都不会生效。

命令示例:

1. SET/GET/APPEND/STRLEN:

/> redis-cli   #执行Redis客户端工具。
redis 127.0.0.1:6379> exists mykey                   #判断该键是否存在,存在返回1,否则返回0。
(integer) 0
redis 127.0.0.1:6379> append mykey "hello"      #该键并不存在,因此append命令返回当前Value的长度。
(integer) 5
redis 127.0.0.1:6379> append mykey " world"    #该键已经存在,因此返回追加后Value的长度。
(integer) 11
redis 127.0.0.1:6379> get mykey                      #通过get命令获取该键,以判断append的结果。
"hello world"
redis 127.0.0.1:6379> set mykey "this is a test" #通过set命令为键设置新值,并覆盖原有值。
OK
redis 127.0.0.1:6379> get mykey
"this is a test"
redis 127.0.0.1:6379> strlen mykey                  #获取指定Key的字符长度,等效于C库中strlen函数。
(integer) 14

2. INCR/DECR/INCRBY/DECRBY:

redis 127.0.0.1:6379> set mykey 20     #设置Key的值为20
OK
redis 127.0.0.1:6379> incr mykey         #该Key的值递增1
(integer) 21
redis 127.0.0.1:6379> decr mykey        #该Key的值递减1
(integer) 20
redis 127.0.0.1:6379> del mykey          #删除已有键。
(integer) 1
redis 127.0.0.1:6379> decr mykey        #对空值执行递减操作,其原值被设定为0,递减后的值为-1
(integer) -1
redis 127.0.0.1:6379> del mykey   
(integer) 1
redis 127.0.0.1:6379> incr mykey        #对空值执行递增操作,其原值被设定为0,递增后的值为1
(integer) 1
redis 127.0.0.1:6379> set mykey hello #将该键的Value设置为不能转换为整型的普通字符串。
OK
redis 127.0.0.1:6379> incr mykey        #在该键上再次执行递增操作时,Redis将报告错误信息。
(error) ERR value is not an integer or out of range
redis 127.0.0.1:6379> set mykey 10
OK
redis 127.0.0.1:6379> decrby mykey 5 
(integer) 5
redis 127.0.0.1:6379> incrby mykey 10
(integer) 15

3. GETSET:

redis 127.0.0.1:6379> incr mycounter      #将计数器的值原子性的递增1
(integer) 1
#在获取计数器原有值的同时,并将其设置为新值,这两个操作原子性的同时完成。
redis 127.0.0.1:6379> getset mycounter 0  
"1"
redis 127.0.0.1:6379> get mycounter       #查看设置后的结果。
"0"

4. SETEX:

redis 127.0.0.1:6379> setex mykey 10 "hello"   #设置指定Key的过期时间为10秒。
OK    
#通过ttl命令查看一下指定Key的剩余存活时间(秒数),0表示已经过期,-1表示永不过期。
redis 127.0.0.1:6379> ttl mykey                       
(integer) 4
redis 127.0.0.1:6379> get mykey                      #在该键的存活期内我们仍然可以获取到它的Value。
"hello"
redis 127.0.0.1:6379> ttl mykey                        #该ttl命令的返回值显示,该Key已经过期。
(integer) 0
redis 127.0.0.1:6379> get mykey                      #获取已过期的Key将返回nil。
(nil)

5. SETNX:

redis 127.0.0.1:6379> del mykey                      #删除该键,以便于下面的测试验证。
(integer) 1
redis 127.0.0.1:6379> setnx mykey "hello"        #该键并不存在,因此该命令执行成功。
(integer) 1
redis 127.0.0.1:6379> setnx mykey "world"       #该键已经存在,因此本次设置没有产生任何效果。
(integer) 0
redis 127.0.0.1:6379> get mykey                      #从结果可以看出,返回的值仍为第一次设置的值。
"hello"

6. SETRANGE/GETRANGE:

redis 127.0.0.1:6379> set mykey "hello world"       #设定初始值。
OK
redis 127.0.0.1:6379> setrange mykey 6 dd          #从第六个字节开始替换2个字节(dd只有2个字节)
(integer) 11
redis 127.0.0.1:6379> get mykey                         #查看替换后的值。
"hello ddrld"
redis 127.0.0.1:6379> setrange mykey 20 dd        #offset已经超过该Key原有值的长度了,该命令将会在末尾补0。
(integer) 22
redis 127.0.0.1:6379> get mykey                           #查看补0后替换的结果。
"hello ddrld\x00\x00\x00\x00\x00\x00\x00\x00\x00dd"
redis 127.0.0.1:6379> del mykey                         #删除该Key。
(integer) 1
redis 127.0.0.1:6379> setrange mykey 2 dd         #替换空值。
(integer) 4
redis 127.0.0.1:6379> get mykey                        #查看替换空值后的结果。
"\x00\x00dd"   
redis 127.0.0.1:6379> set mykey "0123456789"   #设置新值。
OK
redis 127.0.0.1:6379> getrange mykey 1 2      #截取该键的Value,从第一个字节开始,到第二个字节结束。
"12"
redis 127.0.0.1:6379> getrange mykey 1 20   #20已经超过Value的总长度,因此将截取第一个字节后面的所有字节。
"123456789"

7. SETBIT/GETBIT:

redis 127.0.0.1:6379> del mykey
(integer) 1
redis 127.0.0.1:6379> setbit mykey 7 1       #设置从0开始计算的第七位BIT值为1,返回原有BIT值0
(integer) 0
redis 127.0.0.1:6379> get mykey                #获取设置的结果,二进制的0000 0001的十六进制值为0x01
"\x01"
redis 127.0.0.1:6379> setbit mykey 6 1       #设置从0开始计算的第六位BIT值为1,返回原有BIT值0
(integer) 0
redis 127.0.0.1:6379> get mykey                #获取设置的结果,二进制的0000 0011的十六进制值为0x03
"\x03"
redis 127.0.0.1:6379> getbit mykey 6          #返回了指定Offset的BIT值。
(integer) 1
redis 127.0.0.1:6379> getbit mykey 10        #Offset已经超出了value的长度,因此返回0。
(integer) 0

8. MSET/MGET/MSETNX:

redis 127.0.0.1:6379> mset key1 "hello" key2 "world"   #批量设置了key1和key2两个键。
OK
redis 127.0.0.1:6379> mget key1 key2                        #批量获取了key1和key2两个键的值。
1) "hello"
2) "world"
#批量设置了key3和key4两个键,因为之前他们并不存在,所以该命令执行成功并返回1。
redis 127.0.0.1:6379> msetnx key3 "stephen" key4 "liu" 
(integer) 1
redis 127.0.0.1:6379> mget key3 key4                   
1) "stephen"
2) "liu"
#批量设置了key3和key5两个键,但是key3已经存在,所以该命令执行失败并返回0。
redis 127.0.0.1:6379> msetnx key3 "hello" key5 "world" 
(integer) 0
#批量获取key3和key5,由于key5没有设置成功,所以返回nil。
redis 127.0.0.1:6379> mget key3 key5                   
1) "stephen"
2) (nil)


redis数据结构 – lists


redis的另一个重要的数据结构叫做lists,翻译成中文叫做“列表”。
首先要明确一点,redis中的lists在底层实现上并不是数组,而是链表,也就是说对于一个具有上百万个元素的lists来说,在头部和尾部插入一个新元素,其时间复杂度是常数级别的,比如用LPUSH在10个元素的lists头部插入新元素,和在上千万元素的lists头部插入新元素的速度应该是相同的。虽然lists有这样的优势,但同样有其弊端,那就是,链表型lists的元素定位会比较慢,而数组型lists的元素定位就会快得多。lists的常用操作包括LPUSH、RPUSH、LRANGE等。我们可以用LPUSH在lists的左侧插入一个新元素,用RPUSH在lists的右侧插入一个新元素,用LRANGE命令从lists中指定一个范围来提取元素。

在Redis中,List类型是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样,我们可以在其头部(left)和尾部(right)添加新的元素。在插入时,如果该键并不存在,Redis将为该键创建一个新的链表。与此相反,如果链表中所有的元素均被移除,那么该键也将会被从数据库中删除。List中可以包含的最大元素数量是4294967295。
从元素插入和删除的效率视角来看,如果我们是在链表的两头插入或删除元素,这将会是非常高效的操作,即使链表中已经存储了百万条记录,该操作也可以在常量时间内完成。然而需要说明的是,如果元素插入或删除操作是作用于链表中间,那将会是非常低效的。相信对于有良好数据结构基础的开发者而言,这一点并不难理解。

我们来看几个例子:

//新建一个list叫做mylist,并在列表头部插入元素"1"
127.0.0.1:6379> lpush mylist "1" 
//返回当前mylist中的元素个数
(integer) 1 
//在mylist右侧插入元素"2"
127.0.0.1:6379> rpush mylist "2" 
(integer) 2
//在mylist左侧插入元素"0"
127.0.0.1:6379> lpush mylist "0" 
(integer) 3
//列出mylist中从编号0到编号1的元素
127.0.0.1:6379> lrange mylist 0 1 
1) "0"
2) "1"
//列出mylist中从编号0到倒数第一个元素
127.0.0.1:6379> lrange mylist 0 -1 
1) "0"
2) "1"
3) "2"

lists的应用相当广泛,随便举几个例子:
1.我们可以利用lists来实现一个消息队列,而且可以确保先后顺序,不必像MySQL那样还需要通过ORDER BY来进行排序。
2.利用LRANGE还可以很方便的实现分页的功能。

3.在博客系统中,每片博文的评论也可以存入一个单独的list中。


相关命令

命令原型	                   时间复杂度		返回值
LPUSHkey value [value ...] 	    O(1)	         插入后链表中元素的数量。
        在指定Key所关联的List Value的头部插入参数中给出的所有Values。
        如果该Key不存在,该命令将在插入之前创建一个与该Key关联的空链表,之后再将数据从链表的头部插入。
        如果该键的Value不是链表类型,该命令将返回相关的错误信息。 	
LPUSHX key value 	            O(1)  	         插入后链表中元素的数量。 
        仅有当参数中指定的Key存在时,该命令才会在其所关联的List Value的头部插入参数中给出的Value,否则将不会有任何操作发生。	
LRANGE key start stop 	        O(S+N)	         返回指定范围内元素的列表。
        时间复杂度中的S为start参数表示的偏移量,N表示元素的数量。
        该命令的参数start和end都是0-based。即0表示链表头部(leftmost)的第一个元素。
        其中start的值也可以为负值,-1将表示链表中的最后一个元素,即尾部元素,-2表示倒数第二个并以此类推。
        该命令在获取元素时,start和end位置上的元素也会被取出。如果start的值大于链表中元素的数量,空链表将会被返回。
        如果end的值大于元素的数量,该命令则获取从start(包括start)开始,链表中剩余的所有元素。	
LPOPkey 	O(1) 	    如果该Key不存,返回nil。	链表头部的元素。
        返回并弹出指定Key关联的链表中的第一个元素,即头部元素。
LLENkey	O(1) 	       链表中元素的数量。
        返回指定Key关联的链表中元素的数量,如果该Key不存在,则返回0。
        如果与该Key关联的Value的类型不是链表,则返回相关的错误信息。	
LREMkey count value 	O(N) 	       返回被删除的元素数量。
        时间复杂度中N表示链表中元素的数量。在指定Key关联的链表中,删除前count个值等于value的元素。
        如果count大于0,从头向尾遍历并删除,如果count小于0,则从尾向头遍历并删除。
        如果count等于0,则删除链表中所有等于value的元素。如果指定的Key不存在,则直接返回0。	
LSETkey index value 	O(N) 	
        时间复杂度中N表示链表中元素的数量。但是设定头部或尾部的元素时,其时间复杂度为O(1)。
        设定链表中指定位置的值为新值,其中0表示第一个元素,即头部元素,-1表示尾部元素。
        如果索引值Index超出了链表中元素的数量范围,该命令将返回相关的错误信息。	 
LINDEX key index 	O(N) 	                  返回请求的元素,如果index超出范围,则返回nil。
        时间复杂度中N表示在找到该元素时需要遍历的元素数量。对于头部或尾部元素,其时间复杂度为O(1)。
        该命令将返回链表中指定位置(index)的元素,index是0-based,表示头部元素,如果index为-1,表示尾部元素。
        如果与该Key关联的不是链表,该命令将返回相关的错误信息。	
LTRIMkey start stop 	O(N) 	
        N表示被删除的元素数量。该命令将仅保留指定范围内的元素,从而保证链接中的元素数量相对恒定。
        start和stop参数都是0-based,0表示头部元素。和其他命令一样,start和stop也可以为负值,-1表示尾部元素。
        如果start大于链表的尾部,或start大于stop,该命令不错报错,而是返回一个空的链表,与此同时该Key也将被删除。
        如果stop大于元素的数量,则保留从start开始剩余的所有元素。	 
LINSERT key BEFORE|AFTER pivot value 	O(N) 	 成功插入后链表中元素的数量,如果没有找到pivot,返回-1,如果key不存在,返回0。
        时间复杂度中N表示在找到该元素pivot之前需要遍历的元素数量。
        这样意味着如果pivot位于链表的头部或尾部时,该命令的时间复杂度为O(1)。
        该命令的功能是在pivot元素的前面或后面插入参数中的元素value。如果Key不存在,该命令将不执行任何操作。
        如果与Key关联的Value类型不是链表,相关的错误信息将被返回。	
RPUSH key value [value ...] 	O(1) 	       插入后链表中元素的数量。 
        在指定Key所关联的List Value的尾部插入参数中给出的所有Values。
        如果该Key不存在,该命令将在插入之前创建一个与该Key关联的空链表,之后再将数据从链表的尾部插入。
        如果该键的Value不是链表类型,该命令将返回相关的错误信息。 	
RPUSHX key value 	O(1) 	       插入后链表中元素的数量。 
        仅有当参数中指定的Key存在时,该命令才会在其所关联的List Value的尾部插入参数中给出的Value,否则将不会有任何操作发生。 	
RPOPkey 	                O(1) 	       如果该Key不存,返回nil。 	链表尾部的元素。 
        返回并弹出指定Key关联的链表中的最后一个元素,即尾部元素。
RPOPLPUSHsource destination 	O(1) 	   返回弹出和插入的元素。
        原子性的从与source键关联的链表尾部弹出一个元素,同时再将弹出的元素插入到与destination键关联的链表的头部。
        如果source键不存在,该命令将返回nil,同时不再做任何其它的操作了。
        如果source和destination是同一个键,则相当于原子性的将其关联链表中的尾部元素移到该链表的头部。	

命令示例

1. LPUSH/LPUSHX/LRANGE:
	
    /> redis-cli    #在Shell提示符下启动redis客户端工具。
    redis 127.0.0.1:6379> del mykey
    (integer) 1
    #mykey键并不存在,该命令会创建该键及与其关联的List,之后在将参数中的values从左到右依次插入。
    redis 127.0.0.1:6379> lpush mykey a b c d
    (integer) 4
    #取从位置0开始到位置2结束的3个元素。
    redis 127.0.0.1:6379> lrange mykey 0 2
    1) "d"
    2) "c"
    3) "b"
    #取链表中的全部元素,其中0表示第一个元素,-1表示最后一个元素。
    redis 127.0.0.1:6379> lrange mykey 0 -1
    1) "d"
    2) "c"
    3) "b"
    4) "a"
    #mykey2键此时并不存在,因此该命令将不会进行任何操作,其返回值为0。
    redis 127.0.0.1:6379> lpushx mykey2 e
    (integer) 0
    #可以看到mykey2没有关联任何List Value。
    redis 127.0.0.1:6379> lrange mykey2 0 -1
    (empty list or set)
    #mykey键此时已经存在,所以该命令插入成功,并返回链表中当前元素的数量。
    redis 127.0.0.1:6379> lpushx mykey e
    (integer) 5
    #获取该键的List Value的头部元素。
    redis 127.0.0.1:6379> lrange mykey 0 0
    1) "e"

2. LPOP/LLEN:
	
    redis 127.0.0.1:6379> lpush mykey a b c d
    (integer) 4
    redis 127.0.0.1:6379> lpop mykey
    "d"
    redis 127.0.0.1:6379> lpop mykey
    "c"
    #在执行lpop命令两次后,链表头部的两个元素已经被弹出,此时链表中元素的数量是2
    redis 127.0.0.1:6379> llen mykey
    (integer) 2

3. LREM/LSET/LINDEX/LTRIM:
 
    #为后面的示例准备测试数据。
    redis 127.0.0.1:6379> lpush mykey a b c d a c
    (integer) 6
    #从头部(left)向尾部(right)变量链表,删除2个值等于a的元素,返回值为实际删除的数量。
    redis 127.0.0.1:6379> lrem mykey 2 a
    (integer) 2
    #看出删除后链表中的全部元素。
    redis 127.0.0.1:6379> lrange mykey 0 -1
    1) "c"
    2) "d"
    3) "c"
    4) "b"
    #获取索引值为1(头部的第二个元素)的元素值。
    redis 127.0.0.1:6379> lindex mykey 1
    "d"
    #将索引值为1(头部的第二个元素)的元素值设置为新值e。
    redis 127.0.0.1:6379> lset mykey 1 e
    OK
    #查看是否设置成功。
    redis 127.0.0.1:6379> lindex mykey 1
    "e"
    #索引值6超过了链表中元素的数量,该命令返回nil。
    redis 127.0.0.1:6379> lindex mykey 6
    (nil)
    #设置的索引值6超过了链表中元素的数量,设置失败,该命令返回错误信息。
    redis 127.0.0.1:6379> lset mykey 6 hh
    (error) ERR index out of range
    #仅保留索引值0到2之间的3个元素,注意第0个和第2个元素均被保留。
    redis 127.0.0.1:6379> ltrim mykey 0 2
    OK
    #查看trim后的结果。
    redis 127.0.0.1:6379> lrange mykey 0 -1
    1) "c"
    2) "e"
    3) "c"

4. LINSERT:

    #删除该键便于后面的测试。
    redis 127.0.0.1:6379> del mykey
    (integer) 1
    #为后面的示例准备测试数据。
    redis 127.0.0.1:6379> lpush mykey a b c d e
    (integer) 5
    #在a的前面插入新元素a1。
    redis 127.0.0.1:6379> linsert mykey before a a1
    (integer) 6
    #查看是否插入成功,从结果看已经插入。注意lindex的index值是0-based。
    redis 127.0.0.1:6379> lindex mykey 0
    "e"
    #在e的后面插入新元素e2,从返回结果看已经插入成功。
    redis 127.0.0.1:6379> linsert mykey after e e2
    (integer) 7
    #再次查看是否插入成功。
    redis 127.0.0.1:6379> lindex mykey 1
    "e2"
    #在不存在的元素之前或之后插入新元素,该命令操作失败,并返回-1。
    redis 127.0.0.1:6379> linsert mykey after k a
    (integer) -1
    #为不存在的Key插入新元素,该命令操作失败,返回0。
    redis 127.0.0.1:6379> linsert mykey1 after a a2
    (integer) 0

5. RPUSH/RPUSHX/RPOP/RPOPLPUSH:

    #删除该键,以便于后面的测试。
    redis 127.0.0.1:6379> del mykey
    (integer) 1
    #从链表的尾部插入参数中给出的values,插入顺序是从左到右依次插入。
    redis 127.0.0.1:6379> rpush mykey a b c d
    (integer) 4
    #通过lrange的可以获悉rpush在插入多值时的插入顺序。
    redis 127.0.0.1:6379> lrange mykey 0 -1
    1) "a"
    2) "b"
    3) "c"
    4) "d"
    #该键已经存在并且包含4个元素,rpushx命令将执行成功,并将元素e插入到链表的尾部。
    redis 127.0.0.1:6379> rpushx mykey e
    (integer) 5
    #通过lindex命令可以看出之前的rpushx命令确实执行成功,因为索引值为4的元素已经是新元素了。
    redis 127.0.0.1:6379> lindex mykey 4
    "e"
    #由于mykey2键并不存在,因此该命令不会插入数据,其返回值为0。
    redis 127.0.0.1:6379> rpushx mykey2 e
    (integer) 0
    #在执行rpoplpush命令前,先看一下mykey中链表的元素有哪些,注意他们的位置关系。
    redis 127.0.0.1:6379> lrange mykey 0 -1
    1) "a"
    2) "b"
    3) "c"
    4) "d"
    5) "e"
    #将mykey的尾部元素e弹出,同时再插入到mykey2的头部(原子性的完成这两步操作)。
    redis 127.0.0.1:6379> rpoplpush mykey mykey2
    "e"
    #通过lrange命令查看mykey在弹出尾部元素后的结果。
    redis 127.0.0.1:6379> lrange mykey 0 -1
    1) "a"
    2) "b"
    3) "c"
    4) "d"
    #通过lrange命令查看mykey2在插入元素后的结果。
    redis 127.0.0.1:6379> lrange mykey2 0 -1
    1) "e"
    #将source和destination设为同一键,将mykey中的尾部元素移到其头部。
    redis 127.0.0.1:6379> rpoplpush mykey mykey
    "d"
    #查看移动结果。
    redis 127.0.0.1:6379> lrange mykey 0 -1
    1) "d"
    2) "a"
    3) "b"
    4) "c"

链表结构的小技巧:

针对链表结构的Value,Redis在其官方文档中给出了一些实用技巧,如RPOPLPUSH命令,下面给出具体的解释。
Redis链表经常会被用于消息队列的服务,以完成多程序之间的消息交换。假设一个应用程序正在执行LPUSH操作向链表中添加新的元素,我们通常将这样的程序称之为"生产者(Producer)",而另外一个应用程序正在执行RPOP操作从链表中取出元素,我们称这样的程序为"消费者(Consumer)"。如果此时,消费者程序在取出消息元素后立刻崩溃,由于该消息已经被取出且没有被正常处理,那么我们就可以认为该消息已经丢失,由此可能会导致业务数据丢失,或业务状态的不一致等现象的发生。然而通过使RPOPLPUSH命令,消费者程序在从主消息队列中取出消息之后再将其插入到备份队列中,直到消费者程序完成正常的处理逻辑后再将该消息从备份队列中删除。同时我们还可以提供一个守护进程,当发现备份队列中的消息过期时,可以重新将其再放回到主消息队列中,以便其它的消费者程序继续处理。


redis数据结构 – 集合


在Redis中,我们可以将Set类型看作为没有排序的字符集合,和List类型一样,我们也可以在该类型的数据值上执行添加、删除或判断某一元素是否存在等操作。需要说明的是,这些操作的时间复杂度为O(1),即常量时间内完成次操作。Set可包含的最大元素数量是4294967295。
和List类型不同的是,Set集合中不允许出现重复的元素,这一点和C++标准库中的set容器是完全相同的。换句话说,如果多次添加相同元素,Set中将仅保留该元素的一份拷贝。和List类型相比,Set类型在功能上还存在着一个非常重要的特性,即在服务器端完成多个Sets之间的聚合计算操作,如unions、intersections和differences。由于这些操作均在服务端完成,因此效率极高,而且也节省了大量的网络IO开销。

redis的集合,是一种无序的集合,集合中的元素没有先后顺序。
集合相关的操作也很丰富,如添加新元素、删除已有元素、取交集、取并集、取差集等。我们来看例子:

//向集合myset中加入一个新元素"one"
127.0.0.1:6379> sadd myset "one" 
(integer) 1
127.0.0.1:6379> sadd myset "two"
(integer) 1
//列出集合myset中的所有元素
127.0.0.1:6379> smembers myset 
1) "one"
2) "two"
//判断元素1是否在集合myset中,返回1表示存在
127.0.0.1:6379> sismember myset "one" 
(integer) 1
//判断元素3是否在集合myset中,返回0表示不存在
127.0.0.1:6379> sismember myset "three" 
(integer) 0
//新建一个新的集合yourset
127.0.0.1:6379> sadd yourset "1" 
(integer) 1
127.0.0.1:6379> sadd yourset "2"
(integer) 1
127.0.0.1:6379> smembers yourset
1) "1"
2) "2"
//对两个集合求并集
127.0.0.1:6379> sunion myset yourset 
1) "1"
2) "one"
3) "2"
4) "two"

对于集合的使用,也有一些常见的方式,比如,QQ有一个社交功能叫做“好友标签”,大家可以给你的好友贴标签,比如“大美女”、“土豪”、“欧巴”等等,这时就可以使用redis的集合来实现,把每一个用户的标签都存储在一个集合之中。


相关命令

命令原型	                   时间复杂度           	返回值
SADDkey member [member ...]	      O(N)	               本次操作实际插入的成员数量。
        时间复杂度中的N表示操作的成员数量。
        如果在插入的过程用,参数中有的成员在Set中已经存在,该成员将被忽略,而其它成员仍将会被正常插入。
        如果执行该命令之前,该Key并不存在,该命令将会创建一个新的Set,此后再将参数中的成员陆续插入。
        如果该Key的Value不是Set类型,该命令将返回相关的错误信息。	
SCARDkey	                     O(1)	               返回Set中成员的数量,如果该Key并不存在,返回0。
        获取Set中成员的数量。
SISMEMBER key member	         O(1)	               1表示已经存在,0表示不存在,或该Key本身并不存在。
        判断参数中指定成员是否已经存在于与Key相关联的Set集合中。	
SMEMBERS key	                 O(N)	               返回Set中所有的成员。
        时间复杂度中的N表示Set中已经存在的成员数量。获取与该Key关联的Set中所有的成员。	
SPOPkey 	                     O(1) 	               返回移除的成员,如果该Key并不存在,则返回nil。
        随机的移除并返回Set中的某一成员。 
        由于Set中元素的布局不受外部控制,因此无法像List那样确定哪个元素位于Set的头部或者尾部。	

SREMkey member [member ...]	     O(N) 	               从Set中实际移除的成员数量,如果没有则返回0。
        时间复杂度中的N表示被删除的成员数量。
        从与Key关联的Set中删除参数中指定的成员,不存在的参数成员将被忽略,如果该Key并不存在,将视为空Set处理。	

SRANDMEMBER key 	             O(1) 	               返回随机位置的成员,如果Key不存在则返回nil。
        和SPOP一样,随机的返回Set中的一个成员,不同的是该命令并不会删除返回的成员。	
SMOVEsource destination member	 O(1) 	               1表示正常移动,0表示source中并不包含参数成员。
        原子性的将参数中的成员从source键移入到destination键所关联的Set中。
        因此在某一时刻,该成员或者出现在source中,或者出现在destination中。
        如果该成员在source中并不存在,该命令将不会再执行任何操作并返回0,
        否则,该成员将从source移入到destination。
        如果此时该成员已经在destination中存在,那么该命令仅是将该成员从source中移出。
        如果和Key关联的Value不是Set,将返回相关的错误信息。	
SDIFFkey [key ...]	             O(N)                  差异结果成员的集合。	      
        时间复杂度中的N表示所有Sets中成员的总数量。返回参数中第一个Key所关联的Set和其后所有Keys所关联的Sets中成员的差异。
        如果Key不存在,则视为空Set。	
SDIFFSTOREdestination key [key ...] 	O(N)           返回差异成员的数量。	
        该命令和SDIFF命令在功能上完全相同。
        两者之间唯一的差别是SDIFF返回差异的结果成员,而该命令将差异成员存储在destination关联的Set中。
        如果destination键已经存在,该操作将覆盖它的成员。
        两者之间唯一的差别是SDIFF返回差异的结果成员,而该命令将差异成员存储在destination关联的Set中。
        如果destination键已经存在,该操作将覆盖它的成员。	
SINTERkey [key ...] 	                O(N*M) 	        交集结果成员的集合。
        时间复杂度中的N表示最小Set中元素的数量,M则表示参数中Sets的数量。该命令将返回参数中所有Keys关联的Sets中成员的交集。
        因此如果参数中任何一个Key关联的Set为空,或某一Key不存在,那么该命令的结果将为空集。	
SINTERSTOREdestination key [key ...]	O(N*M) 	        返回交集成员的数量。 
        该命令和SINTER命令在功能上完全相同,两者之间唯一的差别是SINTER返回交集的结果成员,
        而该命令将交集成员存储在destination关联的Set中。如果destination键已经存在,该操作将覆盖它的成员。	
SUNION key [key ...] 	                O(N)	        并集结果成员的集合。
        时间复杂度中的N表示所有Sets中成员的总数量。该命令将返回参数中所有Keys关联的Sets中成员的并集。	
SUNIONSTOREdestination key [key ...] 	O(N) 	        返回并集成员的数量。
        该命令和SUNION命令在功能上完全相同,两者之间唯一的差别是SUNION返回并集的结果成员,
        而该命令将并集成员存储在destination关联的Set中。如果destination键已经存在,该操作将覆盖它的成员。 

命令示例

1. SADD/SMEMBERS/SCARD/SISMEMBER:
    #在Shell命令行下启动Redis的客户端程序。
    /> redis-cli
    #插入测试数据,由于该键myset之前并不存在,因此参数中的三个成员都被正常插入。
    redis 127.0.0.1:6379> sadd myset a b c
    (integer) 3
    #由于参数中的a在myset中已经存在,因此本次操作仅仅插入了d和e两个新成员。
    redis 127.0.0.1:6379> sadd myset a d e
    (integer) 2
    #判断a是否已经存在,返回值为1表示存在。
    redis 127.0.0.1:6379> sismember myset a
    (integer) 1
    #判断f是否已经存在,返回值为0表示不存在。
    redis 127.0.0.1:6379> sismember myset f
    (integer) 0
    #通过smembers命令查看插入的结果,从结果可以,输出的顺序和插入顺序无关。
    redis 127.0.0.1:6379> smembers myset
    1) "c"
    2) "d"
    3) "a"
    4) "b"
    5) "e"
    #获取Set集合中元素的数量。
    redis 127.0.0.1:6379> scard myset
    (integer) 5

2. SPOP/SREM/SRANDMEMBER/SMOVE:
    #删除该键,便于后面的测试。
    redis 127.0.0.1:6379> del myset
    (integer) 1
    #为后面的示例准备测试数据。
    redis 127.0.0.1:6379> sadd myset a b c d
    (integer) 4
    #查看Set中成员的位置。
    redis 127.0.0.1:6379> smembers myset
    1) "c"
    2) "d"
    3) "a"
    4) "b"
    #从结果可以看出,该命令确实是随机的返回了某一成员。
    redis 127.0.0.1:6379> srandmember myset
    "c"
    #Set中尾部的成员b被移出并返回,事实上b并不是之前插入的第一个或最后一个成员。
    redis 127.0.0.1:6379> spop myset
    "b"
    #查看移出后Set的成员信息。
    redis 127.0.0.1:6379> smembers myset
    1) "c"
    2) "d"
    3) "a"
    #从Set中移出a、d和f三个成员,其中f并不存在,因此只有a和d两个成员被移出,返回为2。
    redis 127.0.0.1:6379> srem myset a d f
    (integer) 2
    #查看移出后的输出结果。
    redis 127.0.0.1:6379> smembers myset
    1) "c"
    #为后面的smove命令准备数据。
    redis 127.0.0.1:6379> sadd myset a b
    (integer) 2
    redis 127.0.0.1:6379> sadd myset2 c d
    (integer) 2
    #将a从myset移到myset2,从结果可以看出移动成功。
    redis 127.0.0.1:6379> smove myset myset2 a
    (integer) 1
    #再次将a从myset移到myset2,由于此时a已经不是myset的成员了,因此移动失败并返回0。
    redis 127.0.0.1:6379> smove myset myset2 a
    (integer) 0
    #分别查看myset和myset2的成员,确认移动是否真的成功。
    redis 127.0.0.1:6379> smembers myset
    1) "b"
    redis 127.0.0.1:6379> smembers myset2
    1) "c"
    2) "d"
    3) "a"

3. SDIFF/SDIFFSTORE/SINTER/SINTERSTORE:
    #为后面的命令准备测试数据。
    redis 127.0.0.1:6379> sadd myset a b c d
    (integer) 4
    redis 127.0.0.1:6379> sadd myset2 c
    (integer) 1
    redis 127.0.0.1:6379> sadd myset3 a c e
    (integer) 3
    #myset和myset2相比,a、b和d三个成员是两者之间的差异成员。再用这个结果继续和myset3进行差异比较,b和d是myset3不存在的成员。
    redis 127.0.0.1:6379> sdiff myset myset2 myset3
    1) "d"
    2) "b"
    #将3个集合的差异成员存在在diffkey关联的Set中,并返回插入的成员数量。
    redis 127.0.0.1:6379> sdiffstore diffkey myset myset2 myset3
    (integer) 2
    #查看一下sdiffstore的操作结果。
    redis 127.0.0.1:6379> smembers diffkey
    1) "d"
    2) "b"
    #从之前准备的数据就可以看出,这三个Set的成员交集只有c。
    redis 127.0.0.1:6379> sinter myset myset2 myset3
    1) "c"
    #将3个集合中的交集成员存储到与interkey关联的Set中,并返回交集成员的数量。
    redis 127.0.0.1:6379> sinterstore interkey myset myset2 myset3
    (integer) 1
    #查看一下sinterstore的操作结果。
    redis 127.0.0.1:6379> smembers interkey
    1) "c"
    #获取3个集合中的成员的并集。    
    redis 127.0.0.1:6379> sunion myset myset2 myset3
    1) "b"
    2) "c"
    3) "d"
    4) "e"
    5) "a"
    #将3个集合中成员的并集存储到unionkey关联的set中,并返回并集成员的数量。
    redis 127.0.0.1:6379> sunionstore unionkey myset myset2 myset3
    (integer) 5
    #查看一下suiionstore的操作结果。
    redis 127.0.0.1:6379> smembers unionkey
    1) "b"
    2) "c"
    3) "d"
    4) "e"
    5) "a"

应用范围:
1). 可以使用Redis的Set数据类型跟踪一些唯一性数据,比如访问某一博客的唯一IP地址信息。对于此场景,我们仅需在每次访问该博客时将访问者的IP存入Redis中,Set数据类型会自动保证IP地址的唯一性。
2). 充分利用Set类型的服务端聚合操作方便、高效的特性,可以用于维护数据对象之间的关联关系。比如所有购买某一电子设备的客户ID被存储在一个指定的Set中,而购买另外一种电子产品的客户ID被存储在另外一个Set中,如果此时我们想获取有哪些客户同时购买了这两种商品时,Set的intersections命令就可以充分发挥它的方便和效率的优势了。


redis数据结构 – 有序集合


Sorted-Sets 和 Sets 类型极为相似,它们都是字符串的集合,都不允许重复的成员出现在一个Set中。它们之间的主要差别是Sorted-Sets中的每一个成员都会有一个分数(score)与之关联,Redis正是通过分数来为集合中的成员进行从小到大的排序。然而需要额外指出的是,尽管Sorted-Sets中的成员必须是唯一的,但是分数(score)却是可以重复的。
在Sorted-Set中添加、删除或更新一个成员都是非常快速的操作,其时间复杂度为集合中成员数量的对数。由于Sorted-Sets中的成员在集合中的位置是有序的,因此,即便是访问位于集合中部的成员也仍然是非常高效的。事实上,Redis所具有的这一特征在很多其它类型的数据库中是很难实现的,换句话说,在该点上要想达到和Redis同样的高效,在其它数据库中进行建模是非常困难的。

redis不但提供了无需集合(sets),还很体贴的提供了有序集合(sorted sets)。有序集合中的每个元素都关联一个序号(score),这便是排序的依据。
很多时候,我们都将redis中的有序集合叫做zsets,这是因为在redis中,有序集合相关的操作指令都是以z开头的,比如zrange、zadd、zrevrange、zrangebyscore等等
老规矩,我们来看几个生动的例子:
//新增一个有序集合myzset,并加入一个元素baidu.com,给它赋予的序号是1:

127.0.0.1:6379> zadd myzset 1 baidu.com 
(integer) 1
//向myzset中新增一个元素360.com,赋予它的序号是3
127.0.0.1:6379> zadd myzset 3 360.com 
(integer) 1
//向myzset中新增一个元素google.com,赋予它的序号是2
127.0.0.1:6379> zadd myzset 2 google.com 
(integer) 1
//列出myzset的所有元素,同时列出其序号,可以看出myzset已经是有序的了。
127.0.0.1:6379> zrange myzset 0 -1 with scores 
1) "baidu.com"
2) "1"
3) "google.com"
4) "2"
5) "360.com"
6) "3"
//只列出myzset的元素
127.0.0.1:6379> zrange myzset 0 -1 
1) "baidu.com"
2) "google.com"
3) "360.com"

相关命令

命令原型	                           时间复杂度            返回值
ZADD key score member [score] [member] 	    O(log(N))	           本次操作实际插入的成员数量。
        时间复杂度中的N表示Sorted-Sets中成员的数量。
        添加参数中指定的所有成员及其分数到指定key的Sorted-Set中,
        在该命令中我们可以指定多组score/member作为参数。
        如果在添加时参数中的某一成员已经存在,该命令将更新此成员的分数为新值,同时再将该成员基于新值重新排序。
        如果键不存在,该命令将为该键创建一个新的Sorted-Sets Value,并将score/member对插入其中。
        如果该键已经存在,但是与其关联的Value不是Sorted-Sets类型,相关的错误信息将被返回。	
ZCARD key 	O(1)	                                          返回Sorted-Sets中的成员数量,如果该Key不存在,返回0。
        获取与该Key相关联的Sorted-Sets中包含的成员数量。	
ZCOUNTkey min max	                    O(log(N)+M) 	      分数指定范围内成员的数量。
        时间复杂度中的N表示Sorted-Sets中成员的数量,M则表示min和max之间元素的数量。
        该命令用于获取分数(score)在min和max之间的成员数量。
        针对min和max参数需要额外说明的是,-inf和+inf分别表示Sorted-Sets中分数的最高值和最低值。
        缺省情况下,min和max表示的范围是闭区间范围,即min <= score <= max内的成员将被返回。
        然而我们可以通过在min和max的前面添加"("字符来表示开区间,如(min max表示min < score <= max,
        而(min (max表示min < score < max。	
ZINCRBYkey increment member 	O(log(N))	                   以字符串形式表示的新分数。
        时间复杂度中的N表示Sorted-Sets中成员的数量。
        该命令将为指定Key中的指定成员增加指定的分数。
        如果成员不存在,该命令将添加该成员并假设其初始分数为0,此后再将其分数加上increment。
        如果Key不存,该命令将创建该Key及其关联的Sorted-Sets,并包含参数指定的成员,其分数为increment参数。
        如果与该Key关联的不是Sorted-Sets类型,相关的错误信息将被返回。	
ZRANGEkey start stop [WITHSCORES] 	O(log(N)+M)	                返回索引在start和stop之间的成员列表。
        时间复杂度中的N表示Sorted-Set中成员的数量,M则表示返回的成员数量。
        该命令返回顺序在参数start和stop指定范围内的成员,这里start和stop参数都是0-based,即0表示第一个成员,-1表示最后一个成员。
        如果start大于该Sorted-Set中的最大索引值,或start > stop,此时一个空集合将被返回。
        如果stop大于最大索引值,该命令将返回从start到集合的最后一个成员。
        如果命令中带有可选参数WITHSCORES选项,该命令在返回的结果中将包含每个成员的分数值,如value1,score1,value2,score2...。  	       
ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count] 	O(log(N)+M)	   返回分数在指定范围内的成员列表。
        时间复杂度中的N表示Sorted-Set中成员的数量,M则表示返回的成员数量。
        该命令将返回分数在min和max之间的所有成员,即满足表达式min <= score <= max的成员,
        其中返回的成员是按照其分数从低到高的顺序返回,如果成员具有相同的分数,则按成员的字典顺序返回。
        可选参数LIMIT用于限制返回成员的数量范围。
        可选参数offset表示从符合条件的第offset个成员开始返回,同时返回count个成员。
        可选参数WITHSCORES的含义参照ZRANGE中该选项的说明。最后需要说明的是参数中min和max的规则可参照命令ZCOUNT。	
ZRANK key member 	O(log(N))  	      如果该成员存在,则返回它的位置索引值。否则返回nil。
        时间复杂度中的N表示Sorted-Set中成员的数量。
Sorted-Set中的成员都是按照分数从低到高的顺序存储,该命令将返回参数中指定成员的位置值,
        其中0表示第一个成员,它是Sorted-Set中分数最低的成员。	
ZREM key member [member ...]	O(M log(N))	        实际被删除的成员数量。
        时间复杂度中N表示Sorted-Set中成员的数量,M则表示被删除的成员数量。
        该命令将移除参数中指定的成员,其中不存在的成员将被忽略。
        如果与该Key关联的Value不是Sorted-Set,相应的错误信息将被返回。	
ZREVRANGE key startstop[WITHSCORES]  	O(log(N)+M) 	    返回指定的成员列表。
        时间复杂度中的N表示Sorted-Set中成员的数量,M则表示返回的成员数量。
        该命令的功能和ZRANGE基本相同,唯一的差别在于该命令是通过反向排序获取指定位置的成员,即从高到低的顺序。
        如果成员具有相同的分数,则按降序字典顺序排序。	
ZREVRANKkey member 	O(log(N))	           如果该成员存在,则返回它的位置索引值。否则返回nil。 
        时间复杂度中的N表示Sorted-Set中成员的数量。该命令的功能和ZRANK基本相同,
        唯一的差别在于该命令获取的索引是从高到低排序后的位置,同样0表示第一个元素,即分数最高的成员。	
ZSCOREkey member	O(1)	   如果该成员存在,以字符串的形式返回其分数,否则返回nil。
        获取指定Key的指定成员的分数。	
ZREVRANGEBYSCOREkey max min [WITHSCORES] [LIMIT offset count] 	O(log(N)+M) 	 返回分数在指定范围内的成员列表。 
        时间复杂度中的N表示Sorted-Set中成员的数量,M则表示返回的成员数量。
        该命令除了排序方式是基于从高到低的分数排序之外,其它功能和参数含义均与ZRANGEBYSCORE相同。	
ZREMRANGEBYRANKkey start stop 	O(log(N)+M)	              被删除的成员数量。
        时间复杂度中的N表示Sorted-Set中成员的数量,M则表示被删除的成员数量。
        删除索引位置位于start和stop之间的成员,start和stop都是0-based,即0表示分数最低的成员,-1表示最后一个成员,即分数最高的成员。  	
ZREMRANGEBYSCOREkey min max 	O(log(N)+M)	 被删除的成员数量。
        时间复杂度中的N表示Sorted-Set中成员的数量,M则表示被删除的成员数量。
        删除分数在min和max之间的所有成员,即满足表达式min <= score <= max的所有成员。
        对于min和max参数,可以采用开区间的方式表示,具体规则参照ZCOUNT。 

命令示例

1. ZADD/ZCARD/ZCOUNT/ZREM/ZINCRBY/ZSCORE/ZRANGE/ZRANK:
    #在Shell的命令行下启动Redis客户端工具。
    /> redis-cli
    #添加一个分数为1的成员。
    redis 127.0.0.1:6379> zadd myzset 1 "one"
    (integer) 1
    #添加两个分数分别是2和3的两个成员。
    redis 127.0.0.1:6379> zadd myzset 2 "two" 3 "three"
    (integer) 2
    #0表示第一个成员,-1表示最后一个成员。WITHSCORES选项表示返回的结果中包含每个成员及其分数,否则只返回成员。
    redis 127.0.0.1:6379> zrange myzset 0 -1 WITHSCORES
    1) "one"
    2) "1"
    3) "two"
    4) "2"
    5) "three"
    6) "3"
    #获取成员one在Sorted-Set中的位置索引值。0表示第一个位置。
    redis 127.0.0.1:6379> zrank myzset one
    (integer) 0
    #成员four并不存在,因此返回nil。
    redis 127.0.0.1:6379> zrank myzset four
    (nil)
    #获取myzset键中成员的数量。    
    redis 127.0.0.1:6379> zcard myzset
    (integer) 3
    #返回与myzset关联的Sorted-Set中,分数满足表达式1 <= score <= 2的成员的数量。
    redis 127.0.0.1:6379> zcount myzset 1 2
    (integer) 2
    #删除成员one和two,返回实际删除成员的数量。
    redis 127.0.0.1:6379> zrem myzset one two
    (integer) 2
    #查看是否删除成功。
    redis 127.0.0.1:6379> zcard myzset
    (integer) 1
    #获取成员three的分数。返回值是字符串形式。
    redis 127.0.0.1:6379> zscore myzset three
    "3"
    #由于成员two已经被删除,所以该命令返回nil。
    redis 127.0.0.1:6379> zscore myzset two
    (nil)
    #将成员one的分数增加2,并返回该成员更新后的分数。
    redis 127.0.0.1:6379> zincrby myzset 2 one
    "3"
    #将成员one的分数增加-1,并返回该成员更新后的分数。
    redis 127.0.0.1:6379> zincrby myzset -1 one
    "2"
    #查看在更新了成员的分数后是否正确。
    redis 127.0.0.1:6379> zrange myzset 0 -1 WITHSCORES
    1) "one"
    2) "2"
    3) "two"
    4) "2"
    5) "three"
    6) "3"

2. ZRANGEBYSCORE/ZREMRANGEBYRANK/ZREMRANGEBYSCORE
    redis 127.0.0.1:6379> del myzset
    (integer) 1
    redis 127.0.0.1:6379> zadd myzset 1 one 2 two 3 three 4 four
    (integer) 4
    #获取分数满足表达式1 <= score <= 2的成员。
    redis 127.0.0.1:6379> zrangebyscore myzset 1 2
    1) "one"
    2) "two"
    #获取分数满足表达式1 < score <= 2的成员。
    redis 127.0.0.1:6379> zrangebyscore myzset (1 2
    1) "two"
    #-inf表示第一个成员,+inf表示最后一个成员,limit后面的参数用于限制返回成员的自己,
    #2表示从位置索引(0-based)等于2的成员开始,去后面3个成员。
    redis 127.0.0.1:6379> zrangebyscore myzset -inf +inf limit 2 3
    1) "three"
    2) "four"
    #删除分数满足表达式1 <= score <= 2的成员,并返回实际删除的数量。
    redis 127.0.0.1:6379> zremrangebyscore myzset 1 2
    (integer) 2
    #看出一下上面的删除是否成功。
    redis 127.0.0.1:6379> zrange myzset 0 -1
    1) "three"
    2) "four"
    #删除位置索引满足表达式0 <= rank <= 1的成员。
    redis 127.0.0.1:6379> zremrangebyrank myzset 0 1
    (integer) 2
    #查看上一条命令是否删除成功。
    redis 127.0.0.1:6379> zcard myzset
    (integer) 0
 

3. ZREVRANGE/ZREVRANGEBYSCORE/ZREVRANK:
    #为后面的示例准备测试数据。
    redis 127.0.0.1:6379> del myzset
    (integer) 0
    redis 127.0.0.1:6379> zadd myzset 1 one 2 two 3 three 4 four
    (integer) 4
    #以位置索引从高到低的方式获取并返回此区间内的成员。
    redis 127.0.0.1:6379> zrevrange myzset 0 -1 WITHSCORES
    1) "four"
    2) "4"
    3) "three"
    4) "3"
    5) "two"
    6) "2"
    7) "one"
    8) "1"
    #由于是从高到低的排序,所以位置等于0的是four,1是three,并以此类推。
    redis 127.0.0.1:6379> zrevrange myzset 1 3
    1) "three"
    2) "two"
    3) "one"
    #由于是从高到低的排序,所以one的位置是3。
    redis 127.0.0.1:6379> zrevrank myzset one
    (integer) 3
    #由于是从高到低的排序,所以four的位置是0。
    redis 127.0.0.1:6379> zrevrank myzset four
    (integer) 0
    #获取分数满足表达式3 >= score >= 0的成员,并以相反的顺序输出,即从高到底的顺序。
    redis 127.0.0.1:6379> zrevrangebyscore myzset 3 0
    1) "three"
    2) "two"
    3) "one"
    #该命令支持limit选项,其含义等同于zrangebyscore中的该选项,只是在计算位置时按照相反的顺序计算和获取。
    redis 127.0.0.1:6379> zrevrangebyscore myzset 4 0 limit 1 2
    1) "three"
    2) "two"

应用范围:
1). 可以用于一个大型在线游戏的积分排行榜。每当玩家的分数发生变化时,可以执行ZADD命令更新玩家的分数,此后再通过ZRANGE命令获取积分TOP TEN的用户信息。当然我们也可以利用ZRANK命令通过username来获取玩家的排行信息。最后我们将组合使用ZRANGE和ZRANK命令快速的获取和某个玩家积分相近的其他用户的信息。
2). Sorted-Sets类型还可用于构建索引数据。


redis数据结构 – 哈希


最后要给大家介绍的是hashes,即哈希。哈希是从redis-2.0.0版本之后才有的数据结构。
hashes存的是字符串和字符串值之间的映射,比如一个用户要存储其全名、姓氏、年龄等等,就很适合使用哈希。

可以将Redis中的Hashes类型看成具有String Key和String Value的map 容器。所以该类型非常适合于存储值对象的信息。如Username、Password和Age等。如果Hash中包含很少的字段,那么该类型的数据也将仅占用很少的磁盘空间。每一个Hash可以存储4294967295个键值对。

看一个例子:

//建立哈希,并赋值
127.0.0.1:6379> HMSET user:001 username antirez password P1pp0 age 34 
OK
//列出哈希的内容
127.0.0.1:6379> HGETALL user:001 
1) "username"
2) "antirez"
3) "password"
4) "P1pp0"
5) "age"
6) "34"
//更改哈希中的某一个值
127.0.0.1:6379> HSET user:001 password 12345 
(integer) 0
//再次列出哈希的内容
127.0.0.1:6379> HGETALL user:001 
1) "username"
2) "antirez"
3) "password"
4) "12345"
5) "age"
6) "34"

有关hashes的操作,同样很丰富,需要时,大家可以从这里查询:https://redis.io/commands


相关命令

命令原型	          时间复杂度	             	返回值
HSET key field value	O(1)	                  1表示新的Field被设置了新值,0表示Field已经存在,用新值覆盖原有值。
        为指定的Key设定Field/Value对,如果Key不存在,该命令将创建新Key以参数中的Field/Value对,
        如果参数中的Field在该Key中已经存在,则用新值覆盖其原有值。 	 
HGET key field 	        O(1) 	                  返回参数中Field的关联值,如果参数中的Key或Field不存,返回nil。
        返回指定Key中指定Field的关联值。	
HEXISTSkey field 	    O(1) 	                  1表示存在,0表示参数中的Field或Key不存在。
        判断指定Key中的指定Field是否存在。	
HLEN key 	O(1)	                              返回Key包含的Field数量,如果Key不存在,返回0。
        获取该Key所包含的Field的数量。	
HDEL key field [field ...] 	O(N)	
        时间复杂度中的N表示参数中待删除的字段数量。从指定Key的Hashes Value中删除参数中指定的多个字段,如果不存在的字段将被忽略。
        如果Key不存在,则将其视为空Hashes,并返回0.	实际删除的Field数量。
HSETNXkey field value	    O(1)	              1表示新的Field被设置了新值,0表示Key或Field已经存在,该命令没有进行任何操作。
        只有当参数中的Key或Field不存在的情况下,为指定的Key设定Field/Value对,否则该命令不会进行任何操作。 	
HINCRBYkey field increment 	O(1)	              返回运算后的值。
        增加指定Key中指定Field关联的Value的值。
        如果Key或Field不存在,该命令将会创建一个新Key或新Field,并将其关联的Value初始化为0,之后再指定数字增加的操作。
        该命令支持的数字是64位有符号整型,即increment可以负数。 	
HGETALLkey	                O(N) 	              Field/Value的列表。
        时间复杂度中的N表示Key包含的Field数量。获取该键包含的所有Field/Value。
        其返回格式为一个Field、一个Value,并以此类推。	
HKEYSkey 	                O(N)	              返回指定Key的所有Fields名。	Field的列表。
        时间复杂度中的N表示Key包含的Field数量。
HVALSkey 	                O(N)	              Value的列表。 
        时间复杂度中的N表示Key包含的Field数量。返回指定Key的所有Values名。 	
HMGETkey field [field ...] 	O(N) 	
        时间复杂度中的N表示请求的Field数量。      返回和请求Fields关联的一组Values,其返回顺序等同于Fields的请求顺序。
        获取和参数中指定Fields关联的一组Values。如果请求的Field不存在,其值返回nil。
        如果Key不存在,该命令将其视为空Hash,因此返回一组nil。	
HMSET key field value [field value ...]	O(N)	
        时间复杂度中的N表示被设置的Field数量。逐对依次设置参数中给出的Field/Value对。
        如果其中某个Field已经存在,则用新值覆盖原有值。
        如果Key不存在,则创建新Key,同时设定参数中的Field/Value。  	 

命令示例

1. HSET/HGET/HDEL/HEXISTS/HLEN/HSETNX:
    #在Shell命令行启动Redis客户端程序
    /> redis-cli
    #给键值为myhash的键设置字段为field1,值为stephen。
    redis 127.0.0.1:6379> hset myhash field1 "stephen"
    (integer) 1
    #获取键值为myhash,字段为field1的值。
    redis 127.0.0.1:6379> hget myhash field1
    "stephen"
    #myhash键中不存在field2字段,因此返回nil。
    redis 127.0.0.1:6379> hget myhash field2
    (nil)
    #给myhash关联的Hashes值添加一个新的字段field2,其值为liu。
    redis 127.0.0.1:6379> hset myhash field2 "liu"
    (integer) 1
    #获取myhash键的字段数量。
    redis 127.0.0.1:6379> hlen myhash
    (integer) 2
    #判断myhash键中是否存在字段名为field1的字段,由于存在,返回值为1。
    redis 127.0.0.1:6379> hexists myhash field1
    (integer) 1
    #删除myhash键中字段名为field1的字段,删除成功返回1。
    redis 127.0.0.1:6379> hdel myhash field1
    (integer) 1
    #再次删除myhash键中字段名为field1的字段,由于上一条命令已经将其删除,因为没有删除,返回0。
    redis 127.0.0.1:6379> hdel myhash field1
    (integer) 0
    #判断myhash键中是否存在field1字段,由于上一条命令已经将其删除,因为返回0。
    redis 127.0.0.1:6379> hexists myhash field1
    (integer) 0
    #通过hsetnx命令给myhash添加新字段field1,其值为stephen,因为该字段已经被删除,所以该命令添加成功并返回1。
    redis 127.0.0.1:6379> hsetnx myhash field1 stephen
    (integer) 1
    #由于myhash的field1字段已经通过上一条命令添加成功,因为本条命令不做任何操作后返回0。
    redis 127.0.0.1:6379> hsetnx myhash field1 stephen
    (integer) 0

2. HINCRBY:
    #删除该键,便于后面示例的测试。
    redis 127.0.0.1:6379> del myhash
    (integer) 1
    #准备测试数据,该myhash的field字段设定值1。
    redis 127.0.0.1:6379> hset myhash field 5
    (integer) 1
    #给myhash的field字段的值加1,返回加后的结果。
    redis 127.0.0.1:6379> hincrby myhash field 1
    (integer) 6
    #给myhash的field字段的值加-1,返回加后的结果。
    redis 127.0.0.1:6379> hincrby myhash field -1
    (integer) 5
    #给myhash的field字段的值加-10,返回加后的结果。
    redis 127.0.0.1:6379> hincrby myhash field -10
    (integer) -5   

3. HGETALL/HKEYS/HVALS/HMGET/HMSET:
    #删除该键,便于后面示例测试。
    redis 127.0.0.1:6379> del myhash
    (integer) 1
    #为该键myhash,一次性设置多个字段,分别是field1 = "hello", field2 = "world"。
    redis 127.0.0.1:6379> hmset myhash field1 "hello" field2 "world"
    OK
    #获取myhash键的多个字段,其中field3并不存在,因为在返回结果中与该字段对应的值为nil。
    redis 127.0.0.1:6379> hmget myhash field1 field2 field3
    1) "hello"
    2) "world"
    3) (nil)
    #返回myhash键的所有字段及其值,从结果中可以看出,他们是逐对列出的。
    redis 127.0.0.1:6379> hgetall myhash
    1) "field1"
    2) "hello"
    3) "field2"
    4) "world"
    #仅获取myhash键中所有字段的名字。
    redis 127.0.0.1:6379> hkeys myhash
    1) "field1"
    2) "field2"
    #仅获取myhash键中所有字段的值。
    redis 127.0.0.1:6379> hvals myhash
    1) "hello"
    2) "world" 


Redis 持久化 详解


Redis 提供了两种持久化的方式:分别是RDB(Redis DataBase)和 AOF(Append Only File)。
RDB,简而言之,就是在不同的时间点,将redis存储的数据生成快照并存储到磁盘等介质上;
AOF,则是换了一个角度来实现持久化,那就是将redis执行过的所有写指令记录下来,在下次redis重新启动时,只要把这些写指令从前到后再重复执行一遍,就可以实现数据恢复了。
其实RDB和AOF两种方式也可以同时使用,在这种情况下,如果redis重启的话,则会优先采用AOF方式来进行数据恢复,这是因为AOF方式的数据恢复完整度更高。
如果你没有数据持久化的需求,也完全可以关闭RDB和AOF方式,这样的话,redis将变成一个纯内存数据库,就像memcache一样。

Redis提供的持久化机制:

  1. RDB持久化:
    该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
  2. AOF持久化:
    该机制将以日志的形式记录服务器所处理的每一个写操作,在Redis服务器启动之初会读取该文件来重新构建数据库,以保证启动后数据库中的数据是完整的。
  3. 无持久化:
    我们可以通过配置的方式禁用Redis服务器的持久化功能,这样我们就可以将Redis视为一个功能加强版的memcached了。
  4. 同时应用 AOF 和 RDB。


RDB机制的 优势 和 劣势

        RDB方式,是将redis某一时刻的数据持久化到磁盘中,是一种快照式的持久化方法。redis在进行数据持久化的过程中,会先将数据写入到一个临时文件中,待持久化过程都结束了,才会用这个临时文件替换上次持久化好的文件。正是这种特性,让我们可以随时来进行备份,因为快照文件总是完整可用的。
        对于RDB方式,redis会单独创建(fork)一个子进程来进行持久化,而主进程是不会进行任何IO操作的,这样就确保了redis极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。
        虽然RDB有不少优点,但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感,那么RDB方式就不太适合你,因为即使你每5分钟都持久化一次,当redis故障时,仍然会有近5分钟的数据丢失。所以,redis还提供了另一种持久化方式,那就是AOF。

    RDB 优势

  1. 一旦采用该方式,那么你的整个Redis数据库将只包含一个文件,这对于文件备份而言是非常完美的。比如,你可能打算每个小时归档一次最近24小时的数据,同时还要每天归档一次最近30天的数据。通过这样的备份策略,一旦系统出现灾难性故障,我们可以非常容易的进行恢复。
  2. 对于灾难恢复而言,RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
  3. 性能最大化。对于Redis的服务进程而言,在开始持久化时,它唯一需要做的只是fork出子进程,之后再由子进程完成这些持久化的工作,这样就可以极大的避免服务进程执行IO操作了。
  4. 相比于AOF机制,如果数据集很大,RDB的启动效率会更高。

    RDB 劣势

  1. 如果你想保证数据的高可用性,即最大限度的避免数据丢失,那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失。
  2. 由于RDB是通过fork子进程来协助完成数据持久化工作的,因此,如果当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟。


AOF机制的 优势 和 劣势

AOF,英文是Append Only File,即只允许追加不允许改写的文件。
如前面介绍的,AOF方式是将执行过的写指令记录下来,在数据恢复时按照从前到后的顺序再将指令都执行一遍,就这么简单。
我们通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作(如SET等),redis就会被追加到AOF文件的末尾。
默认的AOF持久化策略是每秒钟fsync一次(fsync是指把缓存中的写指令记录到磁盘中),因为在这种情况下,redis仍然可以保持很好的处理性能,即使redis故障,也只会丢失最近1秒钟的数据。
如果在追加日志时,恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整,也没有关系,redis提供了redis-check-aof工具,可以用来进行日志修复。
因为采用了追加方式,如果不做任何处理的话,AOF文件会变得越来越大,为此,redis提供了AOF文件重写(rewrite)机制,即当AOF文件的大小超过所设定的阈值时,redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。举个例子或许更形象,假如我们调用了100次INCR指令,在AOF文件中就要存储100条指令,但这明显是很低效的,完全可以把这100条指令合并成一条SET指令,这就是重写机制的原理。
在进行AOF重写时,仍然是采用先写临时文件,全部完成后再替换的流程,所以断电、磁盘满等问题都不会影响AOF文件的可用性,这点大家可以放心。
AOF方式的另一个好处,我们通过一个“场景再现”来说明。某同学在操作redis时,不小心执行了FLUSHALL,导致redis内存中的数据全部被清空了,这是很悲剧的事情。不过这也不是世界末日,只要redis配置了AOF持久化方式,且AOF文件还没有被重写(rewrite),我们就可以用最快的速度暂停redis并编辑AOF文件,将最后一行的FLUSHALL命令删除,然后重启redis,就可以恢复redis的所有数据到FLUSHALL之前的状态了。是不是很神奇,这就是AOF持久化方式的好处之一。但是如果AOF文件已经被重写了,那就无法通过这种方法来恢复数据了。
虽然优点多多,但AOF方式也同样存在缺陷,比如在同样数据规模的情况下,AOF文件要比RDB文件的体积大。而且,AOF方式的恢复速度也要慢于RDB方式。
如果你直接执行BGREWRITEAOF命令,那么redis会生成一个全新的AOF文件,其中便包括了可以恢复现有数据的最少的命令集。
如果运气比较差,AOF文件出现了被写坏的情况,也不必过分担忧,redis并不会贸然加载这个有问题的AOF文件,而是报错退出。这时可以通过以下步骤来修复出错的文件:
1.备份被写坏的AOF文件
2.运行redis-check-aof –fix进行修复
3.用diff -u来看下两个文件的差异,确认问题点
4.重启redis,加载修复后的AOF文件

    AOF优势

  1. 该机制可以带来更高的数据安全性,即数据持久性。Redis中提供了3中同步策略,即每秒同步、每修改同步和不同步。事实上,每秒同步也是异步完成的,其效率也是非常高的,所差的是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失。而每修改同步,我们可以将其视为同步持久化,即每次发生的数据变化都会被立即记录到磁盘中。可以预见,这种方式在效率上是最低的。至于无同步,无需多言,我想大家都能正确的理解它。
  2. 由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题,不用担心,在Redis下一次启动之前,我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
  3. 如果日志过大,Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中,同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
  4. AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上,我们也可以通过该文件完成数据的重建。

    AOF劣势

  1. 对于相同数量的数据集而言,AOF文件通常要大于RDB文件。
  2. 根据同步策略的不同,AOF在运行效率上往往会慢于RDB。总之,每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效。

AOF 重写

AOF重写的内部运行原理,我们有必要了解一下。
在重写即将开始之际,redis会创建(fork)一个“重写子进程”,这个子进程会首先读取现有的AOF文件,并将其包含的指令进行分析压缩并写入到一个临时文件中。
与此同时,主工作进程会将新接收到的写指令一边累积到内存缓冲区中,一边继续写入到原有的AOF文件中,这样做是保证原有的AOF文件的可用性,避免在重写过程中出现意外。
当“重写子进程”完成重写工作后,它会给父进程发一个信号,父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。
当追加结束后,redis就会用新AOF文件来代替旧AOF文件,之后再有新的写指令,就都会追加到新的AOF文件中了。


如何选择RDB和AOF

对于我们应该选择RDB还是AOF,官方的建议是两个同时使用。这样可以提供更可靠的持久化方案。


其它

1. Snapshotting:

缺省情况下,Redis会将数据集的快照dump到dump.rdb文件中。此外,我们也可以通过配置文件来修改Redis服务器dump快照的频率,在打开6379.conf文件之后,我们搜索save,可以看到下面的配置信息:
save 900 1 #在900秒(15分钟)之后,如果至少有1个key发生变化,则dump内存快照。
save 300 10 #在300秒(5分钟)之后,如果至少有10个key发生变化,则dump内存快照。
save 60 10000 #在60秒(1分钟)之后,如果至少有10000个key发生变化,则dump内存快照。

2. Dump快照的机制:

1). Redis先fork子进程。
2). 子进程将快照数据写入到临时RDB文件中。
3). 当子进程完成数据写入操作后,再用临时文件替换老的文件。

3. AOF文件:

上面已经多次讲过,RDB的快照定时dump机制无法保证很好的数据持久性。如果我们的应用确实非常关注此点,我们可以考虑使用Redis中的AOF机制。对于Redis服务器而言,其缺省的机制是RDB,如果需要使用AOF,则需要修改配置文件中的以下条目:
将appendonly no改为appendonly yes
从现在起,Redis在每一次接收到数据修改的命令之后,都会将其追加到AOF文件中。在Redis下一次重新启动时,需要加载AOF文件中的信息来构建最新的数据到内存中。

4. AOF的配置:

在Redis的配置文件中存在三种同步方式,它们分别是:
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次,该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。

5. 如何修复坏损的AOF文件:

1). 将现有已经坏损的AOF文件额外拷贝出来一份。
2). 执行"redis-check-aof --fix <filename>"命令来修复坏损的AOF文件。
3). 用修复后的AOF文件重新启动Redis服务器。

6. Redis的数据备份:

在Redis中我们可以通过copy的方式在线备份正在运行的Redis数据文件。这是因为RDB文件一旦被生成之后就不会再被修改。Redis每次都是将最新的数据dump到一个临时文件中,之后在利用rename函数原子性的将临时文件改名为原有的数据文件名。因此我们可以说,在任意时刻copy数据文件都是安全的和一致的。鉴于此,我们就可以通过创建cron job的方式定时备份Redis的数据文件,并将备份文件copy到安全的磁盘介质中。 


虚拟内存介绍


简介

和大多NoSQL数据库一样,Redis同样遵循了Key/Value数据存储模型。在有些情况下,Redis会将Keys/Values保存在内存中以提高数据查询和数据修改的效率,然而这样的做法并非总是很好的选择。鉴于此,我们可以将之进一步优化,即尽量在内存中只保留Keys的数据,这样可以保证数据检索的效率,而Values数据在很少使用的时候则可以被换出到磁盘。
在实际的应用中,大约只有10%的Keys属于相对比较常用的键,这样Redis就可以通过虚存将其余不常用的Keys和Values换出到磁盘上,而一旦这些被换出的Keys或Values需要被读取时,Redis则将其再次读回到主内存中。


应用场景

对于大多数数据库而言,最为理想的运行方式就是将所有的数据都加载到内存中,而之后的查询操作则可以完全基于内存数据完成。然而在现实中这样的场景却并不普遍,更多的情况则是只有部分数据可以被加载到内存中。
在Redis中,有一个非常重要的概念,即keys一般不会被交换,所以如果你的数据库中有大量的keys,其中每个key仅仅关联很小的value,那么这种场景就不是非常适合使用虚拟内存。如果恰恰相反,数据库中只是包含少量的keys,而每一个key所关联的value却非常大,那么这种场景对于使用虚存就再合适不过了。
在实际的应用中,为了能让虚存更为充分的发挥作用以帮助我们提高系统的运行效率,我们可以将带有很多较小值的Keys合并为带有少量较大值的Keys。其中最主要的方法就是将原有的Key/Value模式改为基于Hash的模式,这样可以让很多原来的Keys成为Hash中的属性。


配置

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

vm-enabled yes

2). 在配置文件中设定Redis最大可用的虚存字节数。如果内存中的数据大于该值,则有部分对象被换出到磁盘中,其中被换出对象所占用内存将被释放,直到已用内存小于该值时才停止换出。

 vm-max-memory (bytes)

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

3). 在配置文件中设定页的数量及每一页所占用的字节数。为了将内存中的数据传送到磁盘上,我们需要使用交换文件。这些文件与数据持久性无关,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的该特征。

4). 在Redis的配置文件中有一个非常重要的配置参数,即:

vm-max-threads 4

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


聊聊主从( Master-Slave模式 ) – 用法


Redis的主从复制与集群配置实践:http://lib.csdn.net/article/redis/22518

主从同步 与 集群管理:http://blog.csdn.net/u012152619/article/details/52854465


        从数据库是主数据库的备份,当主数据库变化时,从数据库就要同步更新,这些数据库软件可以设计更新周期。这是提高信息安全的手段。主从数据库服务器不在一个地理位置上,当发生意外时数据库可以保存。

        像MySQL一样,redis是支持主从同步的,而且也支持一主多从以及多级从结构。

        主从结构,一是为了纯粹的冗余备份,二是为了提升读性能,比如很消耗性能的SORT就可以由从服务器来承担。

        redis的主从同步是异步进行的,这意味着主从同步不会影响主逻辑,也不会降低redis的处理性能。

        主从架构中,可以考虑关闭主服务器的数据持久化功能,只让从服务器进行持久化,这样可以提高主服务器的处理性能。

        在主从架构中,从服务器通常被设置为只读模式,这样可以避免从服务器的数据被误修改。但是从服务器仍然可以接受CONFIG等指令,所以还是不应该将从服务器直接暴露到不安全的网络环境中。如果必须如此,那可以考虑给重要指令进行重命名,来避免命令被外人误执行。


聊聊主从( Master-Slave模式 ) – 同步原理


从服务器会向主服务器发出SYNC指令,当主服务器接到此命令后,就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作,也就是将主服务器的数据写入RDB文件中。在数据持久化期间,主服务器将执行的写指令都缓存在内存中。
在BGSAVE指令执行完成后,主服务器会将持久化好的RDB文件发送给从服务器,从服务器接到此文件后会将其存储到磁盘上,然后再将其读取到内存中。这个动作完成后,主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。
另外,要说的一点是,即使有多个从服务器同时发来SYNC指令,主服务器也只会执行一次BGSAVE,然后把持久化好的RDB文件发给多个下游。在redis2.8版本之前,如果从服务器与主服务器因某些原因断开连接的话,都会进行一次主从之间的全量的数据同步;而在2.8版本之后,redis支持了效率更高的增量同步策略,这大大降低了连接断开的恢复成本。
主服务器会在内存中维护一个缓冲区,缓冲区中存储着将要发给从服务器的内容。从服务器在与主服务器出现网络瞬断之后,从服务器会尝试再次与主服务器连接,一旦连接成功,从服务器就会把“希望同步的主服务器ID”和“希望请求的数据的偏移位置(replication offset)”发送出去。主服务器接收到这样的同步请求后,首先会验证主服务器ID是否和自己的ID匹配,其次会检查“请求的偏移位置”是否存在于自己的缓冲区中,如果两者都满足的话,主服务器就会向从服务器发送增量内容。
增量同步功能,需要服务器端支持全新的PSYNC指令。这个指令,只有在redis-2.8之后才具有。


主从( Master-Slave模式 )复制配置实例


Redis 的 Replication

在Redis中配置Master-Slave模式很简单。读完下面的内容后你也可以轻松做到。先列出一些理论性的知识,后面给出实际操作的案例。

下面的列表解释了 Redis Replication的特点和优势。

  1.  同一个Master可以同步多个Slaves。
  2.  Slave同样可以接受其它Slaves的连接和同步请求,这样可以有效的分载Master的同步压力。因此我们可以将Redis的Replication架构视为图结构。
  3.  Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间,客户端仍然可以提交查询或修改请求。
  4.  Slave Server同样是以非阻塞的方式完成数据同步。在同步期间,如果有客户端提交查询请求,Redis则返回同步之前的数据。
  5.  为了分载Master的读操作压力,Slave服务器可以为客户端提供只读操作的服务,写服务仍然必须由Master来完成。即便如此,系统的伸缩性还是得到了很大的提高。
  6.  Master可以将数据保存操作交给Slaves完成,从而避免了在Master中要有独立的进程来完成此操作。

Replication的工作原理

        在Slave启动并连接到Master之后,它将主动发送一个SYNC命令。此后Master将启动后台存盘进程,同时收集所有接收到的用于修改数据集的命令,在后台进程执行完毕后,Master将传送整个数据库文件到Slave,以完成一次完全同步。而Slave服务器在接收到数据库文件数据之后将其存盘并加载到内存中。此后,Master继续将所有已经收集到的修改命令,和新的修改命令依次传送给Slaves,Slave将在本次执行这些数据修改命令,从而达到最终的数据同步。
        如果Master和Slave之间的链接出现断连现象,Slave可以自动重连Master,但是在连接成功之后,一次完全同步将被自动执行。

如何配置Replication

见如下步骤:

    1). 同时启动两个Redis服务器,可以考虑在同一台机器上启动两个Redis服务器,分别监听不同的端口,如6379和6380。
    2). 在Slave服务器上执行一下命令:

  /> redis-cli -p 6380   #这里我们假设Slave的端口号是6380
    redis 127.0.0.1:6380> slaveof 127.0.0.1 6379 #我们假设Master和Slave在同一台主机,Master的端口为6379
    OK

上面的方式只是保证了在执行slaveof命令之后,redis_6380成为了redis_6379的slave,一旦服务(redis_6380)重新启动之后,他们之间的复制关系将终止。
如果希望长期保证这两个服务器之间的Replication关系,可以在redis_6380的配置文件中做如下修改:

/> cd /etc/redis  #切换Redis服务器配置文件所在的目录。
/> ls
6379.conf  6380.conf
/> vi 6380.conf
将
# slaveof <masterip> <masterport>
改为
slaveof 127.0.0.1 6379

保存退出。这样就可以保证Redis_6380服务程序在每次启动后都会主动建立与Redis_6379的Replication连接了。

应用示例:

这里我们假设Master-Slave已经建立。

#启动master服务器。
[root@Stephen-PC redis]# redis-cli -p 6379
redis 127.0.0.1:6379>
#情况Master当前数据库中的所有Keys。
redis 127.0.0.1:6379> flushdb
OK
#在Master中创建新的Keys作为测试数据。
redis 127.0.0.1:6379> set mykey hello
OK
redis 127.0.0.1:6379> set mykey2 world
OK
#查看Master中存在哪些Keys。
redis 127.0.0.1:6379> keys *
1) "mykey"
2) "mykey2"

#启动slave服务器。
[root@Stephen-PC redis]# redis-cli -p 6380
#查看Slave中的Keys是否和Master中一致,从结果看,他们是相等的。
redis 127.0.0.1:6380> keys *
1) "mykey"
2) "mykey2"

#在Master中删除其中一个测试Key,并查看删除后的结果。
redis 127.0.0.1:6379> del mykey2
(integer) 1
redis 127.0.0.1:6379> keys *
1) "mykey"

#在Slave中查看是否mykey2也已经在Slave中被删除。
redis 127.0.0.1:6380> keys *
1) "mykey"


聊聊redis的事务处理


众所周知,事务是指“一个完整的动作,要么全部执行,要么什么也没有做”。
在聊redis事务处理之前,要先和大家介绍四个redis指令,即MULTI、EXEC、DISCARD、WATCH。这四个指令构成了redis事务处理的基础。

1. MULTI 用来组装一个事务;
2. EXEC 用来执行一个事务;
3. DISCARD 用来取消一个事务;
4. WATCH 用来监视一些 key,一旦这些 key 在事务执行之前被改变,则取消事务的执行。

和众多其它数据库一样,Redis作为NoSQL数据库也同样提供了事务机制。在Redis中,MULTI/EXEC/DISCARD/WATCH这四个命令是我们实现事务的基石。相信对有关系型数据库开发经验的开发者而言这一概念并不陌生,即便如此,我们还是会简要的列出Redis中事务的实现特征:
1). 在事务中的所有命令都将会被串行化的顺序执行,事务执行期间,Redis不会再为其它客户端的请求提供任何服务,从而保证了事物中的所有命令被原子的执行。
2). 和关系型数据库中的事务相比,在Redis事务中如果有某一条命令执行失败,其后的命令仍然会被继续执行。
3). 我们可以通过MULTI命令开启一个事务,有关系型数据库开发经验的人可以将其理解为"BEGIN TRANSACTION"语句。在该语句之后执行的命令都将被视为事务之内的操作,最后我们可以通过执行EXEC/DISCARD命令来提交/回滚该事务内的所有操作。这两个Redis命令可被视为等同于关系型数据库中的COMMIT/ROLLBACK语句。
4). 在事务开启之前,如果客户端与服务器之间出现通讯故障并导致网络断开,其后所有待执行的语句都将不会被服务器执行。然而如果网络中断事件是发生在客户端执行EXEC命令之后,那么该事务中的所有命令都会被服务器执行。
5). 当使用Append-Only模式时,Redis会通过调用系统函数write将该事务内的所有写操作在本次调用中全部写入磁盘。然而如果在写入的过程中出现系统崩溃,如电源故障导致的宕机,那么此时也许只有部分数据被写入到磁盘,而另外一部分数据却已经丢失。Redis服务器会在重新启动时执行一系列必要的一致性检测,一旦发现类似问题,就会立即退出并给出相应的错误提示。此时,我们就要充分利用Redis工具包中提供的redis-check-aof工具,该工具可以帮助我们定位到数据不一致的错误,并将已经写入的部分数据进行回滚。修复之后我们就可以再次重新启动Redis服务器了。

相关命令

MULTI
        用于标记事务的开始,其后执行的命令都将被存入命令队列,直到执行EXEC时,这些命令才会被原子的执行。始终返回OK
EXEC
        执行在一个事务内命令队列中的所有命令,同时将当前连接的状态恢复为正常状态,即非事务状态。
		如果在事务中执行了WATCH命令,那么只有当WATCH所监控的Keys没有被修改的前提下,EXEC命令才能执行事务队列中的所有命令,
		否则EXEC将放弃当前事务中的所有命令。	
		原子性的返回事务中各条命令的返回结果。如果在事务中使用了WATCH,一旦事务被放弃,EXEC将返回NULL-multi-bulk回复。
DISCARD
        回滚事务队列中的所有命令,同时再将当前连接的状态恢复为正常状态,即非事务状态。
		如果WATCH命令被使用,该命令将UNWATCH所有的Keys。	始终返回OK。
WATCHkey [key ...]	
        在MULTI命令执行之前,可以指定待监控的Keys,然而在执行EXEC之前,如果被监控的Keys发生修改,
		EXEC将放弃执行该事务队列中的所有命令。	始终返回OK。
UNWATCH	  
        取消当前事务中指定监控的Keys,如果执行了EXEC或DISCARD命令,则无需再手工执行该命令了,
		因为在此之后,事务中所有被监控的Keys都将自动取消。	始终返回OK。

命令示例

1. 事务被正常执行:
    #在Shell命令行下执行Redis的客户端工具。
    /> redis-cli
    #在当前连接上启动一个新的事务。
    redis 127.0.0.1:6379> multi
    OK
    #执行事务中的第一条命令,从该命令的返回结果可以看出,该命令并没有立即执行,而是存于事务的命令队列。
    redis 127.0.0.1:6379> incr t1
    QUEUED
    #又执行一个新的命令,从结果可以看出,该命令也被存于事务的命令队列。
    redis 127.0.0.1:6379> incr t2
    QUEUED
    #执行事务命令队列中的所有命令,从结果可以看出,队列中命令的结果得到返回。
    redis 127.0.0.1:6379> exec
    1) (integer) 1
    2) (integer) 1  
    
2. 事务中存在失败的命令:
    #开启一个新的事务。
    redis 127.0.0.1:6379> multi
    OK
    #设置键a的值为string类型的3。
    redis 127.0.0.1:6379> set a 3
    QUEUED
    #从键a所关联的值的头部弹出元素,由于该值是字符串类型,而lpop命令仅能用于List类型,因此在执行exec命令时,该命令将会失败。
    redis 127.0.0.1:6379> lpop a
    QUEUED
    #再次设置键a的值为字符串4。
    redis 127.0.0.1:6379> set a 4
    QUEUED
    #获取键a的值,以便确认该值是否被事务中的第二个set命令设置成功。
    redis 127.0.0.1:6379> get a
    QUEUED
    #从结果中可以看出,事务中的第二条命令lpop执行失败,而其后的set和get命令均执行成功,这一点是Redis的事务与关系型数据库中的事务之间最为重要的差别。
    redis 127.0.0.1:6379> exec
    1) OK
    2) (error) ERR Operation against a key holding the wrong kind of value
    3) OK
    4) "4"

3. 回滚事务:
    #为键t2设置一个事务执行前的值。
    redis 127.0.0.1:6379> set t2 tt
    OK
    #开启一个事务。
    redis 127.0.0.1:6379> multi
    OK
    #在事务内为该键设置一个新值。
    redis 127.0.0.1:6379> set t2 ttnew
    QUEUED
    #放弃事务。
    redis 127.0.0.1:6379> discard
    OK
    #查看键t2的值,从结果中可以看出该键的值仍为事务开始之前的值。
    redis 127.0.0.1:6379> get t2
    "tt"

4、WATCH命令和基于CAS的乐观锁:
      在Redis的事务中,WATCH命令可用于提供CAS(check-and-set)功能。
	  假设我们通过WATCH命令在事务执行之前监控了多个Keys,倘若在WATCH之后有任何Key的值发生了变化,EXEC命令执行的事务都将被放弃,
	  同时返回Null multi-bulk应答以通知调用者事务执行失败。
	  例如,我们再次假设Redis中并未提供incr命令来完成键值的原子性递增,如果要实现该功能,我们只能自行编写相应的代码。
	  其伪码如下:

      val = GET mykey
      val = val + 1
      SET mykey $val
  
      以上代码只有在单连接的情况下才可以保证执行结果是正确的,
	  因为如果在同一时刻有多个客户端在同时执行该段代码,
	  那么就会出现多线程程序中经常出现的一种错误场景--竞态争用(race condition)。
	  比如,客户端A和B都在同一时刻读取了mykey的原有值,假设该值为10,此后两个客户端又均将该值加一后set回Redis服务器,
	  这样就会导致mykey的结果为11,而不是我们认为的12。为了解决类似的问题,我们需要借助WATCH命令的帮助,见如下代码:
  
      WATCH mykey
      val = GET mykey
      val = val + 1
      MULTI
      SET mykey $val
      EXEC
  
      和此前代码不同的是,新代码在获取mykey的值之前先通过WATCH命令监控了该键,此后又将set命令包围在事务中,
	  这样就可以有效的保证每个连接在执行EXEC之前,如果当前连接获取的mykey的值被其它连接的客户端修改,
	  那么当前连接的EXEC命令将执行失败。这样调用者在判断返回值后就可以获悉val是否被重新设置成功。

纸上得来终觉浅,我们来看一个MULTI和EXEC的例子:

redis> MULTI //标记事务开始
OK
redis> INCR user_id //多条命令按顺序入队
QUEUED
redis> INCR user_id
QUEUED
redis> INCR user_id
QUEUED
redis> PING
QUEUED
redis> EXEC //执行
1) (integer) 1
2) (integer) 2
3) (integer) 3
4) PONG

在上面的例子中,我们看到了QUEUED的字样,这表示我们在用MULTI组装事务时,每一个命令都会进入到内存队列中缓存起来,如果出现QUEUED则表示我们这个命令成功插入了缓存队列,在将来执行EXEC时,这些被QUEUED的命令都会被组装成一个事务来执行。
对于事务的执行来说,如果redis开启了AOF持久化的话,那么一旦事务被成功执行,事务中的命令就会通过write命令一次性写到磁盘中去,如果在向磁盘中写的过程中恰好出现断电、硬件故障等问题,那么就可能出现只有部分命令进行了AOF持久化,这时AOF文件就会出现不完整的情况,这时,我们可以使用redis-check-aof工具来修复这一问题,这个工具会将AOF文件中不完整的信息移除,确保AOF文件完整可用。
有关事务,大家经常会遇到的是两类错误:
1.调用EXEC之前的错误
2.调用EXEC之后的错误
“调用EXEC之前的错误”,有可能是由于语法有误导致的,也可能时由于内存不足导致的。只要出现某个命令无法成功写入缓冲队列的情况,redis都会进行记录,在客户端调用EXEC时,redis会拒绝执行这一事务。(这时2.6.5版本之后的策略。在2.6.5之前的版本中,redis会忽略那些入队失败的命令,只执行那些入队成功的命令)。我们来看一个这样的例子:

127.0.0.1:6379> multi
OK
127.0.0.1:6379> haha //一个明显错误的指令
(error) ERR unknown command 'haha'
127.0.0.1:6379> ping
QUEUED
127.0.0.1:6379> exec
//redis无情的拒绝了事务的执行,原因是“之前出现了错误”
(error) EXECABORT Transaction discarded because of previous errors.

而对于“调用EXEC之后的错误”,redis则采取了完全不同的策略,即redis不会理睬这些错误,而是继续向下执行事务中的其他命令。这是因为,对于应用层面的错误,并不是redis自身需要考虑和处理的问题,所以一个事务中如果某一条命令执行失败,并不会影响接下来的其他命令的执行。我们也来看一个例子:

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set age 23
QUEUED
//age不是集合,所以如下是一条明显错误的指令
127.0.0.1:6379> sadd age 15 
QUEUED
127.0.0.1:6379> set age 29
QUEUED
127.0.0.1:6379> exec //执行事务时,redis不会理睬第2条指令执行错误
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) OK
127.0.0.1:6379> get age
"29" //可以看出第3条指令被成功执行了

好了,我们来说说最后一个指令“WATCH”,这是一个很好用的指令,它可以帮我们实现类似于“乐观锁”的效果,即CAS(check and set)。
WATCH本身的作用是“监视key是否被改动过”,而且支持同时监视多个key,只要还没真正触发事务,WATCH都会尽职尽责的监视,一旦发现某个key被修改了,在执行EXEC时就会返回nil,表示事务无法触发。

127.0.0.1:6379> set age 23
OK
127.0.0.1:6379> watch age //开始监视age
OK
127.0.0.1:6379> set age 24 //在EXEC之前,age的值被修改了
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set age 25
QUEUED
127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> exec //触发EXEC
(nil) //事务无法被执行


教你看懂redis配置 – 简介


我们可以在启动redis-server时指定应该加载的配置文件,方法如下:

$ ./redis-server /path/to/redis.conf

接下来,我们就来讲解下redis配置文件的各个配置项的含义,注意,本文是基于redis-2.8.4版本进行讲解的。
redis官方提供的redis.conf文件,足有700+行,其中100多行为有效配置行,另外的600多行为注释说明。
在配置文件的开头部分,首先明确了一些度量单位:

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

可以看出,redis配置中对单位的大小写不敏感,1GB、1Gb和1gB都是相同的。由此也说明,redis只支持bytes,不支持bit单位。
redis支持“主配置文件中引入外部配置文件”,很像C/C++中的include指令,比如:

include /path/to/other.conf

如果你看过redis的配置文件,会发现还是很有条理的。redis配置文件被分成了几大块区域,它们分别是:

1.通用(general)
2.快照(snapshotting)
3.复制(replication)
4.安全(security)
5.限制(limits)
6.追加模式(append only mode)
7.LUA脚本(lua scripting)
8.慢日志(slow log)
9.事件通知(event notification)
下面我们就来逐一讲解。

教你看懂redis配置 -通用

默认情况下,redis并不是以daemon形式来运行的。通过daemonize配置项可以控制redis的运行形式,如果改为yes,那么redis就会以daemon形式运行:

daemonize no

当以daemon形式运行时,redis会生成一个pid文件,默认会生成在/var/run/redis.pid。当然,你可以通过pidfile来指定pid文件生成的位置,比如:

pidfile /path/to/redis.pid

默认情况下,redis会响应本机所有可用网卡的连接请求。当然,redis允许你通过bind配置项来指定要绑定的IP,比如:

bind 192.168.1.2 10.8.4.2

redis的默认服务端口是6379,你可以通过port配置项来修改。如果端口设置为0的话,redis便不会监听端口了。

port 6379

有些同学会问“如果redis不监听端口,还怎么与外界通信呢”,其实redis还支持通过unix socket方式来接收请求。可以通过unixsocket配置项来指定unix socket文件的路径,并通过unixsocketperm来指定文件的权限。

unixsocket /tmp/redis.sock
unixsocketperm 755

当一个redis-client一直没有请求发向server端,那么server端有权主动关闭这个连接,可以通过timeout来设置“空闲超时时限”,0表示永不关闭。

timeout 0

TCP连接保活策略,可以通过tcp-keepalive配置项来进行设置,单位为秒,假如设置为60秒,则server端会每60秒向连接空闲的客户端发起一次ACK请求,以检查客户端是否已经挂掉,对于无响应的客户端则会关闭其连接。所以关闭一个连接最长需要120秒的时间。如果设置为0,则不会进行保活检测。

tcp-keepalive 0

redis支持通过loglevel配置项设置日志等级,共分四级,即debug、verbose、notice、warning。

loglevel notice

redis也支持通过logfile配置项来设置日志文件的生成位置。如果设置为空字符串,则redis会将日志输出到标准输出。假如你在daemon情况下将日志设置为输出到标准输出,则日志会被写到/dev/null中。

logfile ""

如果希望日志打印到syslog中,也很容易,通过syslog-enabled来控制。另外,syslog-ident还可以让你指定syslog里的日志标志,比如:

syslog-ident redis

而且还支持指定syslog设备,值可以是USER或LOCAL0-LOCAL7。具体可以参考syslog服务本身的用法。

syslog-facility local0

对于redis来说,可以设置其数据库的总数量,假如你希望一个redis包含16个数据库,那么设置如下:

databases 16

这16个数据库的编号将是0到15。默认的数据库是编号为0的数据库。用户可以使用select <DBid>来选择相应的数据库。

教你看懂redis配置 – 快照

快照,主要涉及的是redis的RDB持久化相关的配置,我们来一起看一看。我们可以用如下的指令来让数据保存到磁盘上,即控制RDB快照功能:

save <seconds> <changes>

举例来说:

save 900 1 //表示每15分钟且至少有1个key改变,就触发一次持久化
save 300 10 //表示每5分钟且至少有10个key改变,就触发一次持久化
save 60 10000 //表示每60秒至少有10000个key改变,就触发一次持久化

如果你想禁用RDB持久化的策略,只要不设置任何save指令就可以,或者给save传入一个空字符串参数也可以达到相同效果,就像这样:

save ""

如果用户开启了RDB快照功能,那么在redis持久化数据到磁盘时如果出现失败,默认情况下,redis会停止接受所有的写请求。这样做的好处在于可以让用户很明确的知道内存中的数据和磁盘上的数据已经存在不一致了。如果redis不顾这种不一致,一意孤行的继续接收写请求,就可能会引起一些灾难性的后果。
如果下一次RDB持久化成功,redis会自动恢复接受写请求。
当然,如果你不在乎这种数据不一致或者有其他的手段发现和控制这种不一致的话,你完全可以关闭这个功能,以便在快照写入失败时,也能确保redis继续接受新的写请求。配置项如下:

stop-writes-on-bgsave-error yes

对于存储到磁盘中的快照,可以设置是否进行压缩存储。如果是的话,redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能,但是存储在磁盘上的快照会比较大。

rdbcompression yes

在存储快照后,我们还可以让redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果你希望获取到最大的性能提升,可以关闭此功能。

rdbchecksum yes

我们还可以设置快照文件的名称,默认是这样配置的:

dbfilename dump.rdb

最后,你还可以设置这个快照文件存放的路径。比如默认设置就是当前文件夹:

dir ./

教你看懂redis配置 – 复制

redis提供了主从同步功能。
通过slaveof配置项可以控制某一个redis作为另一个redis的从服务器,通过指定IP和端口来定位到主redis的位置。一般情况下,我们会建议用户为从redis设置一个不同频率的快照持久化的周期,或者为从redis配置一个不同的服务端口等等。

slaveof <masterip> <masterport>

如果主redis设置了验证密码的话(使用requirepass来设置),则在从redis的配置中要使用masterauth来设置校验密码,否则的话,主redis会拒绝从redis的访问请求。

masterauth <master-password>

当从redis失去了与主redis的连接,或者主从同步正在进行中时,redis该如何处理外部发来的访问请求呢?这里,从redis可以有两种选择:
第一种选择:如果slave-serve-stale-data设置为yes(默认),则从redis仍会继续响应客户端的读写请求。
第二种选择:如果slave-serve-stale-data设置为no,则从redis会对客户端的请求返回“SYNC with master in progress”,当然也有例外,当客户端发来INFO请求和SLAVEOF请求,从redis还是会进行处理。
你可以控制一个从redis是否可以接受写请求。将数据直接写入从redis,一般只适用于那些生命周期非常短的数据,因为在主从同步时,这些临时数据就会被清理掉。自从redis2.6版本之后,默认从redis为只读。

slave-read-only yes

只读的从redis并不适合直接暴露给不可信的客户端。为了尽量降低风险,可以使用rename-command指令来将一些可能有破坏力的命令重命名,避免外部直接调用。比如:

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

从redis会周期性的向主redis发出PING包。你可以通过repl_ping_slave_period指令来控制其周期。默认是10秒。

repl-ping-slave-period 10

在主从同步时,可能在这些情况下会有超时发生:

1.以从redis的角度来看,当有大规模IO传输时。
2.以从redis的角度来看,当数据传输或PING时,主redis超时
3.以主redis的角度来看,在回复从redis的PING时,从redis超时
用户可以设置上述超时的时限,不过要确保这个时限比repl-ping-slave-period的值要大,否则每次主redis都会认为从redis超时。

repl-timeout 60

我们可以控制在主从同步时是否禁用TCP_NODELAY。如果开启TCP_NODELAY,那么主redis会使用更少的TCP包和更少的带宽来向从redis传输数据。但是这可能会增加一些同步的延迟,大概会达到40毫秒左右。如果你关闭了TCP_NODELAY,那么数据同步的延迟时间会降低,但是会消耗更多的带宽。(如果你不了解TCP_NODELAY,可以到这里来科普一下)。

repl-disable-tcp-nodelay no

我们还可以设置同步队列长度。队列长度(backlog)是主redis中的一个缓冲区,在与从redis断开连接期间,主redis会用这个缓冲区来缓存应该发给从redis的数据。这样的话,当从redis重新连接上之后,就不必重新全量同步数据,只需要同步这部分增量数据即可。

repl-backlog-size 1mb

如果主redis等了一段时间之后,还是无法连接到从redis,那么缓冲队列中的数据将被清理掉。我们可以设置主redis要等待的时间长度。如果设置为0,则表示永远不清理。默认是1个小时。

repl-backlog-ttl 3600

我们可以给众多的从redis设置优先级,在主redis持续工作不正常的情况,优先级高的从redis将会升级为主redis。而编号越小,优先级越高。比如一个主redis有三个从redis,优先级编号分别为10、100、25,那么编号为10的从redis将会被首先选中升级为主redis。当优先级被设置为0时,这个从redis将永远也不会被选中。默认的优先级为100。

slave-priority 100

假如主redis发现有超过M个从redis的连接延时大于N秒,那么主redis就停止接受外来的写请求。这是因为从redis一般会每秒钟都向主redis发出PING,而主redis会记录每一个从redis最近一次发来PING的时间点,所以主redis能够了解每一个从redis的运行情况。

min-slaves-to-write 3
min-slaves-max-lag 10

上面这个例子表示,假如有大于等于3个从redis的连接延迟大于10秒,那么主redis就不再接受外部的写请求。上述两个配置中有一个被置为0,则这个特性将被关闭。默认情况下min-slaves-to-write为0,而min-slaves-max-lag为10。

教你看懂redis配置 – 安全

我们可以要求redis客户端在向redis-server发送请求之前,先进行密码验证。当你的redis-server处于一个不太可信的网络环境中时,相信你会用上这个功能。由于redis性能非常高,所以每秒钟可以完成多达15万次的密码尝试,所以你最好设置一个足够复杂的密码,否则很容易被黑客破解。

requirepass zhimakaimen
这里我们通过requirepass将密码设置成“芝麻开门”。
redis允许我们对redis指令进行更名,比如将一些比较危险的命令改个名字,避免被误执行。比如可以把CONFIG命令改成一个很复杂的名字,这样可以避免外部的调用,同时还可以满足内部调用的需要:
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c89

我们甚至可以禁用掉CONFIG命令,那就是把CONFIG的名字改成一个空字符串:

rename-command CONFIG ""

但需要注意的是,如果你使用AOF方式进行数据持久化,或者需要与从redis进行通信,那么更改指令的名字可能会引起一些问题。

教你看懂redis配置 -限制

我们可以设置redis同时可以与多少个客户端进行连接。默认情况下为10000个客户端。当你无法设置进程文件句柄限制时,redis会设置为当前的文件句柄限制值减去32,因为redis会为自身内部处理逻辑留一些句柄出来。
如果达到了此限制,redis则会拒绝新的连接请求,并且向这些连接请求方发出“max number of clients reached”以作回应。

maxclients 10000

我们甚至可以设置redis可以使用的内存量。一旦到达内存使用上限,redis将会试图移除内部数据,移除规则可以通过maxmemory-policy来指定。
如果redis无法根据移除规则来移除内存中的数据,或者我们设置了“不允许移除”,那么redis则会针对那些需要申请内存的指令返回错误信息,比如SET、LPUSH等。但是对于无内存申请的指令,仍然会正常响应,比如GET等。

maxmemory <bytes>

需要注意的一点是,如果你的redis是主redis(说明你的redis有从redis),那么在设置内存使用上限时,需要在系统中留出一些内存空间给同步队列缓存,只有在你设置的是“不移除”的情况下,才不用考虑这个因素。
对于内存移除规则来说,redis提供了多达6种的移除规则。他们是:

1.volatile-lru:使用LRU算法移除过期集合中的key
2.allkeys-lru:使用LRU算法移除key
3.volatile-random:在过期集合中移除随机的key
4.allkeys-random:移除随机的key
5.volatile-ttl:移除那些TTL值最小的key,即那些最近才过期的key。
6.noeviction:不进行移除。针对写操作,只是返回错误信息。
无论使用上述哪一种移除规则,如果没有合适的key可以移除的话,redis都会针对写请求返回错误信息。

maxmemory-policy volatile-lru

LRU算法和最小TTL算法都并非是精确的算法,而是估算值。所以你可以设置样本的大小。假如redis默认会检查三个key并选择其中LRU的那个,那么你可以改变这个key样本的数量。

maxmemory-samples 3

最后,我们补充一个信息,那就是到目前版本(2.8.4)为止,redis支持的写指令包括了如下这些:

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

教你看懂redis配置 – 追加模式

默认情况下,redis会异步的将数据持久化到磁盘。这种模式在大部分应用程序中已被验证是很有效的,但是在一些问题发生时,比如断电,则这种机制可能会导致数分钟的写请求丢失。
如博文上半部分中介绍的,追加文件(Append Only File)是一种更好的保持数据一致性的方式。即使当服务器断电时,也仅会有1秒钟的写请求丢失,当redis进程出现问题且操作系统运行正常时,甚至只会丢失一条写请求。

我们建议大家,AOF机制和RDB机制可以同时使用,不会有任何冲突。对于如何保持数据一致性的讨论,请参见:https://redis.io/topics/persistence

appendonly no

我们还可以设置aof文件的名称:

appendfilename "appendonly.aof"

fsync()调用,用来告诉操作系统立即将缓存的指令写入磁盘。一些操作系统会“立即”进行,而另外一些操作系统则会“尽快”进行。
redis支持三种不同的模式:

1.no:不调用fsync()。而是让操作系统自行决定sync的时间。这种模式下,redis的性能会最快。
2.always:在每次写请求后都调用fsync()。这种模式下,redis会相对较慢,但数据最安全。
3.everysec:每秒钟调用一次fsync()。这是性能和安全的折衷。
默认情况下为everysec。有关数据一致性的揭秘,可以参考: http://oldblog.antirez.com/post/redis-persistence-demystified.html

appendfsync everysec

当fsync方式设置为always或everysec时,如果后台持久化进程需要执行一个很大的磁盘IO操作,那么redis可能会在fsync()调用时卡住。目前尚未修复这个问题,这是因为即使我们在另一个新的线程中去执行fsync(),也会阻塞住同步写调用。
为了缓解这个问题,我们可以使用下面的配置项,这样的话,当BGSAVE或BGWRITEAOF运行时,fsync()在主进程中的调用会被阻止。这意味着当另一路进程正在对AOF文件进行重构时,redis的持久化功能就失效了,就好像我们设置了“appendsync none”一样。如果你的redis有时延问题,那么请将下面的选项设置为yes。否则请保持no,因为这是保证数据完整性的最安全的选择。

no-appendfsync-on-rewrite no

我们允许redis自动重写aof。当aof增长到一定规模时,redis会隐式调用BGREWRITEAOF来重写log文件,以缩减文件体积。
redis是这样工作的:redis会记录上次重写时的aof大小。假如redis自启动至今还没有进行过重写,那么启动时aof文件的大小会被作为基准值。这个基准值会和当前的aof大小进行比较。如果当前aof大小超出所设置的增长比例,则会触发重写。另外,你还需要设置一个最小大小,是为了防止在aof很小时就触发重写。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

如果设置auto-aof-rewrite-percentage为0,则会关闭此重写功能。

教你看懂redis配置 – LUA脚本

lua脚本的最大运行时间是需要被严格限制的,要注意单位是毫秒:

lua-time-limit 5000

如果此值设置为0或负数,则既不会有报错也不会有时间限制。

教你看懂redis配置 – 慢日志

redis慢日志是指一个系统进行日志查询超过了指定的时长。这个时长不包括IO操作,比如与客户端的交互、发送响应内容等,而仅包括实际执行查询命令的时间。
针对慢日志,你可以设置两个参数,一个是执行时长,单位是微秒,另一个是慢日志的长度。当一个新的命令被写入日志时,最老的一条会从命令日志队列中被移除。
单位是微秒,即1000000表示一秒。负数则会禁用慢日志功能,而0则表示强制记录每一个命令。

slowlog-log-slower-than 10000

慢日志最大长度,可以随便填写数值,没有上限,但要注意它会消耗内存。你可以使用SLOWLOG RESET来重设这个值。

slowlog-max-len 128

教你看懂redis配置 – 事件通知

redis可以向客户端通知某些事件的发生。这个特性的具体解释可以参见:https://redis.io/topics/keyspace-events

教你看懂redis配置 – 高级配置

有关哈希数据结构的一些配置项:

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

有关列表数据结构的一些配置项:

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

有关集合数据结构的配置项:

set-max-intset-entries 512

有关有序集合数据结构的配置项:

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

关于是否需要再哈希的配置项:

activerehashing yes

关于客户端输出缓冲的控制项:

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

有关频率的配置项:

hz 10

有关重写aof的配置项

aof-rewrite-incremental-fsync yes

至此,redis的入门内容就结束了,内容实在不少,但相对来说都很基础,本文没有涉及redis集群、redis工作原理、redis源码、redis相关LIB库等内容,后续会陆续奉献,大家敬请期待:)




已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 书香水墨 设计师:CSDN官方博客 返回首页