Redis 核心技术与实战 学习笔记 02

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

题图来自于专栏插图

02 | 数据结构：快速的 Redis 有哪些慢操作？

Redis 的快（微妙级）一是因为内存，而是因为数据结构。

Redis → 哈希表/哈希桶 → 指针

采用两个全局哈希表，来提高 rehash 的效率，应该算是以空间换时间了；然后用通过渐进式哈希，拉长了 rehash 的时间，或者说降低了频率，分散了拷贝处理。

看到这里感觉和 Elasticsearch 中的一些处理思路上有些相近的地方，发现瓶颈、找到方法、解决问题。Redis 和 Elasticsearch 似乎在底层技术上都没有什么特别的创新，但是在工程应用上的优化做的非常好。

回到隔壁重读了《17 | 跳表：为什么 Redis 一定要用跳表来实现有序集合？》

Redis 中有序跳表的核心操作是插入、删除、查找一个数据，迭代输出有序序列，按照区间查找数据。其中插入、删除、查找一个数据，迭代输出有序序列用红黑树也可以完成，但是区间查找数据还是跳表的效率更高。另外，感觉跳表更容易理解和代码实现。

大部分单元素操作和统计操作只有 O(1) 的时间复杂度，这个是否就是 Redis 崛起的关键？

集合类型的范围操作，最好使用 SCAN，避免全集合遍历；

复杂度较高的 List 类型，POP/PUSH 效率很高，主要用于 FIFO 队列，而不是随机读写；

对于课后题目，整数数组应该是在应用中使用的比较多的一种，所以值得单独拿出来作为底层数据结构；而压缩列表可能是为了节约存储空间考虑，内存虽然一直在降价，但是仍然不便宜。

留言里面 @樱花落花 提到的使用压缩列表可以减少内存碎片，确实是之前没有考虑到的。

有点好奇，为什么这一篇的留言特别多？

03 | 高性能 IO 模型：为什么单线程 Redis 能那么快？

Redis 的网络 IO 和键值对读写是单线程的，而持久化、异步删除、集群数据同步等是由额外的线程执行的（似乎 Redis 6.0 以后，网络 IO 也是多线程了）。那么，是不是把 Redis 理解为单线程、多线程“混动”更好一些。（老师在留言回复里面提到是“单线程的进程”）

Redis 使用单线程，主要是为了避免多线程并发访问控制带来的问题，那么应该也是和使用场景有关的。

Redis 之所以快，首先是因为内存（硬件基础），高效的数据结构，再加上 epoll 多路复用（软件），从某种角度上说应该是“软硬搭配，干活不累”。

bind/listen → accept → recv → parse → get → send

其中 accept 和 recv 是潜在的阻塞点（其他的网络 IO 应该也是一样的）

病人等同于请求，医院的分诊台类似于 Linux 内核监听请求，实际诊断的医生相当于是 Redis 单线程。

对于课后题，在 Redis 基本 IO 模型中，除了 accept 和 recv，send 有可能成为瓶颈么？假设请求的数据又多又大？

看到留言里面有提到 bigkey，但是没有说 bigvalue，看样子我又想歪了，标准答案似乎是事件处理可能会成为瓶颈。