Redis 数据结构使用场景介绍

　　Redis不只是一个简单的键(key)-值(value)数据库，实际上它是一个数据结构服务器，支持各种类型的值。也就是说，在传统的键-值数据库中，你把字符串键与字符串值联系起来，而在redis，值不仅限于一个简单的字符串，还可以是更复杂的数据结构。下面列出了所有redis支持的数据结构，下文会分别对这些结构进行介绍：

　　1.二进制安全字符串

　　2.队列(lists)：基于插入顺序有序存储的字符串元素集合。主要是链式的list。

　　3.集(sets)：元素唯一的、无序的字符串元素集合。

　　4.有序集(sortedsets)：与sets相似，但是每个字符串元素都与一个被称为分数(score)的浮点数相关联。和sets不同的是，元素能够基于分数排序，因此可以检索某个范围内的元素（比如你可以查询前10个或后10个）。

　　5.哈希(hashes)：由域(fields)和值之间关系组成的映射。域和值都是字符串。这和Ruby或Python的哈希非常相似。

　　6.位数组（位图bitmaps）：可以通过特殊命令，像处理位图一样地处理字符串：设置和清除某一位，统计被置1的位数，找到第一个被设置或没有被设置的位等。

　　7.HyperLogLogs：这是一种概率数据结构，用于估算集的势。不要被吓到了，没那么难。本文将在下文中HyperLogLog章节介绍。

　　遇到问题的时候，理解数据结构是怎么工作的以及怎么被使用的并不是那么微不足道的事情。因此，这篇文档是一个关于Redis数据类型和它们常用模式的速成教材。

　　这里所有的例子，我们都使用redis客户端（redis-cli）。相对于redis服务器来说，这是一个简单方便的命令行控制台。

　　下面我们就来简单说明一下它们各自的使用场景：

　　redis的键

　　redis的键是二进制安全【1】的，也说是说，你可以使用任意的二进制序列作为键，比如字符串”foo”或一个JPEG文件的内容。

　　空串也是一个有效的键。

　　一些关于键的其它规则：

　　1.太长的键不推荐。例如长度为1024字节的键并不好，不管是从内存角度，还是从查询键的角度。因为从数据集中查询键需要多次的键匹配步骤。即使手边的任务就是要判断一个很大的值是否存在，采用某种手段对它做hash是个好主意，尤其是从内存和带宽的角度去考虑。

　　2.太短的键通常也不推荐。如果你把键“user:1000:followers”写成“u1000flw”可能会有点问题。因为前者可读性更好，而只需要多花费一点点的空间。短的键显然占的花费的空间会小一点，因此你需要找到平衡点。

　　3.尽量坚持模式。例如”object-type:id”是推荐的，就像”user:1000”。点和短线常用于多个单词的场景，比如”comment:1234:reply.to”或”comment:1234:reply-to”。

　　4.键的大小不能超过512MB。

　　String——字符串

　　String数据结构是简单的key-value类型，value不仅可以是String，也可以是数字（当数字类型用Long可以表示的时候encoding就是整型，其他都存储在sdshdr当做字符串）。使用Strings类型，可以完全实现目前Memcached的功能，并且效率更高。还可以享受Redis的定时持久化（可以选择RDB模式或者AOF模式），操作日志及Replication等功能。除了提供与Memcached一样的get、set、incr、decr等操作外，Redis还提供了下面一些操作：

　　1.LENniushuai：O(1)获取字符串长度

　　2.APPENDniushuairedis：往字符串append内容，而且采用智能分配内存（每次2倍）

　　3.设置和获取字符串的某一段内容

　　4.设置及获取字符串的某一位（bit）

　　5.批量设置一系列字符串的内容

　　6.原子计数器

　　7.GETSET命令的妙用，请于清空旧值的同时设置一个新值，配合原子计数器使用

　　Hash——字典

