主题信息（必填）
主题描述（最多限制在50个字符）
申请人信息（必填）
申请信息已提交审核，请注意查收邮件，我们会尽快给您反馈。
如有疑问，请联系
傻丫头和高科技产物小心翼翼的初恋
如今的编程是一场程序员和上帝的竞赛，程序员要开发出更大更好、傻瓜都会用到软件。而上帝在努力创造出更大更傻的傻瓜。目前为止，上帝是赢的。个人网站：。个人QQ群：、
个人大数据技术博客：
CSDN &《程序员》编辑/记者，投稿&纠错等事宜请致邮
最详尽的Redis源码解析，第二篇，分析字符串在Redis中的内部存储结构developerWorks 社区
本文讲述了如何使用 Redis 作共享内存来实现分布式系统中的协调技术，包括 signal/wait，分布式锁，选举算法，消息队列等，并对其优缺点以及使用场景做了简单描述。
, C++开发工程师, 广州衣联网络科技有限公司
朱培旭，拥有多年 C++开发经验的软件工程师。
在分布式系统中，各个进程（本文使用进程来描述分布式系统中的运行主体，它们可以在同一个物理节点上也可以在不同的物理节点上）相互之间通常是需要协调进行运作的，有时是不同进程所处理的数据有依赖关系，必须按照一定的次序进行处理，有时是在一些特定的时间需要某个进程处理某些事务等等，人们通常会使用分布式锁、选举算法等技术来协调各个进程之间的行为。因为分布式系统本身的复杂特性，以及对于容错性的要求，这些技术通常是重量级的，比如 Paxos 算法，欺负选举算法，ZooKeeper 等，侧重于消息的通信而不是共享内存，通常也是出了名的复杂和难以理解，当在具体的实现和实施中遇到问题时都是一个挑战。Redis 经常被人们认为是一种 NoSQL 软件，但其本质上是一种分布式的数据结构服务器软件，提供了一个分布式的基于内存的数据结构存储服务。在实现上，仅使用一个线程来处理具体的内存数据结构，保证它的数据操作命令的原子特性；它同时还支持基于 Lua 的脚本，每个 Redis 实例使用同一个 Lua 解释器来解释运行 Lua 脚本，从而 Lua 脚本也具备了原子特性，这种原子操作的特性使得基于共享内存模式的分布式系统的协调方式成了可能，而且具备了很大的吸引力，和复杂的基于消息的机制不同，基于共享内存的模式对于很多技术人员来说明显容易理解的多，特别是那些已经了解多线程或多进程技术的人。在具体实践中，也并不是所有的分布式系统都像分布式数据库系统那样需要严格的模型的，而所使用的技术也不一定全部需要有坚实的理论基础和数学证明，这就使得基于 Redis 来实现分布式系统的协调技术具备了一定的实用价值，实际上，人们也已经进行了不少尝试。本文就其中的一些协调技术进行介绍。signal/wait 操作在分布式系统中，有些进程需要等待其它进程的状态的改变，或者通知其它进程自己的状态的改变，比如，进程之间有操作上的依赖次序时，就有进程需要等待，有进程需要发射信号通知等待的进程进行后续的操作，这些工作可以通过 Redis 的 Pub/Sub 系列命令来完成，比如：import redis, time
rc = redis.Redis()
def wait( wait_for ):
ps = rc.pubsub()
ps.subscribe( wait_for )
ps.get_message()
wait_msg = None
while True:
msg = ps.get_message()
if msg and msg['type'] == 'message':
wait_msg = msg
time.sleep(0.001)
ps.close()
return wait_msg
def signal_broadcast( wait_in, data ):
wait_count = rc.publish(wait_in, data)
return wait_count用这个方法很容易进行扩展实现其它的等待策略，比如 try wait，wait 超时，wait 多个信号时是要等待全部信号还是任意一个信号到达即可返回等等。因为 Redis 本身支持基于模式匹配的消息订阅（使用 psubscribe 命令），设置 wait 信号时也可以通过模式匹配的方式进行。和其它的数据操作不同，订阅消息是即时易逝的，不在内存中保存，不进行持久化保存，如果客户端到服务端的连接断开的话也是不会重发的，但是在配置了 master/slave 节点的情况下，会把 publish 命令同步到 slave 节点上，这样我们就可以同时在 master 以及 slave 节点的连接上订阅某个频道，从而可以同时接收到发布者发布的消息，即使 master 在使用过程中出故障，或者到 master 的连接出了故障，我们仍然能够从 slave 节点获得订阅的消息，从而获得更好的鲁棒性。另外，因为数据不用写入磁盘，这种方法在性能上也是有优势的。上面的方法中信号是广播的，所有在 wait 的进程都会收到信号，如果要将信号设置成单播，只允许其中一个收到信号，则可以通过约定频道名称模式的方式来实现，比如：频道名称 = 频道名前缀 (channel) + 订阅者全局唯一 ID(myid)其中唯一 ID 可以是 UUID，也可以是一个随机数字符串，确保全局唯一即可。在发送 signal 之前先使用“pubsub channels channel*”命令获得所有的订阅者订阅的频道，然后发送信号给其中一个随机指定的频道；等待的时候需要传递自己的唯一 ID，将频道名前缀和唯一 ID 合并为一个频道名称，然后同前面例子一样进行 wait。示例如下：import random
single_cast_script="""
local channels = redis.call('pubsub', 'channels', ARGV[1]..'*');
if #channels == 0 then
local index= math.mod(math.floor(tonumber(ARGV[2])), #channels) + 1;
return redis.call( 'publish', channels[index], ARGV[3]);
def wait_single( channel, myid):
return wait( channel + myid )
def signal_single( channel, data):
rand_num = int(random.random() * 65535)
return rc.eval( single_cast_script, 0, channel, str(rand_num), str(data) )分布式锁 Distributed
Locks分布式锁的实现是人们探索的比较多的一个方向，在 Redis 的官方网站上专门有一篇文档介绍，其中提出了 Redlock 算法，并列出了多种语言的实现案例，这里作一简要介绍。Redlock 算法着眼于满足分布式锁的三个要素：
安全性：保证互斥，任何时间至多只有一个客户端可以持有锁
免死锁：即使当前持有锁的客户端崩溃或者从集群中被分开了，其它客户端最终总是能够获得锁。
容错性：只要大部分的 Redis 节点在线，那么客户端就能够获取和释放锁。锁的一个简单直接的实现方法就是用 SET NX 命令设置一个设定了存活周期 TTL 的 Key 来获取锁，通过删除 Key 来释放锁，通过存活周期来保证避免死锁。不过这个方法存在单点故障风险，如果部署了 master/slave 节点，则在特定条件下可能会导致安全性方面的冲突，比如：
客户端 A 从 master 节点获得锁
master 节点在将 key 复制到 slave 节点之前崩溃了
slave 节点提升为新的 master 节点
客户端 B 从新的 master 节点获得了锁，而这个锁实际上已经由客户端 A 所持有，导致了系统中有两个客户端在同一时间段内持有同一个互斥锁，破坏了互斥锁的安全性。在 Redlock 算法中，通过类似于下面这样的命令进行加锁：SET resource_name my_random_value NX PX 30000这里的 my_random_value 为全局不同的随机数，每个客户端需要自己产生这个随机数并且记住它，后面解锁的时候需要用到它。解锁则需要通过一个 Lua 脚本来执行，不能简单地直接删除 Key，否则可能会把别人持有的锁给释放了：if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
end这个 ARGV[1] 的值就是前面加锁的时候的 my_random_value 的值。如果需要更好的容错性，可以建立一个有 N（N 为奇数）个相互独立完备的 Redis 冗余节点的集群，这种情况下，一个客户端获得锁和释放锁的算法如下：
先获取当前时间戳 timestamp_1，以毫秒为单位。
以相同的 Key 和随机数值，依次从 N 个节点获取锁，每次获取锁都设置一个超时，超时时限要保证小于所有节点上该锁的自动释放时间，以免在某个节点上耗时过长，通常都设的比较短。
客户端将当前时间戳减去第一步中的时间戳 timestamp_1，计算获取锁总消耗时间。只有当客户端获得了半数以上节点的锁，而且总耗时少于锁存活时间，该客户端才被认为已经成功获得了锁。
如果获得了锁，则其存活时间为开始预设锁存活时间减去获取锁总耗时间。
如果客户端不能获得锁，则应该马上在所有节点上解锁。
如果要重试，则在随机延时之后重新去获取锁。
获得了锁的客户端要释放锁，简单地在所有节点上解锁即可。Redlock 算法不需要保证 Redis 节点之间的时钟是同步的（不论是物理时钟还是逻辑时钟），这点和传统的一些基于同步时钟的分布式锁算法有所不同。Redlock 算法的具体的细节可以参阅 Redis 的官方文档，以及文档中列出的多种语言版本的实现。选举算法在分布式系统中，经常会有些事务是需要在某个时间段内由一个进程来完成，或者由一个进程作为 leader 来协调其它的进程，这个时候就需要用到选举算法，传统的选举算法有欺负选举算法（霸道选举算法）、环选举算法、Paxos 算法、Zab 算法 (ZooKeeper) 等，这些算法有些依赖于消息的可靠传递以及时钟同步，有些过于复杂，难以实现和验证。新的 Raft 算法相比较其它算法来说已经容易了很多，不过它仍然需要依赖心跳广播和逻辑时钟，leader 需要不断地向 follower 广播消息来维持从属关系，节点扩展时也需要其它算法配合。选举算法和分布式锁有点类似，任意时刻最多只能有一个 leader 资源。当然，我们也可以用前面描述的分布式锁来实现，设置一个 leader 资源，获得这个资源锁的为 leader，锁的生命周期过了之后，再重新竞争这个资源锁。这是一种竞争性的算法，这个方法会导致有比较多的空档期内没有 leader 的情况，也不好实现 leader 的连任，而 leader 的连任是有比较大的好处的，比如 leader 执行任务可以比较准时一些，查看日志以及排查问题的时候也方便很多，如果我们需要一个算法实现 leader 可以连任，那么可以采用这样的方法：import redis
rc = redis.Redis()
local_selector = 0
def master():
global local_selector
master_selector = rc.incr('master_selector')
if master_selector == 1:
# initial / restarted
local_selector = master_selector
if local_selector & 0:
# I'm the master before
if local_selector & master_selector:
# lost, maybe the db is fail-overed.
local_selector = 0
# continue to be the master
local_selector = master_selector
if local_selector & 0:
# I'm the current master
rc.expire('master_selector', 20)
return local_selector & 0这个算法鼓励连任，只有当前的 leader 发生故障或者执行某个任务所耗时间超过了任期、或者 Redis 节点发生故障恢复之后才需要重新选举出新的 leader。在 master/slave 模式下，如果 master 节点发生故障，某个 slave 节点提升为新的 master 节点，即使当时 master_selector 值尚未能同步成功，也不会导致出现两个 leader 的情况。如果某个 leader 一直连任，则 master_selector 的值会一直递增下去，考虑到 master_selector 是一个 64 位的整型类型，在可预见的时间内是不可能溢出的，加上每次进行 leader 更换的时候 master_selector 会重置为从 1 开始，这种递增的方式是可以接受的，但是碰到 Redis 客户端（比如 Node.js）不支持 64 位整型类型的时候就需要针对这种情况作处理。如果当前 leader 进程处理时间超过了任期，则其它进程可以重新生成新的 leader 进程，老的 leader 进程处理完毕事务后，如果新的 leader 的进程经历的任期次数超过或等于老的 leader 进程的任期次数，则可能会出现两个 leader 进程，为了避免这种情况，每个 leader 进程在处理完任期事务之后都应该检查一下自己的处理时间是否超过了任期，如果超过了任期，则应当先设置 local_selector 为 0 之后再调用 master 检查自己是否是 leader 进程。消息队列消息队列是分布式系统之间的通信基本设施，通过消息可以构造复杂的进程间的协调操作和互操作。Redis 也提供了构造消息队列的原语，比如 Pub/Sub 系列命令，就提供了基于订阅/发布模式的消息收发方法，但是 Pub/Sub 消息并不在 Redis 内保持，从而也就没有进行持久化，适用于所传输的消息即使丢失了也没有关系的场景。如果要考虑到持久化，则可以考虑 list 系列操作命令，用 PUSH 系列命令（LPUSH, RPUSH 等）推送消息到某个 list，用 POP 系列命令（LPOP, RPOP,BLPOP,BRPOP 等）获取某个 list 上的消息，通过不同的组合方式可以得到 FIFO，FILO，比如：import redis
rc = redis.Redis()
def fifo_push(q, data):
rc.lpush(q, data)
def fifo_pop(q):
return rc.rpop(q)
def filo_push(q, data):
rc.lpush(q, data)
def filo_pop(q):
return rc.lpop(q)如果用 BLPOP,BRPOP 命令替代 LPOP, RPOP，则在 list 为空的时候还支持阻塞等待。不过，即使按照这种方式实现了持久化，如果在 POP 消息返回的时候网络故障，则依然会发生消息丢失，针对这种需求 Redis 提供了 RPOPLPUSH 和 BRPOPLPUSH 命令来先将提取的消息保存在另外一个 list 中，客户端可以先从这个 list 查看和处理消息数据，处理完毕之后再从这个 list 中删除消息数据，从而确保了消息不会丢失，示例如下：def safe_fifo_push(q, data):
rc.lpush(q, data)
def safe_fifo_pop(q, cache):
msg = rc.rpoplpush(q, cache)
# check and do something on msg
rc.lrem(cache, 1) # remove the msg in cache list.
return msg如果使用 BRPOPLPUSH 命令替代 RPOPLPUSH 命令，则可以在 q 为空的时候阻塞等待。结语使用 Redis 作为分布式系统的共享内存，以共享内存模式为基础来实现分布式系统协调技术，虽然不像传统的基于消息传递的技术那样有着坚实的理论证明的基础，但是它在一些要求不苛刻的情况下不失为一种简单实用的轻量级解决方案，毕竟不是每个系统都需要严格的容错性等要求，也不是每个系统都会频繁地发生进程异常，而且 Redis 本身已经经受了工业界的多年实践和考验。另外，用 Redis 技术还有一些额外的好处，比如在开发过程中和生产环境中都可以直接观察到锁、队列的内容，实施的时候也不需要额外的特别配置过程等，它足够简单，在调试问题的时候逻辑清晰，进行排查和临时干预也比较方便。在可扩展性方面也比较好，可以动态扩展分布式系统的进程数目，而不需要事先预定好进程数目。Redis 支持基于 Key 值 hash 的集群，在集群中应用本文所述技术时建议另外部署专用 Redis 节点（或者冗余 Redis 节点集群）来使用，因为在基于 Key 值 hash 的集群中，不同的 Key 值会根据 hash 值被分布到不同的集群节点上，而且对于 Lua 脚本的支持也受到限制，难以保证一些操作的原子性，这一点是需要考虑到的。使用专用节点还有一个好处是专用节点的数据量会少很多，当应用了 master/slave 部署或者 AOF 模式的时候，因为数据量少，master 和 slave 之间的同步会少很多，AOF 模式实时写入磁盘的数据也少很多，这样子也可以大大提高可用性。本文示例所列 Python 代码在 Python3.4 下运行，Redis 客户端采用 ，Redis 服务端版本为 3.0.1 版。
参考资料 Redis 的，上面有非常全面的 Redis 相关文档，包括命令和部署方面的知识。Redlock 算法，上面有详细的文档，包括对该算法的详细分析，以及多种实现的链接。Raft 算法的，上面有丰富的 Raft 算法的资料，包括了该算法作者的以及其它相关论文和教程等，上面还收录了多种实现方案的链接。Wikipedia，上面有 与的介绍。Benjamin Reed 和 Flavio P.Junqueira 所著论文《》以及 ，对 Zab 算法进行了介绍。：查找丰富的操作信息、工具和项目更新，帮助您掌握开源技术并将其用于 IBM 产品。
加入 ，查看开发人员推动的博客、论坛、组和维基，并与其他 developerWorks 用户交流。
developerWorks: 登录
标有星（*）号的字段是必填字段。
保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件。
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
选择您的昵称
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。
您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
标有星（*）号的字段是必填字段。
(昵称长度在 3 至 31 个字符之间)
单击提交则表示您同意developerWorks 的条款和条件。 .
所有提交的信息确保安全。
文章、教程、演示，帮助您构建、部署和管理云应用。
立即加入来自 IBM 的专业 IT 社交网络。
免费下载、试用软件产品，构建应用并提升技能。
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=Open sourceArticleID=1008519ArticleTitle=使用 Redis 实现分布式系统轻量级协调技术publish-date=Redis几种数据结构的应用场景
[html] view plaincopy
常用命令：
除了get、set、incr、decr mget等操作外，Redis还提供了下面一些操作：
获取字符串长度
往字符串append内容
设置和获取字符串的某一段内容
设置及获取字符串的某一位（bit）
批量设置一系列字符串的内容
应用场景：
String是最常用的一种数据类型，普通的key/value存储都可以归为此类，value其实不仅是String，
也可以是数字：比如想知道什么时候封锁一个IP地址(访问超过几次)。INCRBY命令让这些变得很容易，通过原子递增保持计数。
实现方式：
m,decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。
[html] view plaincopy
常用命令：
hget,hset,hgetall 等。
应用场景：
我们简单举个实例来描述下Hash的应用场景，比如我们要存储一个用户信息对象数据，包含以下信息：
用户ID，为查找的key，
存储的value用户对象包含姓名name，年龄age，生日birthday 等信息，
如果用普通的key/value结构来存储，主要有以下2种存储方式：
第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储，
如：set u001 &李三,18,&
这种方式的缺点是，增加了序列化/反序列化的开销，并且在需要修改其中一项信息时，需要把整个对象取回，并且修改操作需要对并发进行保护，引入CAS等复杂问题。
第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿，用用户ID+对应属性的名称作为唯一标识来取得对应属性的值，
如：mset user:001:name &李三 &user:001:age18 user:001:birthday &&
虽然省去了序列化开销和并发问题，但是用户ID为重复存储，如果存在大量这样的数据，内存浪费还是非常可观的。
那么Redis提供的Hash很好的解决了这个问题，Redis的Hash实际是内部存储的Value为一个HashMap，
并提供了直接存取这个Map成员的接口，
如：hmset user:001 name &李三& age 18 birthday &&
也就是说，Key仍然是用户ID,value是一个Map，这个Map的key是成员的属性名，value是属性值，
这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过
key(用户ID) + field(属性标签) 操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题。很好的解决了问题。
这里同时需要注意，Redis提供了接口(hgetall)可以直接取到全部的属性数据,但是如果内部Map的成员很多，那么涉及到遍历整个内部Map的操作，由于Redis单线程模型的缘故，这个遍历操作可能会比较耗时，而另其它客户端的请求完全不响应，这点需要格外注意。
实现方式：
上面已经说到Redis Hash对应Value内部实际就是一个HashMap，实际这里会有2种不同实现，这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，对应的value redisObject的encoding为zipmap,当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。
[html] view plaincopy
常用命令：
lpush,rpush,lpop,rpop,lrange,BLPOP(阻塞版)等。
应用场景：
Redis list的应用场景非常多，也是Redis最重要的数据结构之一。
我们可以轻松地实现最新消息排行等功能。
Lists的另一个应用就是消息队列，可以利用Lists的PUSH操作，将任务存在Lists中，然后工作线程再用POP操作将任务取出进行执行。
实现方式：
Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。
RPOPLPUSH source destination
命令 RPOPLPUSH 在一个原子时间内，执行以下两个动作：
将列表 source 中的最后一个元素(尾元素)弹出，并返回给客户端。
将 source 弹出的元素插入到列表 destination ，作为 destination 列表的的头元素。
如果 source 和 destination 相同，则列表中的表尾元素被移动到表头，并返回该元素，可以把这种特殊情况视作列表的旋转(rotation)操作。
一个典型的例子就是服务器的监控程序：它们需要在尽可能短的时间内，并行地检查一站，确保它们的可访问性。
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&
next_ip = redis.rpoplpush &downstream_ips&, &downstream_ips&
假设现在有 job 、 command 和 request 三个列表，其中 job 不存在， command 和 request 都持有非空列表。考虑以下命令：
BLPOP job command request 30 #阻塞30秒，0的话就是无限期阻塞,job列表为空,被跳过,紧接着command 列表的第一个元素被弹出。
1) &command& # 弹出元素所属的列表
2) &update system...& # 弹出元素所属的值
为什么要阻塞版本的pop呢，主要是为了避免轮询。举个简单的例子如果我们用list来实现一个工作队列。执行任务的thread可以调用阻塞版本的pop去获取任务这样就可以避免轮询去检查是否有任务存在。当任务来时候工作线程可以立即返回，也可以避免轮询带来的延迟。
[html] view plaincopy
常用命令：
sadd,srem,spop,sdiff ,smembers,sunion 等。
应用场景：
Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。
比如在微博应用中，每个人的好友存在一个集合（set）中，这样求两个人的共同好友的操作，可能就只需要用求交集命令即可。
Redis还为集合提供了求交集、并集、差集等操作，可以非常方便的实
实现方式：
set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
[html] view plaincopy
5、Sorted set
常用命令：
zadd,zrange,zrem,zcard等
使用场景：
以某个条件为权重，比如按顶的次数排序.
ZREVRANGE命令可以用来按照得分来获取前100名的用户，ZRANK可以用来获取用户排名，非常直接而且操作容易。
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,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。
[html] view plaincopy
6、 Pub/Sub
Pub/Sub 从字面上理解就是发布（Publish）与订阅（Subscribe），在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，
当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息，比如普通的即时聊天，群聊等功能。
客户端1：subscribe rain
客户端2：PUBLISH rain &my love!!!&
(integer) 2 代表有几个客户端订阅了这个消息
transaction
[html] view plaincopy
7、Transactions
谁说NoSQL都不支持事务，虽然Redis的Transactions提供的并不是严格的ACID的事务（比如一串用EXEC提交执行的命令，在执行中服务器宕机，那么会有一部分命令执行了，剩下的没执行），但是这个Transactions还是提供了基本的命令打包执行的功能（在服务器不出问题的情况下，可以保证一连串的命令是顺序在一起执行的，中间有会有其它客户端命令插进来执行）。
Redis还提供了一个Watch功能，你可以对一个key进行Watch，然后再执行Transactions，在这过程中，如果这个Watched的值进行了修改，那么这个Transactions会发现并拒绝执行。
redis 127.0.0.1:6379& get age
redis 127.0.0.1:6379& watch age
redis 127.0.0.1:6379& multi
redis 127.0.0.1:6379&
redis 127.0.0.1:6379& set age 30
redis 127.0.0.1:6379& get age
redis 127.0.0.1:6379&
redis 127.0.0.1:6379& set age 20
redis 127.0.0.1:6379& exec
redis 127.0.0.1:6379& get age
redis 127.0.0.1:6379&
第一步，Session 1 还没有来得及对age的值进行修改
　　第二步，Session 2 已经将age的值设为30
　　第三步，Session 1 希望将age的值设为20，但结果一执行返回是nil，说明执行失败，之后我们再取一下age的值是30，这是由于Session 1中对age加了乐观锁导致的。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'}