保存图片的例子，除了用String和Hash存储之外，还可以用Sorted Set存储（勉强）。 Sorted Set与Hash类似，当元素数量少于zset-max-ziplist-entries，并且每个元素内存占用小于zset-max-ziplist-value时，默认也采用ziplist结构存储。我们可以把zset-max-ziplist-entries参数设置为1000，这样Sorted Set默认就会使用ziplist存储了，member和score也会紧凑排列存储，可以节省内存空间。 使用zadd 1101000 3302000080 060命令存储图片ID和对象ID的映射关系，查询时使用zscore 1101000 060获取结果。 但是Sorted Set使用ziplist存储时的缺点是，这个ziplist是需要按照score排序的（为了方便zrange和zrevrange命令的使用），所以在插入一个元素时，需要先根据score找到对应的位置，然后把member和score插入进去，这也意味着Sorted Set插入元素的性能没有Hash高（这也是前面说勉强能用Sorte Set存储的原因）。而Hash在插入元素时，只需要将新的元素插入到ziplist的尾部即可，不需要定位到指定位置。 不管是使用Hash还是Sorted Set，当采用ziplist方式存储时，虽然可以节省内存空间，但是在查询指定元素时，都要遍历整个ziplist，找到指定的元素。所以使用ziplist方式存储时，虽然可以利用CPU高速缓存，但也不适合存储过多的数据（hash-max-ziplist-entries和zset-max-ziplist-entries不宜设置过大），否则查询性能就会下降比较厉害。整体来说，这样的方案就是时间换空间，我们需要权衡使用。 当使用ziplist存储时，我们尽量存储int数据，ziplist在设计时每个entry都进行了优化，针对要存储的数据，会尽量选择占用内存小的方式存储（整数比字符串在存储时占用内存更小），这也有利于我们节省Redis的内存。还有，因为ziplist是每个元素紧凑排列，而且每个元素存储了上一个元素的长度，所以当修改其中一个元素超过一定大小时，会引发多个元素的级联调整（前面一个元素发生大的变动，后面的元素都要重新排列位置，重新分配内存），这也会引发性能问题，需要注意。 另外，使用Hash和Sorted Set存储时，虽然节省了内存空间，但是设置过期变得困难（无法控制每个元素的过期，只能整个key设置过期，或者业务层单独维护每个元素过期删除的逻辑，但比较复杂）。而使用String虽然占用内存多，但是每个key都可以单独设置过期时间，还可以设置maxmemory和淘汰策略，以这种方式控制整个实例的内存上限。 所以在选用Hash和Sorted Set存储时，意味着把Redis当做数据库使用，这样就需要务必保证Redis的可靠性（做好备份、主从副本），防止实例宕机引发数据丢失的风险。而采用String存储时，可以把Redis当做缓存使用，每个key设置过期时间，同时设置maxmemory和淘汰策略，控制整个实例的内存上限，这种方案需要在数据库层（例如MySQL）也存储一份映射关系，当Redis中的缓存过期或被淘汰时，需要从数据库中重新查询重建缓存，同时需要保证数据库和缓存的一致性，这些逻辑也需要编写业务代码实现。 总之，各有利弊，我们需要根据实际场景进行选择。

一，作者讲了什么？ Redis的String类型数据结构，及其底层实现 二，作者是怎么把这事给说明白的？ 1，通过一个图片存储的案例，讲通过合理利用Redis的数据结构，降低资源消耗 三，为了讲明白，作者讲了哪些要点？有哪些亮点？ 1，亮点1：String类型的数据占用内存，分别是被谁占用了 2，亮点2：可以巧妙的利用Redis的底层数据结构特性，降低资源消耗 3，要点1： Simple Dynamic String结构体（ buf：字节数组，为了表示字节结束，会在结尾增加“\0” len： 占4个字节，表示buf的已用长度 alloc：占4个字节，表示buf实际分配的长度，一般大于len） 4，要点2： RedisObject 结构体（ 元数据：8字节（用于记录最后一次访问时间，被引用次数。。。） 指针：8字节，指向具体数据类型的实际数据所在 ） 5，要点3：dicEntry 结构体（ key：8个字节指针，指向key value：8个字节指针，指向value next：指向下一个dicEntry） 6，要点4：ziplist(压缩列表)（ zlbytes：在表头，表示列表长度 zltail：在表头，表示列尾偏移量 zllen：在表头，表示列表中 entry：保存数据对象模型 zlend：在表尾，表示列表结束） entry：（ prev_len：表示一个entry的长度，有两种取值方式：1字节或5字节。 1字节表示一个entry小于254字节，255是zlend的默认值，所以不使用。 len：表示自身长度，4字节 encodeing：表示编码方式，1字节 content：保存实际数据） 5，要点4：String类型的内存空间消耗 ①，保存Long类型时，指针直接保存整数数据值，可以节省空间开销（被称为：int编码） ②，保存字符串，且不大于44字节时，RedisObject的元数据，指针和SDS是连续的，可以避免内存碎片（被称为：embstr编码） ③，当保存的字符串大于44字节时，SDS的数据量变多，Redis会给SDS分配独立的空间，并用指针指向SDS结构（被称为：raw编码） ④，Redis使用一个全局哈希表保存所以键值对，哈希表的每一项都是一个dicEntry，每个dicEntry占用32字节空间 ⑤，dicEntry自身24字节，但会占用32字节空间，是因为Redis使用了内存分配库jemalloc。 jemalloc在分配内存时，会根据申请的字节数N，找一个比N大，但最接近N的2的幂次数作为分配空间，这样可以减少频繁分配内存的次数 4，要点5：使用什么数据结构可以节省内存？ ①， 压缩列表，是一种非常节省内存的数据结构，因为他使用连续的内存空间保存数据，不需要额外的指针进行连接 ②，Redis基于压缩列表实现List，Hash，Sorted Set集合类型，最大的好处是节省了dicEntry开销 5，要点6：如何使用集合类型保存键值对？ ①，Hash类型设置了用压缩列表保存数据时的两个阀值，一旦超过就会将压缩列表转为哈希表，且不可回退 ②，hash-max-ziplist-entries：表示用压缩列表保存哈希集合中的最大元素个数 ③，hash-max-ziplist-value：表示用压缩列表保存时，哈希集合中单个元素的最大长度 四，对于作者所讲，我有哪些发散性思考？ 看了老师讲解，做了笔记，又看了黄建宏写的《Redis 设计与实现》 有这样的讲解： 当哈希对象可以同时满足以下两个条件时， 哈希对象使用 ziplist 编码： 1. 哈希对象保存的所有键值对的键和值的字符串长度都小于 64 字节； 2. 哈希对象保存的键值对数量小于 512 个； 五，在将来的哪些场景中，我能够使用它？ 这次学习Redis数据结构特性有了更多了解，在以后可以更加有信心根据业务需要，选取特定的数据结构