Redis数据结构和操作redis不只是一个简单的键(key)-值(value)数据库，实际上它是一个数据结构服务器，支持各种类型的值。也就是说，在传统的键-值数据库中，你把字符串键与字符串值联系起来，而在redis，值不仅限于一个简单的字符串，还可以是更复杂的数据结构。下面列出了所有redis支持的数据结构，下文会分别对这些结构进行介绍：二进制安全字符串队列(lists)：基于插入顺序有序存储的字符串元素集合。主要是链式的list。集(sets)：元素唯一的、无序的字符串元素集合。有序集(sortedsets)：与sets相似，但是每个字符串元素都与一个被称为分数(score)的浮点数相关联。和sets不同的是，元素能够基于分数排序，因此可以检索某个范围内的元素（比如你可以查询前10个或后10个）。哈希(hashes)：由域(fields)和值之间关系组成的映射。域和值都是字符串。这和Ruby或Python的哈希非常相似。位数组（位图bitmaps）：可以通过特殊命令，像处理位图一样地处理字符串：设置和清除某一位，统计被置1的位数，找到第一个被设置或没有被设置的位等。HyperLogLogs：这是一种概率数据结构，用于估算集的势。不要被吓到了，没那么难。本文将在下文中HyperLogLog章节介绍。遇到问题的时候，理解数据结构是怎么工作的以及怎么被使用的并不是那么微不足道的事情。因此，这篇文档是一个关于Redis数据类型和它们常用模式的速成教材。这里所有的例子，我们都使用redis客户端（redis-cli）。相对于redis服务器来说，这是一个简单方便的命令行控制台。redis的键redis的键是二进制安全【1】的，也说是说，你可以使用任意的二进制序列作为键，比如字符串”foo”或一个JPEG文件的内容。空串也是一个有效的键。一些关于键的其它规则：太长的键不推荐。例如长度为1024字节的键并不好，不管是从内存角度，还是从查询键的角度。因为从数据集中查询键需要多次的键匹配步骤。即使手边的任务就是要判断一个很大的值是否存在，采用某种手段对它做hash是个好主意，尤其是从内存和带宽的角度去考虑。太短的键通常也不推荐。如果你把键“user:1000:followers”写成“u1000flw”可能会有点问题。因为前者可读性更好，而只需要多花费一点点的空间。短的键显然占的花费的空间会小一点，因此你需要找到平衡点。尽量坚持模式。例如”object-type:id”是推荐的，就像”user:1000”。点和短线常用于多个单词的场景，比如”comment:1234:reply.to”或”comment:1234:reply-to”...
