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

5种数据类型

String

1、String
经常使用命令：
除了get、set、incr、decr mget等操作外，Redis还提供了下面一些操作：
获取字符串长度
往字符串append内容
设置和获取字符串的某一段内容
设置及获取字符串的某一位（bit）
批量设置一系列字符串的内容

应用场景：
String是最经常使用的一种数据类型，普通的key/value存储都能够归为此类。value事实上不仅是String，
也能够是数字：比方想知道什么时候封锁一个IP地址(訪问超过几次)。INCRBY命令让这些变得非常easy，通过原子递增保持计数。

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

Hash

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

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

List

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

应用场景：
    Redis list的应用场景非常多。也是Redis最重要的数据结构之中的一个。
    我们能够轻松地实现最新消息排行等功能。
    Lists的还有一个应用就是消息队列，能够利用Lists的PUSH操作，将任务存在Lists中。然后工作线程再用POP操作将任务取出进行运行。

实现方式：
    Redis list的实现为一个双向链表。即能够支持反向查找和遍历。更方便操作，只是带来了部分额外的内存开销，Redis内部的非常多实现，包括发送缓冲队列等也都是用的这个数据结构。

RPOPLPUSH source destination

    命令 RPOPLPUSH 在一个原子时间内，运行下面两个动作：
    将列表 source 中的最后一个元素(尾元素)弹出，并返回给client。
    将 source 弹出的元素插入到列表 destination 。作为 destination 列表的的头元素。
    假设 source 和 destination 同样。则列表中的表尾元素被移动到表头。并返回该元素，能够把这样的特殊情况视作列表的旋转(rotation)操作。
    一个典型的样例就是server的监控程序：它们须要在尽可能短的时间内，并行地检查一组站点。确保它们的可訪问性。
    redis.lpush "downstream_ips", "192.168.0.10"
    redis.lpush "downstream_ips", "192.168.0.11"
    redis.lpush "downstream_ips", "192.168.0.12"
    redis.lpush "downstream_ips", "192.168.0.13"
    Then:
    next_ip = redis.rpoplpush "downstream_ips", "downstream_ips"

BLPOP

  假设如今有 job 、 command 和 request 三个列表，当中 job 不存在， command 和 request 都持有非空列表。考虑下面命令：
  BLPOP job command request 30  #堵塞30秒。0的话就是无限期堵塞,job列表为空,被跳过,紧接着command 列表的第一个元素被弹出。
  1) "command"                             # 弹出元素所属的列表
  2) "update system..."                    # 弹出元素所属的值
  为什么要堵塞版本号的pop呢，主要是为了避免轮询。举个简单的样例假设我们用list来实现一个工作队列。运行任务的thread能够调用堵塞版本号的pop去获取任务这样就能够避免轮询去检查是否有任务存在。当任务来时候工作线程能够马上返回，也能够避免轮询带来的延迟。

Set

4、Set

经常使用命令：
    sadd,srem,spop,sdiff ,smembers,sunion 等。

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

实现方式：
    set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来高速排重的，这也是set能提供推断一个成员是否在集合内的原因。

Sort Set

5、Sorted set

  经常使用命令：
    zadd,zrange,zrem,zcard等

  使用场景：
    以某个条件为权重，比方按顶的次数排序.
    ZREVRANGE命令能够用来依照得分来获取前100名的用户，ZRANK能够用来获取用户排名。非常直接而且操作easy。
    Redis sorted set的使用场景与set相似。差别是set不是自己主动有序的，而sorted set能够通过用户额外提供一个优先级(score)的參数来为成员排序，而且是插入有序的，即自己主动排序。
    比方:twitter 的public timeline能够以发表时间作为score来存储，这样获取时就是自己主动按时间排好序的。
    比方:全班同学成绩的SortedSets，value能够是同学的学号，而score就能够是其考试得分，这样数据插入集合的。就已经进行了天然的排序。
    另外还能够用Sorted Sets来做带权重的队列，比方普通消息的score为1，重要消息的score为2，然后工作线程能够选择按score的倒序来获取工作任务。让重要的任务优先运行。

    须要精准设定过期时间的应用
    比方你能够把上面说到的sorted set的score值设置成过期时间的时间戳，那么就能够简单地通过过期时间排序。定时清除过期数据了，不仅是清除Redis中的过期数据，你全然能够把Redis里这个过期时间当成是对数据库中数据的索引，用Redis来找出哪些数据须要过期删除，然后再精准地从数据库中删除相应的记录。


  实现方式：
    Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射。而跳跃表里存放的是全部的成员，排序根据是HashMap里存的score,使用跳跃表的结构能够获得比較高的查找效率。而且在实现上比較简单。

2种特殊数据处理策略

消息订阅

   6、 Pub/Sub

    Pub/Sub 从字面上理解就是公布（Publish）与订阅（Subscribe），在Redis中。你能够设定对某一个key值进行消息公布及消息订阅。
    当一个key值上进行了消息公布后，全部订阅它的client都会收到相应的消息。这一功能最明显的使用方法就是用作实时消息系统，比方普通的即时聊天。群聊等功能。

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

transaction

  7、Transactions

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

Session 2
    (2)第2步
    redis 127.0.0.1:6379> set age 30
    OK
    redis 127.0.0.1:6379> get age
    "30"
    redis 127.0.0.1:6379>

Session 1
    (3)第3步
    redis 127.0.0.1:6379> set age 20
    QUEUED
    redis 127.0.0.1:6379> exec
    (nil)
    redis 127.0.0.1:6379> get age
    "30"
    redis 127.0.0.1:6379>

    第一步，Session 1 还没有来得及对age的值进行改动
　　第二步。Session 2 已经将age的值设为30
　　第三步。Session 1 希望将age的值设为20，但结果一运行返回是nil，说明运行失败，之后我们再取一下age的值是30，这是因为Session   1中对age加了乐观锁导致的。