问题
首先，你需要了解Redis的数据类型，这样才能够为特定的应用提供更好的Redis使用方式和性能。
解决方法
和大部分其他的NoSQL方案和key-value存储引擎不同，Redis包含一些内建的数据类型，允许开发者可以使用有意义的语义方式来构建他们的数据。在Redis内部操作指定类型的数据时，预定义的数据类型一般会比外部定义数据类型要操作更快。
讨论
在我们深入特定的数据类型之前，先来了解一些在设计Key数据结构的时候需要关注的事情：
- 定义
key空间时需要一致。由于一个key可以包含任意的字符，你可以使用分隔符去为自己的业务定义有意义的命名。例如：cache:project:319:tasks，每一个冒号就是一个命名分隔符。 - 当定义自己的
key时，尝试限制合适的大小。从存储中检索一个key是需要比较操作的，所以保证key长度足够的小是一个很好的建议。此外，更小的key长度还会节省内存的使用。 - 即使
key不能够特别的大，但是保持特别小的key并不会带来非常大的性能提升。这意味着，你设计自己的key时需要综合考虑key的易读性和正常的键长度。
因此，当键设计成c:p:319:t或者user 123是相当失败的，前面一个可读性很差，后面一个包含空格。另一方面，像cache:project:319:tasks，lastchatmessage，464A1E96B2D217EBE87449FA8B70E6C7D112560C的key都是很好的，因为他们都是有语义的词（最后一个是SHA1哈希值，虽然很难猜测他的语义，但是这对于存储了对应的对象，你就可以计算出hash值了）。
Strings
这是Redis里面最简单的数据类型：字符串。Strings也是其他key-value存储引擎中典型的数据类型。你可以存储任意类型的字符串，包括二进制数据。比如：你可能想要为社交网络中的头像缓存图片数据。你需要考虑的唯一一件事情就是在Redis里面不允许特定的值大小超过512M。
Lists
在Redis存储里面， Lists是一个有序的二进制安全的字符串列表，使用linked list来实现。这意外者，当通过一个指定的索引获取元素的时候，会是一个很慢的操作，但是在这个数据结构的头部或者尾部增加元素是非常快的。你可能想要基于Lists去实现queues之类的数据结构。关于这点，后文会说到。
Hashes
和传统的hash表很像，在Redis中hashes在特定的key里面存储一些fields和他们对应的值。hashes是需要映射复杂对像的完美选项，通过使用对象属性的fields（比如一个对象有多个属性：“color”,“brand”, “license plate”）。
Sets and Sorted Sets
在Redis中，sets是一个无序的二进制安全的字符串集合。在给定的set中是不存在重复的元素的。比如，当你尝试在一个set中添加两次wheel时，Redis会忽略第二次插入操作。sets允许你执行传统语言中set的相关操作，比如获取集合的交集和并集。
虽然这个和lists看起来很相似，但是他们实现是非常不同的，并且由于他们不同的特性而决定适应不同的应用需求。此外，set的内存占用要比lists高一些。
Sorted sets是sets的特例，通过定义score来实现排序，此外也是经典的二进制安全字符串。这个score允许你通过使用ZRANGE命令查询一个有序的元素列表。后面，会介绍一些关于sets and sorted sets的使用实例。