Redis储存模式那些事儿，简单聊聊它到底是怎么存数据的

说到Redis的储存模式，咱们可以把它想象成一个超级能干、但记东西方式有点特别的“闪电侠”，它不像我们常见的MySQL那种数据库，非得用表格一行一行、整整齐齐地存数据，Redis的秘诀在于，它为了追求极致的速度，用了非常灵活多样的“小本本”来记录不同类型的信息，每种“小本本”的记法都针对特定的用途做了优化，这就是它的核心——“键值对”储存，但“值”的花样特别多。

（来源：Redis官方文档对数据结构的介绍）

第一本小本本：字符串（String） 这是最简单、最常用的一本，你就把它理解成一张张便利贴，一个钥匙（Key）对应一个值（Value），这个值可以是文字、数字，甚至是图片的二进制数据，你想存用户“张三”的在线状态，钥匙就是“user:zhangsan:status”，值就是“online”，或者你想做个网站计数器，钥匙是“website:visits”，值就是数字“1024”，它特别适合存一些简单的、需要快速读写的信息。

第二本小本本：哈希（Hash） 这个有点像我们填写的个人档案表，一个钥匙对应了一张表，这张表里面又可以有很多个字段（Field）和对应的值（Value），你要存用户“张三”的完整信息，如果用字符串，可能得存成“user:zhangsan:name”、“user:zhangsan:age”好几个钥匙，很麻烦，但用哈希，一个钥匙“user:zhangsan”就够了，它的值是一张表，里面有“name: 张三”、“age: 30”、“city: 北京”等多个字段，这样当你需要获取、修改用户的某一部分信息时，效率非常高,不用动整个数据。

第三本小本本：列表（List） 这个就是名副其实的清单列表，特点是按顺序来，它像一个只有一头开口的竹筒（或者两头都能操作），你可以从左边或者右边把新元素一个个塞进去，你要做一个微博的时间线，钥匙是“user:123:timeline”，你可以把新发的微博ID从左边塞进这个列表，当用户查看时间线时，就从左边按顺序取出最新的N条，它非常适合用来做消息队列、最新列表等需要保持顺序的场景。

第四本小本本：集合（Set） 这个集合的特点就是“独一无二”和“无序”，它就像一个装了很多小球的袋子，你往里面放球，但每个编号的球只能放一个（自动去重），而且袋子里的球是没有固定顺序的，这有什么用呢？你想记录一篇文章的所有点赞用户ID，钥匙是“article:1001:likes”，你可以把用户ID一个个加进去，完全不用担心同一个用户重复点赞，你还可以很方便地求出两篇文章的共同点赞用户（求两个集合的交集）,社交网络里的共同好友功能底层就经常这么干。

第五本小本本：有序集合（Sorted Set / ZSet） 这是集合的升级版，它给每个元素都绑定了一个分数（Score），然后根据这个分数来给元素从小到大排序，它就像一个排行榜，钥匙是“leaderboard”，值是一系列成员和他们的分数，PlayerA: 5000”, “PlayerB: 7000”，这样，你可以很快地查出分数最高的前10名玩家，或者查询某个玩家的具体排名，游戏排行榜、带热度的新闻列表都非常适合用它。

（来源：对Redis五种核心数据结构的通用解读）

Redis是怎么让存取这么快的？ 这就得说到它另一个关键选择了：内存储存，Redis把所有这些“小本本”上的数据都直接放在服务器的内存（RAM）里，我们知道，从内存里读数据比从硬盘上读要快成千上万倍，这就像是你要查资料，直接从手边的抽屉里拿（内存），还是跑去图书馆的书架上找（硬盘）的区别，只放内存的话，一断电数据就没了，所以Redis也有持久化机制，比如定期给内存里的数据拍个快照存到硬盘上（RDB），或者把所有写操作命令都记录在一个日志文件里（AOF），这样重启后可以重新执行一遍命令来恢复数据,在速度和数据安全之间取得平衡。

（来源：对Redis基于内存特性和持久化机制的普遍技术解释）

Redis的储存模式精髓就是“对症下药”，它不强迫所有数据都住进一样的“房子”里，而是提供了好几种精心设计的“小仓库”，你需要存简单键值就用String，存对象就用Hash，要保证顺序就用List，需要去重和集合运算就用Set，要做排行榜就用Sorted Set，这种专门化的设计，再加上内存带来的闪电速度,共同造就了Redis在数据处理上的高性能。