　　在Memcached中，我们经常将一些结构化的信息打包成hashmap，在客户端序列化后存储为一个字符串的值（一般是JSON格式），比如用户的昵称、年龄、性别、积分等。这时候在需要修改其中某一项时，通常需要将字符串（JSON）取出来，然后进行反序列化，修改某一项的值，再序列化成字符串（JSON）存储回去。简单修改一个属性就干这么多事情，消耗必定是很大的，也不适用于一些可能并发操作的场合（比如两个并发的操作都需要修改积分）。而Redis的Hash结构可以使你像在数据库中Update一个属性一样只修改某一项属性值。

　　1.存储、读取、修改用户属性

　　List——列表

#p#分页标题#e#

　　List说白了就是链表（redis使用双端链表实现的List），相信学过数据结构知识的人都应该能理解其结构。使用List结构，我们可以轻松地实现最新消息排行等功能（比如新浪微博的TimeLine）。List的另一个应用就是消息队列，可以利用List的*PUSH操作，将任务存在List中，然后工作线程再用POP操作将任务取出进行执行。Redis还提供了操作List中某一段元素的API，你可以直接查询，删除List中某一段的元素。

　　1.微博TimeLine

　　2.消息队列

　　Set——集合

　　Set就是一个集合，集合的概念就是一堆不重复值的组合。利用Redis提供的Set数据结构，可以存储一些集合性的数据。比如在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。因为Redis非常人性化的为集合提供了求交集、并集、差集等操作，那么就可以非常方便的实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。

　　1.共同好友、二度好友

　　2.利用唯一性，可以统计访问网站的所有独立IP

　　3.好友推荐的时候，根据tag求交集，大于某个threshold就可以推荐

　　SortedSet——有序集合

　　和Sets相比，SortedSets是将Set中的元素增加了一个权重参数score，使得集合中的元素能够按score进行有序排列，比如一个存储全班同学成绩的SortedSets，其集合value可以是同学的学号，而score就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序。另外还可以用SortedSets来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

　　带有权重的元素，比如一个游戏的用户得分排行榜

　　比较复杂的数据结构，一般用到的场景不算太多

　　二、redis其他功能使用场景

　　订阅-发布系统

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

　　事务——Transactions

　　谁说NoSQL都不支持事务，虽然Redis的Transactions提供的并不是严格的ACID的事务（比如一串用EXEC提交执行的命令，在执行中服务器宕机，那么会有一部分命令执行了，剩下的没执行），但是这个Transactions还是提供了基本的命令打包执行的功能（在服务器不出问题的情况下，可以保证一连串的命令是顺序在一起执行的，中间有会有其它客户端命令插进来执行）。Redis还提供了一个Watch功能，你可以对一个key进行Watch，然后再执行Transactions，在这过程中，如果这个Watched的值进行了修改，那么这个Transactions会发现并拒绝执行。

　　题外话：如何为字符串获取唯一标识

　　在标签的例子里，我们用到了标签ID，却没有提到ID从何而来。基本上你得为每个加入系统的标签分配一个唯一标识。你也希望在多个客户端同时试着添加同样的标签时不要出现竞争的情况。此外，如果标签已存在，你希望返回他的ID，否则创建一个新的唯一标识并将其与此标签关联。

　　Redis1.4将增加Hash类型。有了它，字符串和唯一ID关联的事儿将不值一提，但如今我们如何用现有Redis命令可靠的解决它呢？

　　我们首先的尝试（以失败告终）可能如下。假设我们想为标签“redis”获取一个唯一ID：

　　1.为了让算法是二进制安全的（只是标签而不考虑utf8，空格等等）我们对标签做SHA1签名。

　　2.检查这个标签是否已与一个唯一ID关联，

　　用命令GETtag:b840fc02d524045429941cc15f59e41cb7be6c52:id

　　3.如果上面的GET操作返回一个ID，则将其返回给用户。标签已经存在了。

　　4.否则…用INCRnext.tag.id命令生成一个新的唯一ID（假定它返回123456）。

　　5.最后关联标签和新的ID，并将新ID返回给调用者。

　　小编结语：

　　更多内容尽在课课家教育！