《Redis核心技术与实战》学习总结（1）

【Redis】| 总结/Edison Zhou

0写在开头

作为Key/Value键值数据库，Redis的应用非常广泛。在之前多年的工作生涯中，我也只是关注了零散的技术点，没有对Redis建立起一套整体观，但只有建立了系统整体观，才能更好地定位问题和解决问题，更重要的是应付面试。

刚好，极客时间推出了一门《Redis核心技术与实战》课程，于是我就入手了，这是我的学习总结，化繁为简，只留重点，分享与你。

1KV数据库的基本架构

为了建立系统观，最好的方法就是对其总体架构和关键模块有一个全局认知，因此这门课在最开始便给出了一个简单的KV数据库的基本架构，它包括了：

（1）访问框架

（2）索引模块

（3）操作模块

（4）存储模块

SimpleKV - 来自极客时间

为了支持更加丰富的业务场景，其实 Redis 对这些组件或者功能进行了扩展，或者说是进行了精细优化，从而满足了功能和性能等方面的要求。

下图展示了从SimpleKV到Redis的变化：

SimpleKV to Redis - 来自极客时间

上图中展示了几点变化：

一是Redis主要使用网络框架来进行访问，使得Redis可以作为一个独立的基础网络服务；

二是Redis数据模型中的value类型更加丰富，可以提供更多的接口；

三是Redis扩展了持久化模块，提供日志（AOF）和快照（RDB）。

四是Redis提供了集群的支持，使得HA和可扩展成为可能。

2Redis的数据结构

Redis之所以“快”，一方面因为它是内存数据库，所有操作都在内存上完成，内存的访问速度本来就快。另一方面则是因为高效的数据结构，使得操作键值效率较高。

总体来说，Redis使用了一个用来保存每个Key/Value的全局哈希表结构，其中Value类型又包括了支持集合类型的双向链表、压缩列表、跳表等五大底层结构。

K/V的组织结构：全局哈希表

Redis使用了一个全局维度的哈希表来保存所有的Key/Value，每个哈希表本质上都是一个数组，这个数组的每个元素称为一个哈希桶。

哈希桶中的元素保存的并不是Value本身，而是指向Value的指针，如下图所示：

由数据结构的知识可以知道，哈希表的时间复杂度为O(1)，因此它非常适合快速查找的场景。

哈希冲突及其解决

当往哈希表中写入的数据变的很多时，哈希冲突问题就会出现。所谓哈希冲突，就是两个Key的哈希值正好落到了同一个哈希桶中（哈希桶的个数毕竟通常少于Key的个数）。

因此，和我们在数据结构课程学到的一致，Redis也采用了链式哈希来解决哈希冲突。所谓链式哈希，就是同一个哈希桶中的多个元素用一个链表来保存，它们之间依次用指针连接，如下图所示：

但是，如果哈希表里写入的数据越来越多，哈希冲突链也会进而变得很长，从而导致这个链条上得元素查找耗时长，效率降低。

因此，Redis还会对哈希表做rehash操作。所谓rehash，就是增加现有的哈希桶的数量，让逐渐增多的entry元素能够在更多的桶之间分散保存，减少单个桶中的元素数量，从而减少单个桶中的冲突。

在具体操作中，Redis会开辟一个新的哈希表（比如：大小为之前的两倍），然后把之前哈希表的数据重新映射到新的哈希表，最后释放之前的哈希表。

画外音：是不是跟.NET中的集合类型动态扩容的思想类似？

But，在拷贝之前哈希表数据到新哈希表时，涉及到数据量过大，有可能会造成Redis的线程阻塞，从而无法服务其他的请求。因此，Redis采用了渐进式哈希的解决方案。

简单来说，所谓渐进式哈希就是不一次性把老哈希表中的数据迁移完，而是在每次处理一个请求时，从老哈希表中的第一个索引位置开始，顺带着将这个索引位置上的所有entries拷贝到新哈希表中；等下一个请求时，再顺带拷贝下一个索引位置的entries。如此，便将一次性的大量拷贝的开销，分摊到多次处理请求的过程中，避免了耗时的操作和服务的中断。

渐进式哈希的示例流程如下图所示：