1. 概述
Redis 不是一个简单的 key-value 存储，实际上它是一个数据结构服务器，并且支持不同种类的值。这意味着，在传统的 key-value 存储中key 和 value 的数据类型都是 string 的，然而在 Redis 中，值不仅仅限制为简单的字符串，它也可以包含复杂的数据结构。
2. 数据类型及简介
下面是 Redis 支持的数据结构的列表，在后续的教程里面将会分开介绍：
1. 二进制安全的字符串
2. List：根据插入顺序排序的字符串元素的集合。他们是简单的 linked list ；
3. Sets：唯一的、未排序的字符串元素的集合；
4. Sorted Set：它与 Sets 是非常相似的，不过它的所有的字符串元素都与一个被称作分数(score) 的浮点的数字值相关联。这些元素总是按照他们的分数进行排序，所以不像 Sets 一样可以检索一个区间的元素（比如你会说：给我前10个或者最后10）；
5. Hashes：它是由有相对应的值的字段组成的maps。字段和值都是字符串。这个与Ruby 或者 Python 中是非常相似的；
6. Bit array：或者说是简单的位图（bitmaps），它是你可以使用特定的命令像位数组(array of bits)一样处理字符串：你可以设置或者清空单个位，统计所有的设置为1的位的数量，查找第一个设置或者未设置的位等等；
7. HyperLogLogs：这是概率估计数据结构，用于估计一个集合的基数。不要害怕，它比它看起来要简单 ...
3. Redis 的键
Redis 的键是二进制安全的，这意味着你可以使用任何二进制序列作为键值，无论是类似于“foo”的字符串还是一个 JPEG 文件的内容。空字符串也是一个合法的键。
关于键值的一些其他规则：
- 不要使用非常长的key：例如一个一个1024 字节的键是非常糟糕的，这不仅仅是由于内存的考虑，而且也由于在数据集里的键的查找可能需要一些昂贵的键的比较操作。即使这个任务只是匹配一个大值的存在，使用哈希处理重排序（比如使用SHA1）是一个更好的做法，特别是对于关注与内存和带宽的时候。
- 非常短的key也不是一个好的做法。如果你可以取而代之使用“user:1000:followers” 的话，没有理由使用“u1000flw”作为键。前者中，与值相比较，键所多战的内存空间是有限的；然而后者明显的消耗的内存要少一些。因此，你的工作就好在二者之间做一个衡量。
- 严格遵守一个模式。例如 “object-type:id” 是一个非常好的做法例如“user:1000” 。点符号或者短划线常常用于多词的字段，例如 “comment:1234:reply.to” 或者 “comment:1234:reply-to” 。
哎，今天就先学这么多把，其实我也是在逐步的学习过程中，现在也是想更加系统的学习一下。不知不觉现在已经 00:30 了，还是睡觉把，明天还得起来搬砖呢～
哦，对了，下面依然是我建的一个公众帐号，是脱离于咱们码农行业的，可以关注一下哦，哈哈
