Redis 5种数据类型，2种特殊数据处理策略

5种数据类型

String

[html] view
plaincopy

1. 1、String  
2. 经常使用命令：  
3. 除了get、set、incr、decr mget等操作外，Redis还提供了下面一些操作：  
4. 获取字符串长度  
5. 往字符串append内容  
6. 设置和获取字符串的某一段内容  
7. 设置及获取字符串的某一位（bit）  
8. 批量设置一系列字符串的内容  
9.   
10. 应用场景：  
11. String是最经常使用的一种数据类型，普通的key/value存储都能够归为此类。value事实上不仅是String，  
12. 也能够是数字：比方想知道什么时候封锁一个IP地址(訪问超过几次)。

    INCRBY命令让这些变得非常easy，通过原子递增保持计数。  

13.   
14. 实现方式：  
15. m,decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。  

Hash

[html] view
plaincopy

1. 经常使用命令：  
2. hget,hset,hgetall 等。  
3. 应用场景：  
4. 我们简单举个实例来描写叙述下Hash的应用场景，比方我们要存储一个用户信息对象数据，包括下面信息：  
5.            用户ID。为查找的key，  
6.            存储的value用户对象包括姓名name，年龄age，生日birthday 等信息。  
7.    假设用普通的key/value结构来存储，主要有下面2种存储方式：  
8.        第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储，  
9.            如：set u001 "李三,18,20010101"  
10.            这样的方式的缺点是，添加了序列化/反序列化的开销，而且在须要改动当中一项信息时，须要把整个对象取回，而且改动操作须要对并发进行保护。引入CAS等复杂问题。  
11.        另外一种方法是这个用户信息对象有多少成员就存成多少个key-value对儿，用用户ID+相应属性的名称作为唯一标识来取得相应属性的值。  
12.            如：mset user:001:name "李三 "user:001:age18 user:001:birthday "20010101"  
13.            尽管省去了序列化开销和并发问题，可是用户ID为反复存储。假设存在大量这样的数据，内存浪费还是非常可观的。  
14.     那么Redis提供的Hash非常好的攻克了这个问题，Redis的Hash实际是内部存储的Value为一个HashMap。  
15.     并提供了直接存取这个Map成员的接口，  
16.         如：hmset user:001 name "李三" age 18 birthday "20010101"     
17.             也就是说。Key仍然是用户ID,value是一个Map，这个Map的key是成员的属性名。value是属性值。  
18.             这样对数据的改动和存取都能够直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过   
19.             key(用户ID) + field(属性标签) 操作相应属性数据了，既不须要反复存储数据，也不会带来序列化和并发改动控制的问题。非常好的攻克了问题。

      

20.   
21.           这里同一时候须要注意，Redis提供了接口(hgetall)能够直接取到全部的属性数据,可是假设内部Map的成员非常多，那么涉及到遍历整个内部Map的操作，因为Redis单线程模型的缘故，这个遍历操作可能会比較耗时，而另其他client的请求全然不响应，这点须要格外注意。  
22.   实现方式：  
23.     上面已经说到Redis Hash相应Value内部实际就是一个HashMap，实际这里会有2种不同实现，这个Hash的成员比較少时Redis为了节省内存会採用相似一维数组的方式来紧凑存储。而不会採用真正的HashMap结构，相应的value redisObject的encoding为zipmap,当成员数量增大时会自己主动转成真正的HashMap,此时encoding为ht。

      

List

[html] view
plaincopy

1. 经常使用命令：  
2.     lpush,rpush,lpop,rpop,lrange,BLPOP(堵塞版)等。

     

3.   
4. 应用场景：  
5.     Redis list的应用场景非常多。也是Redis最重要的数据结构之中的一个。  
6.     我们能够轻松地实现最新消息排行等功能。

     

7.     Lists的还有一个应用就是消息队列，能够利用Lists的PUSH操作，将任务存在Lists中。然后工作线程再用POP操作将任务取出进行运行。

     

8.   
9. 实现方式：  
10.     Redis list的实现为一个双向链表。即能够支持反向查找和遍历。更方便操作，只是带来了部分额外的内存开销，Redis内部的非常多实现，包括发送缓冲队列等也都是用的这个数据结构。  
11.   
12. RPOPLPUSH source destination  
13.   
14.     命令 RPOPLPUSH 在一个原子时间内，运行下面两个动作：  
15.     将列表 source 中的最后一个元素(尾元素)弹出，并返回给client。

      

16.     将 source 弹出的元素插入到列表 destination 。作为 destination 列表的的头元素。  
17.     假设 source 和 destination 同样。则列表中的表尾元素被移动到表头。并返回该元素，能够把这样的特殊情况视作列表的旋转(rotation)操作。  
18.     一个典型的样例就是server的监控程序：它们须要在尽可能短的时间内，并行地检查一组站点。确保它们的可訪问性。

      

19.     redis.lpush "downstream_ips", "192.168.0.10"  
20.     redis.lpush "downstream_ips", "192.168.0.11"  
21.     redis.lpush "downstream_ips", "192.168.0.12"  
22.     redis.lpush "downstream_ips", "192.168.0.13"  
23.     Then:  
24.     next_ip = redis.rpoplpush "downstream_ips", "downstream_ips"  
25.   
26. BLPOP  
27.   
28.   假设如今有 job 、 command 和 request 三个列表，当中 job 不存在， command 和 request 都持有非空列表。考虑下面命令：  
29.   BLPOP job command request 30  #堵塞30秒。0的话就是无限期堵塞,job列表为空,被跳过,紧接着command 列表的第一个元素被弹出。  
30.   1) "command"                             # 弹出元素所属的列表  
31.   2) "update system..."                    # 弹出元素所属的值   
32.   为什么要堵塞版本号的pop呢，主要是为了避免轮询。举个简单的样例假设我们用list来实现一个工作队列。运行任务的thread能够调用堵塞版本号的pop去获取任务这样就能够避免轮询去检查是否有任务存在。

    当任务来时候工作线程能够马上返回，也能够避免轮询带来的延迟。

      

