图解Redis 01 | 初识Redis

什么是 Redis？

Redis 是一种基于内存的数据库，所有的数据读写操作都在内存中完成，因此读写速度非常快。它被广泛应用于缓存、消息队列、分布式锁等场景。

Redis 提供了多种数据类型来支持不同的业务需求，如 String、Hash、List、Set、Zset、Bitmaps、HyperLogLog、GEO、Stream 等。Redis 对这些数据类型的操作都是原子的------因为Redis是单线程架构，一条命令的执行是由单个线程完成，不会出现并发竞争的问题。

除了基本的数据存储功能，Redis 还支持事务、持久化、Lua 脚本、多种集群方案（包括主从复制模式、哨兵模式和分片集群模式）、发布/订阅模式、内存驱逐机制以及过期删除机制等一些高级特性，进一步增强了其功能和应用场景的多样性。

Redis 和 Memcached 有什么区别？

很多人常建议用Redis做缓存，但是Memcached同样是基于内存的非关系型数据库，为什么Redis的使用场景更多呢？

要回答这个问题，我们需要搞清楚Redis和Memcached的区别。Redis与Memcached主要有以下区别：

1. 支持的数据类型

Redis不仅仅支持简单的String键值对存储，还提供了Hash、List、Set、Zset等多种复杂的数据结构，可以满足更复杂的数据存储场景需求。
Memcached主要是简单的键值对存储。

2. 持久化

Redis支持数据持久化，可以将数据保存到磁盘，从而保证数据在Redis发生故障后能够恢复。
Memcached通常不具备数据持久化功能，数据只存在于内存中。服务器重启后数据会丢失。

3. 内存管理

Redis具有更加灵活的内存管理策略和机制，可以配置和优化内存使用方式，以适应不同的应用场景，这一点在后面会详细的介绍。
Memcached在内存管理方面比较简单。

4. 性能特点：

在一些特定场景下，Memcached可能在简单的键值对操作中展现出极高的性能。
Redis在综合性能、功能多样性方面具有优势。

5. 应用场景

Memcached比较适合缓存比较简单的数据。
Redis可以应用在更广泛的场景，比如缓存，消息队列，分布式锁等等。

可以看出，当只需快速缓存简单的键值对时，Memcached 可能是更好的选择；而在需要处理复杂数据结构且存在持久化需求的情况下，Redis 则更为合适。在实际应用中，应该根据具体的需求和场景来选择合适的缓存方案。

Redis 支持的数据类型

Redis 提供了丰富多样的数据类型，其中常见的五种类型包括：String、Hash、List、Set 和 Zset。注意这里说的数据类型指的是value的类型，因为key的类型永远只有String这一种类型。

在后续版本中，Redis 还新增了四种数据类型：BitMap（2.2 版本）、HyperLogLog（2.8 版本）、GEO（3.2 版本）以及 Stream（5.0 版本）。

各种数据类型的应用场景

String：一般用于计数或缓存简单的键值对数据，例如用户信息、配置参数等。
Hash：用于存储对象信息，如一个用户的详细属性，常用于实现购物车等场景。
List：适用于消息队列、排行榜等。
Set：用于处理聚合计算（如并、交、差运算）的场景，比如点赞、共同关注、抽奖活动等。
Zset：适合实现带权重的排行榜或按时间排序的事件。
Bitmaps：用于处理二进制状态统计的场景，比如签到、判断用户登录状态、统计连续签到的用户总数等。
HyperLogLog：适合海量数据基数统计的场景，例如对百万级网页的 UV（独立访问用户数）进行计数。
GEO：用于基于位置的服务，如查找附近的商家、网约车等。
Stream：用于实现高级消息队列。

关于各个数据类型的指令使用方式和应用场景，会在后续的文章中一一介绍

Redis 五种常见数据类型是如何实现的？

下面是一张 Redis 数据类型与底层数据结构的对应关系图，其中左边展示的是 Redis 3.0 版本的数据类型实现，现在看来已经有些过时；右边则是 Redis 7.0 版本的数据类型实现。

下面对这些底层数据结构做一个简单的介绍，让我们有一个大致的映像，后面会写一篇文章详细剖析这些数据结构。

1. String类型内部实现

在 Redis 中，String 类型的底层数据结构主要是 SDS（Simple Dynamic String）。

SDS 与我们熟知的 C 语言字符串有所不同。相比于 C语言原生的字符串，Redis 选择 SDS 作为实现方式有其特定原因：

SDS 不仅可以保存文本数据，还可以保存二进制数据。这是因为 SDS 使用 len 属性来判断字符串的结束位置，而不是依靠空字符 ('\0') 标记结束。同时，SDS 的所有 API 都会将 buf[] 数组中的数据作为二进制来处理。因此，SDS 不仅可以存储文本，还能存储图片、音频、视频、压缩文件等二进制数据。
SDS获取字符串长度的时间复杂度为O(1)。由于C语言的字符串没有记录自身的长度，所以获取长度的复杂度为O(n)；而SDS结构体中的len属性记录了字符串长度，所以复杂度为O(1)。
Redis 的 SDS API 是安全的，拼接字符串不会导致缓冲区溢出。因为 SDS 会在拼接字符串前检查空间是否足够，如果空间不足，会自动扩展，避免缓冲区溢出的问题。

2. List类型的内部实现

List 类型的底层数据结构通过双向链表或者 ziplist实现：

当列表中的元素数量小于 512 个（默认值，可通过 list-max-ziplist-entries 配置），且每个元素的长度小于 64 字节（默认值，可通过 list-max-ziplist-value 配置）时，Redis 会使用 ziplist 作为 List 类型的底层数据结构。

如果列表中的元素不满足这些条件，Redis 则会使用双向链表作为 List 类型的底层数据结构。

然而，从 Redis 3.2 版本开始，List 类型的底层数据结构改为仅由 quicklist 实现，取代了早期的双向链表和 ziplist。

3. Hash类型的内部实现

Hash 类型的底层数据结构通过ziplist 或者 hash table实现：

当 Hash 类型的元素数量少于 512 个（默认值，可通过 hash-max-ziplist-entries 配置），且所有元素的值小于 64 字节（默认值，可通过 hash-max-ziplist-value 配置）时，Redis 会使用 ziplist 作为 Hash 类型的底层数据结构。
如果 Hash 类型的元素不满足这些条件，Redis 则会使用hash table作为底层数据结构。

从 Redis 7.0 开始，ziplist 数据结构已被废弃，取而代之的是 listpack 数据结构。

4. Set 类型的内部实现

Set 类型的底层数据结构可以通过hash table或整数集合实现：

当集合中的所有元素都是整数且元素数量少于 512 个（默认值，可通过 set-maxintset-entries 配置）时，Redis 会使用整数集合作为 Set 类型的底层数据结构。
如果集合中的元素不满足这些条件，Redis 则会使用哈希表作为 Set 类型的底层数据结构。

5. ZSet类型内部实现

ZSet 类型的底层数据结构可以通过 ziplist 或 skiplist 实现：

当有序集合中的元素数量少于 128 个且每个元素的值小于 64 字节时，Redis 会使用 ziplist 作为 ZSet 类型的底层数据结构。
如果有序集合的元素不满足这些条件，Redis 则会使用 skiplist 作为 ZSet 类型的底层数据结构。

从 Redis 7.0 开始，ziplist 数据结构已被废弃，取而代之的是 listpack 数据结构。