redis

前情提要：Redis 最佳设计 Top 9

Redis 是一个非常优秀的数据库，既然有好设计，那有没有不合理的设计呢？

答案当然是有的，本文章并不是打算批评设计的如何如何，而且许多设计放在当时可能是合理的，也可能因为背了历史负担导致原有的不合理设计难以改动，文章单纯属图一乐。

ziplist

ziplist 会出现联级更新问题，后续开发出了新的 listpack 来替代，相比新的 listpack：

• 不需要联级更新
• 减掉了一个字段的使用

但是由于出现联级更新的可能性实在是太小了，而且新数据结构节省的空间并没有那么明显，如果把现有的 ziplist 替换成 listpack 风险太大了，所以只在 stream 里用到了。

PS：看起来已经弃用了，在 Redis 7.0 中，加载旧的 RDB 格式时会动态的把 ziplist 编码的 key 转换为 listpacks。

RESP

RESP 是 Redis 的通信协议，和 HTTP 一样都是文本协议，协议以 \r\n 结尾。

• 单行字符串以 + 符号开头。
• 错误消息以 - 符号开头。
• 整数值以 : 符号开头，后跟整数的字符串形式。
• 多行字符串 以 $ 符号开头，后跟字符串长度。
• 数组 以 * 号开头，后跟数组的长度。

RESP 的优点：

• 实现方便
• 解析速度快
• 可读性好

可以看得出来优点其实都是站在 Redis 开发者角度的，对于用户其实没有这么关系这些点。可能是因为作者一开始感觉这样就够用了，如果可以重新设计估计会也会给改成二进制协议（你看隔壁 HTTP 2.0 就是二进制的了）。

位图操作

可能是我没 get 到那个点，无法理解为什么 set 是以字节为单位操作的，但是获取的时候需要通过字节的索引来获取。bitcount 的设计确实令人不解，至少应该提供可选的按照 bit 为 index 的命令。如果有懂哥可以给我科普一下。

select db

这个设计毫无意义，不仅集群只支持 db0，而且在使用过程中非常容易切错数据库导致数据写入出问题。

连作者都认为这个是个烂设计了，只不过因为历史原因有人已经在用了不好做改动。希望后续能删除这个功能吧。

本文由 鸡米 创作，采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: Apr 25,2022