Set

[html] view
plaincopy

1. 4、Set  
2.   
3. 经常使用命令：  
4.     sadd,srem,spop,sdiff ,smembers,sunion 等。

     

5.   
6. 应用场景：  
7.     Redis set对外提供的功能与list相似是一个列表的功能。特殊之处在于set是能够自己主动排重的，当你须要存储一个列表数据，又不希望出现反复数据时，set是一个非常好的选择，而且set提供了推断某个成员是否在一个set集合内的重要接口。这个也是list所不能提供的。  
8.     比方在微博应用中，每一个人的好友存在一个集合（set）中。这样求两个人的共同好友的操作，可能就仅仅须要用求交集命令就可以。  
9.     Redis还为集合提供了求交集、并集、差集等操作，能够非常方便的实  
10.   
11. 实现方式：  
12.     set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来高速排重的，这也是set能提供推断一个成员是否在集合内的原因。  

Sort Set

[html] view
plaincopy

1. 5、Sorted set  
2.   
3.   经常使用命令：  
4.     zadd,zrange,zrem,zcard等  
5.   
6.   使用场景：  
7.     以某个条件为权重，比方按顶的次数排序.  
8.     ZREVRANGE命令能够用来依照得分来获取前100名的用户，ZRANK能够用来获取用户排名。非常直接而且操作easy。  
9.     Redis sorted set的使用场景与set相似。差别是set不是自己主动有序的，而sorted set能够通过用户额外提供一个优先级(score)的參数来为成员排序，而且是插入有序的，即自己主动排序。

     

10.     比方:twitter 的public timeline能够以发表时间作为score来存储，这样获取时就是自己主动按时间排好序的。  
11.     比方:全班同学成绩的SortedSets，value能够是同学的学号，而score就能够是其考试得分，这样数据插入集合的。就已经进行了天然的排序。

      

12.     另外还能够用Sorted Sets来做带权重的队列，比方普通消息的score为1，重要消息的score为2，然后工作线程能够选择按score的倒序来获取工作任务。让重要的任务优先运行。

      

13.   
14.     须要精准设定过期时间的应用  
15.     比方你能够把上面说到的sorted set的score值设置成过期时间的时间戳，那么就能够简单地通过过期时间排序。定时清除过期数据了，不仅是清除Redis中的过期数据，你全然能够把Redis里这个过期时间当成是对数据库中数据的索引，用Redis来找出哪些数据须要过期删除，然后再精准地从数据库中删除相应的记录。  
16.   
17.   
18.   实现方式：  
19.     Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射。而跳跃表里存放的是全部的成员，排序根据是HashMap里存的score,使用跳跃表的结构能够获得比較高的查找效率。而且在实现上比較简单。  

2种特殊数据处理策略

消息订阅

[html] view
plaincopy

1.    6、 Pub/Sub  
2.   
3.     Pub/Sub 从字面上理解就是公布（Publish）与订阅（Subscribe），在Redis中。你能够设定对某一个key值进行消息公布及消息订阅。  
4.     当一个key值上进行了消息公布后，全部订阅它的client都会收到相应的消息。

   这一功能最明显的使用方法就是用作实时消息系统，比方普通的即时聊天。群聊等功能。

     

5.   
6. client1：subscribe  rain  
7. client2：PUBLISH  rain "my love!!!"  
8.     (integer) 2 代表有几个client订阅了这个消息  

transaction

[html] view
plaincopy

1.   7、Transactions  
2.   
3.     谁说NoSQL都不支持事务。尽管Redis的Transactions提供的并非严格的ACID的事务（比方一串用EXEC提交运行的命令，在运行中server宕机，那么会有一部分命令运行了。剩下的没运行），可是这个Transactions还是提供了主要的命令打包运行的功能（在server不出问题的情况下，能够保证一连串的命令是顺序在一起运行的。中间有会有其他client命令插进来运行）。  
4.     Redis还提供了一个Watch功能，你能够对一个key进行Watch，然后再运行Transactions，在这过程中，假设这个Watched的值进行了改动。那么这个Transactions会发现并拒绝运行。

     

5. Session 1  
6.     (1)第1步  
7.     redis 127.0.0.1:6379> get age  
8.     "10"  
9.     redis 127.0.0.1:6379> watch age  
10.     OK  
11.     redis 127.0.0.1:6379> multi  
12.     OK  
13.     redis 127.0.0.1:6379>  
14.    
15. Session 2  
16.     (2)第2步  
17.     redis 127.0.0.1:6379> set age 30  
18.     OK  
19.     redis 127.0.0.1:6379> get age  
20.     "30"  
21.     redis 127.0.0.1:6379>  
22.   
23. Session 1     
24.     (3)第3步  
25.     redis 127.0.0.1:6379> set age 20  
26.     QUEUED  
27.     redis 127.0.0.1:6379> exec  
28.     (nil)  
29.     redis 127.0.0.1:6379> get age  
30.     "30"  
31.     redis 127.0.0.1:6379>  
32.   
33.     第一步，Session 1 还没有来得及对age的值进行改动  
34. 　　第二步。Session 2 已经将age的值设为30  
35. 　　第三步。Session 1 希望将age的值设为20，但结果一运行返回是nil，说明运行失败，之后我们再取一下age的值是30，这是因为Session   1中对age加了乐观锁导致的。

      

36.