《Redis 核心技术与实战》学习笔记 06

学习极客时间《Redis 核心技术与实战》专栏过程中的一些学习笔记，部分已经作为留言发布，但是留言太多，排在后面的一般很难被大家看到，所以集中发布在这里，欢迎讨论。

题图来自极客时间《Redis 核心技术与实战》专栏

11 | “万金油”的 String，为什么不好用了？

String 类型并不适用于所有场合，保存数据时所消耗的内存空间比较多，那么内存消耗到哪里了？

为什么 Long 类型是 8 个字节？我以前的印象应该是 4 个字节，查了一下大概是因为是 64 位的操作系统。

String 类型保存图片 ID （10 位）和图片存储对象 ID（10 位）时，采用 SDS 结构

• 全局哈希表 dictEntry 三个指针 24 字节，jemalloc 分配 32 字节

• 每个 int 编码的 RedisObject 元数据 8 字节，指针 8 字节

• 每个 ID 16 字节

采用压缩列表来保存图片存储对象 ID

• 图片存储对象 ID 8 字节

• 每个 entry 的 prev_len 1 字节

• 每个 entry 的 len 4 字节

• 每个 entry 的 encoding 1 字节

内存占用 14 字节，分配 16 字节（jemalloc?）

试着在阿里云的 Redis 上执行了 hset 命令，没有得到预想中的结果，可能是和云服务器有关。

在这一篇中，其实把图片 ID 和 图片存储对象 ID 拆分成 7+3+10 ，前 7 位作为 Hash 类型的键，中间 3 位（图片 ID 的最后 3 位）和后 10 位（图片存储对象 ID）分别作为 Hash 类型值中的 key 和 value 才是更为关键的地方。

不知道是哪一位英雄首先想到的这个解决方案。

对于课后题，按照同样的思路，使用 List 或者 SortedSet 应该也能节省空间，用 List 会不会相对好一些，同样可以采用二级索引的方式。

看了一下课代表的留言，发现自己猜错了方向，等着看老师阶段答疑的解释。另外对于 String 类型的优缺点分析，也很精彩。