Redis其实能存各种数据，感觉它存东西挺灵活的，你想要啥都能放进去

“Redis其实能存各种数据，感觉它存东西挺灵活的，你想要啥都能放进去”这个说法，其实非常形象地概括了Redis给很多开发者带来的第一印象，它不像传统的关系型数据库，比如MySQL，需要你先严格地定义好表格结构，每个字段是什么类型、多长，都规定得死死的，Redis更像是一个超级灵活的大仓库，或者说得更贴切一点，像一个有很多种不同规格储物格的万能储物柜，你不需要事先申请说“我要一个放书本的格子”，而是直接拿着东西过来，看它适合放哪个格子,就塞进哪个格子里去。

这种灵活性主要来源于Redis支持的不同“数据结构”，咱们可以不用管“数据结构”这个听起来有点专业的词，就把它理解成存放数据的不同方式或者不同形状的容器，Redis提供了好几种这样的容器,所以你存各种各样品类的东西就感觉很顺手。

最基础的容器就是“字符串”（String），这个很好理解，就是能存一段文本，比如一句话、一个验证码、或者用户的昵称，但Redis的字符串容器厉害之处在于，它也能很轻松地存数字，并且能直接让你对数字进行加减操作，比如用来做文章点赞数、商品库存的计数就特别方便，你说“给这篇文章的点赞数加1”，Redis直接就能办到，你不用先把数字读出来，在程序里加好,再存回去那么麻烦。

然后是一个叫“哈希”（Hash）的容器，这个容器特别适合存放一个对象的多个属性，比如你要存一个用户的信息，有用户名、年龄、城市、签名等等，如果你用多个字符串来存，就得存好几个键，管理起来不方便，但用哈希容器，就好像一个文件夹，你可以把这个用户的所有信息都放在这个文件夹里，每个属性有一个小标签（字段名）对应，这样你取数据的时候，可以一次性拿走整个文件夹，也可以只拿出其中一个属性的小纸条看看,非常灵活有序。

还有一个很常用的容器叫“列表”（List），这个容器就像排队一样，数据一个接一个地放进去，它是有顺序的，你可以从队伍左边加人，也可以从右边加人，这种特性让它特别适合做那种需要保持顺序的东西，比如消息队列，用户A发了条消息，从左边塞进队伍；用户B发了条消息，也跟着排进去，另一边，处理消息的程序从队伍右边一个一个取出来处理，保证先来的先被处理,不会乱套。

与列表有点像但用途不同的是“集合”（Set），这个容器最大的特点就是里面的元素是不允许重复的，而且没有顺序之分，它就像是一个装独特小球的袋子，你往里面放两个一模一样的小球，它最终也只会有一个，这个特性用来存一些需要去重的东西非常棒，比如文章的所有标签，同一个标签你存多少次都只会有一个；或者存某个活动的参与用户ID,可以自动保证不会重复记录。

在集合的基础上，还有一个“有序集合”（ZSet），这个就更强大了，它像是一个带排行榜的集合，集合里的每个元素都有一个分数（score）跟着，Redis会根据这个分数来给所有元素从小到大排序，这简直就是为排行榜功能量身定做的，比如游戏里的玩家积分榜，玩家的ID是元素，他的积分就是分数，你直接就能取出分数最高的前十名玩家,非常简单高效。

除了这些标准的容器，Redis还能存一种不太一样的东西，叫“位图”（Bitmap），它不是用来存我们平时理解的图片的，而是通过操作二进制位（0和1）来实现一些特殊功能，比如你想记录用户一年365天的签到情况，签到了就是1，没签就是0，如果你用普通的字符串，可能得存365个键值对，但用位图，可能只需要很短的存储空间，就能高效地记录和查询（比如查询用户今年连续签到了多少天），虽然这个概念可能稍微绕一点,但它展示了Redis在存储形式上确实可以非常巧妙和节省空间。

还有一种叫“HyperLogLog”的容器，它是专门用来做基数统计的，说白了就是估算一个集合中不重复元素的个数，比如统计一个网页一天的独立访客数（UV），它的最大优点是，即使用来统计上亿个数据，也只需要占用非常小的固定内存空间，虽然结果是个近似值不是100%精确，但在很多大数据量的场景下,用微小的误差换取巨大的内存节省是非常划算的。

回过头来看“Redis其实能存各种数据，感觉它存东西挺灵活的，你想要啥都能放进去”这句话，它确实捕捉到了Redis的核心优势之一，正是因为它提供了字符串、哈希、列表、集合、有序集合、位图、HyperLogLog等多种多样的“储物容器”，开发者可以根据自己要存的数据的特点和访问方式，选择最合适的那一个来用，这种基于数据结构的灵活性，使得Redis能够轻松应对字符串缓存、对象存储、消息队列、排行榜、计数器、社交关系、实时系统等五花八门的业务场景，给人一种“啥都能装”的利落感，这种灵活性也要求使用者对每种容器的特性和适用场景有基本的了解,这样才能真正地把Redis的威力发挥出来。