redis（二）高级用法
事务
redis的事务是一组命令的集合。事务同命令一样都是redis的最小执行单元，一个事务中的命令要么执行要么都不执行。
首先需要multi命令来开始事务，用exec命令来执行事务。
127.0.0.1:> multi
OK
127.0.0.1:> hset user: name xiaoming
QUEUED
127.0.0.1:> hset user: name daxiong
QUEUED
127.0.0.1:> exec
) (integer)
) (integer)
127.0.0.1:> hgetall user:
) "name"
) "daxiong"
) "score"
) ""
multi代表事务的开始，返回ok表示成功；
exec代表事务的执行，返回各个命令的执行结果；
在multi和exec中间添加需要执行的命令。
在multi开始后，所有命令都不会执行，而是全部暂时保存起来，在执行exec命令后会按照命令保存的顺序依次执行各个命令。
如果事务执行过程中存在失败的情况下（某一个命令执行失败后其他命令会继续执行），需要开发人员自行处理后果。
注意：redis不支持回滚操作，导致redis的错误异常需要开发人员处理。
watch
watch命令可以监控一个或多个键值的变化，一旦其中一个键被改变，之后的事务就不会执行，而且监控会一直持续到exec命令。
127.0.0.1:> set key
OK
127.0.0.1:> watch key
OK
127.0.0.1:> set key
OK
127.0.0.1:> multi
OK
127.0.0.1:> set key
QUEUED
127.0.0.1:> exec
(nil)
127.0.0.1:> get key
""
生存时间
（1）设置key的超时时间，超时后redis会自动删除给key值，类似于memcache中的超时时间。
expire key seconds
//设置成功返回1，失败返回0
127.0.0.1:> set session:aabb uid1122
OK
127.0.0.1:> expire session:aabb
(integer)
127.0.0.1:> del session:aabb
(integer)
127.0.0.1:> expire session:aabb
(integer) 127.0.0.1:> expire session:aabb
(integer)
127.0.0.1:> ttl session:aabb
(integer)
（2）查询剩余超时时间
ttl key
127.0.0.1:> expire session:aabb
(integer)
127.0.0.1:> ttl session:aabb
(integer)
（3）取消超时时间
127.0.0.1:> get session:aabb
""
127.0.0.1:> ttl session:aabb
(integer)
127.0.0.1:> persist session:aabb
(integer)
127.0.0.1:> ttl session:aabb
(integer) -
（4）如果使用设置相关的命令，会取消该键的超时间
缓存数据
在某些情况下，需要缓存一部分网站数据，而网站数据由需要持续的更新（假如需要两个小时更新一次），那么可以采用redis进行缓存这部分数据，设置数据的超时时间为2小时，每当有请求访问的时候首先到redis中查找该数据是否存在，如果存在直接读取，如果不存在的话重新从数据库中读取该数据加载到redis中。
在缓存数据的时候需要考虑到被缓存数据的大小，如果缓存数据较大，会占用过多的内存资源，有必要在配置文件中限制内存的使用大小（maxmemory）。
当超过maxmemory的限制后，redis会根据maxmemory-policy参数指定的策略（包括LRU等算法）来删除不需要的键。
排序
sort命令支持对集合类型、类表类型、有序集合类型进行排序。
127.0.0.1:> lpush list
(integer)
127.0.0.1:> sort list
) ""
) ""
) ""
) ""
) ""
) ""
) ""
可以对有序集合的值进行排序：
127.0.0.1:> zadd set
(integer)
127.0.0.1:> sort set
) ""
) ""
) ""
) ""
sort命令可以添加desc来实现倒序排序
127.0.0.1:> sort set desc
) ""
) ""
) ""
) ""
BY参数
很多时候我们需要根据ID对应的对象的某一个属性进行排序，那么如何才能把多个不同的数据进行关联查询呢？
（1）首先，向userids中添加三个用户id
127.0.0.1:> lpush userids
(integer)
（2）其次，分别对三个用户添加分数
127.0.0.1:> set user_score_1
OK
127.0.0.1:> set user_score_2
OK
127.0.0.1:> set user_score_3
OK
（3）最后，使用sort、by命令来对对用户按照默认情况以及分数的递增和递减进行排序。
127.0.0.1:> sort userids
) ""
) ""
) ""
127.0.0.1:> sort userids by user_score_*
) ""
) ""
) ""
127.0.0.1:> sort userids by user_score_* desc
) ""
) ""
) ""
GET参数
get参数并不影响排序，它的作用是使sort命令返回的结果不再是元素自身的值，而是get参数中指定的键值，同by参数一样，支持字符串类型和散列类型的键。
127.0.0.1:> sort userids by user_score_* get user_name_*
) "xiaoming"
) "daxiong"
) "xiaohong"
127.0.0.1:> sort userids by user_score_* desc get user_name_*
) "xiaohong"
) "daxiong"
) "xiaoming"
STORE参数
store参数用于结果保存。
sort命令是redis的复杂命令之一，使用不好会造成性能的瓶颈。
sort命令的时间复杂度是O（n+mlog(m)），其中n是排序列表（集合和有序集合）中元素的个数，m是返回元素的个数。Redis在排序前会建立一个长度为n的的容器来存储待排序元素，虽然是一个临时的过程，但是多个较大数据的排序操作则会严重影响系统的性能。
因此，在开发中需要注意：
（1）尽可能减少排序键中的元素个数，降低n
（2）使用Limit参数只获取需要的数据，降低n
（3）如果要排序的数据量较大，尽可能使用store名来缓存结果。
任务队列
任务队列一般适用于生产者和消费者之间通信的，那么在redis中很容易想到使用列表类型来实现任务队列，具体方法是创建一个任务队列，生产者主动lpush数据，而消费者去rpop数据，保持一个先进先出的循序。
但是这样存在一个问题，消费者需要主动去请求数据，周期性的请求会造成资源的浪费，因此，redis提供了一个brpop的命令来解决这个问题。
BRPOP key timeout
brpop命令接收两个参数，第一个参数key为键值，第二个参数timeout为超时时间。BRPOP命令取数据时候，如果暂时不存在数据，该命令会一直阻塞直到达到超时时间。如果timeout设置为0，那么就会无限等待下去。
优先级队列
基于任务队列，如何实现优先级队列呢？
那么可以选择多个任务队列，而每个任务队列的任务优先级是不同的。
redis提供了下面的命令，会从左边第一个key开始读下去知道返回一个数据。
brpop key [key...] timetout
发布/订阅模式
redis提供了rabitmq类似的发布订阅模式，通过生产者使用下面的命令来发布消息，
PUBLISH CHANNEL MESSAGE
消费者通过下面的消息来订阅消息，
SUBSCRIBE CHANNEL MESSAGE
生产者：
#向channel.test发布消息
127.0.0.1:> publish channel.test hello
(integer) #返回0表明订阅者为0，没有发布消息
127.0.0.1:> publish channel.test hello
(integer) #返回n表明订阅者为n，成功发布给1个消费者
消费者：
#订阅channel.test消息
127.0.0.1:> subscribe channel.test
Reading messages... (press Ctrl-C to quit)
) "subscribe"
) "channel.test"
) (integer)
#接收到来自channel.test的消息
) "message"
) "channel.test"
) "hello"
管道
redis的底层通信协议对管道提供了支持。通过管道可以一次性发送多条命令并在执行完后一次性将结果返回，当一组命令中每条命令都不依赖之前命令的执行结果时就可以将这组命令一起通过管道发出。管道通过减少客户端与redis的通信次数来实现降低往返实验累计值的目的。
节省空间
（1）精简键名和键值
（2）redis为每种数据类型提供了两种内部编码。例如散列类型的存储是通过散列表来实现的，redis会根据数据的多少来选择编码类型，当数据较少的时候会采用紧凑但性能稍差的内部编码方式，而数据变多时会把编码方式改为散列表。