您的位置:首页 > 汽车 > 时评 > 图解Redis 01 | 初识Redis

图解Redis 01 | 初识Redis

2024/11/8 16:01:09 来源:https://blog.csdn.net/weixin_42627385/article/details/142312628  浏览:    关键词:图解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 数据结构。

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com