redis成神系列：redis基础（二）

最新推荐文章于 2024-09-30 11:23:38 发布
最新推荐文章于 2024-09-30 11:23:38 发布
阅读量903 收藏 17
点赞数 9
文章标签： redis 数据库 缓存
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_55839103/article/details/141763010
版权

Set 的编码方式

Redis 中的 Set 集合有两种底层编码方式：整数集合（intset） 和 字典（hashtable）。具体使用哪种编码取决于集合元素的数据类型和集合的大小。

  1. 整数集合（intset）：

    • 当集合的所有元素都是整数（例如 1, 2, 3），并且集合中元素的个数不超过 512 个时，Redis 会使用整数集合（intset）作为底层实现。
    • 整数集合是有序的：整数集合存储的整数是有序排列的，因此支持高效的查找和范围查询操作。

  2. 字典（hashtable）：

    • 当集合中有非整数类型的元素，或者元素个数超过 512 个时，Redis 会使用字典（hashtable）作为底层实现。
    • 字典是无序的：字典的底层实现是哈希表，因此它不保证元素的顺序。

Set 是有序的吗？

Redis 中的 Set 集合既可以是有序的，也可以是无序的，具体取决于底层编码的类型。如果 Set 的底层编码是 整数集合（intset），那么 Set 是有序的；如果底层编码是 字典（hashtable），那么 Set 是无序的。因此，在实际业务中，不应该依赖 Set 的顺序，始终应当按照无序来使用 Set。

Set 为什么要用两种编码方式？

Redis 中的 Set 集合使用两种编码方式：整数集合（intset） 和 字典（hashtable）。采用这两种编码方式的主要原因是为了在不同的场景下优化内存使用和查询性能。

  1. 内存优化（intset）:

    • 内存效率高：当 Set 集合中的所有元素都是整数类型，并且元素的数量较少（不超过 512 个），Redis 使用整数集合（intset）作为底层实现。这种编码方式在内存的使用上更加节约，因为它使用一个连续的有序数组来存储整数，并且数组的编码格式会根据存储的整数范围自动升级（从 int16 到 int32，再到 int64），以适应更大的整数值。

    • 适合小数据量的集合：整数集合（intset）通过这种可变长度的编码方式（编码格式和元素数量的灵活调整），能够在较小的数据量情况下节省大量内存。它在数据量不大时，查找操作的时间复杂度为 O(log⁡n)O(\log n)O(logn)，通过二分查找来快速定位元素。

  2. 查询性能（hashtable）:

    • 更高效的查找：当 Set 中的元素数量较多（超过 512 个）或包含非整数类型的元素时，Redis 则使用字典（hashtable）作为底层编码。这是因为哈希表提供了 O(1)O(1)O(1) 平均时间复杂度的查找性能，适合处理大量数据。

    • 适合大数据量和复杂数据类型的集合：字典编码更适合处理较大的数据集合，或者当元素不仅仅是整数时，字典编码能提供更高效的查找速度和灵活性。

Hash 的编码方式是什么?

Redis 中的 Hash（哈希）有两种底层编码方式：ZIPLIST（压缩列表） 和 HASHTABLE（哈希表）。具体使用哪种编码方式，取决于 Hash 中元素的数量和每个元素的大小。

  1. ZIPLIST（压缩列表）:

    • 适用场景：元素个数少且每个元素的大小较小的情况。
    • 条件：当 Hash 中的元素个数少于 512 个，并且键和值的长度都小于 64 字节时，Redis 使用 ZIPLIST 作为底层数据结构。
    • 优点：ZIPLIST 编码的主要优点是节省内存，适用于小型数据集。

  2. HASHTABLE（哈希表）:

    • 适用场景：元素个数多或单个元素的大小较大的情况。
    • 条件：当 Hash 中的元素个数超过 512 个，或者任意一个键或值的长度超过 64 字节时，Redis 则会使用 HASHTABLE 作为底层数据结构。
    • 优点：HASHTABLE 编码的主要优点是查找速度快，即使在较大的数据集上也能保持高效的查找性能。

Hash 查找某个 key 的平均时间复杂度是多少?

在 Redis 中，Hash 的底层编码有两种，查找某个 key 的时间复杂度取决于底层编码方式。

  1. ZIPLIST（压缩列表）:

    • 查找复杂度：O(N)
    • 原因：ZIPLIST 是一个连续的内存结构，查找某个 key 时需要遍历每个元素，直到找到目标 key，平均时间复杂度为 O(N)，其中 NNN 是元素的个数。

  2. HASHTABLE（哈希表）:

    • 查找复杂度：O(1)
    • 原因：HASHTABLE 使用哈希算法将键映射到数组的索引位置，通过哈希计算直接找到对应的键值对，平均时间复杂度为 O(1)。

Redis 中 HashTable 查找元素总数的平均时间复杂度是多少?

在 Redis 中，HashTable 的表头结构包含一个字段 used，专门用于记录当前字典中键值对的数量。因此，查找 HashTable 中元素总数的操作可以在常数时间内完成。

由于 used 字段直接记录了键值对的数量，Redis 查找 HashTable 中元素总数的操作只需要读取这个字段的值，因此其平均时间复杂度是 O(1)。

一个数据在 HashTable 中的存储位置是怎么计算的?

  1. 计算哈希值:

    • 对 key 使用 MurmurHash2 哈希算法计算出一个哈希值。这个哈希值是一个整数，理论上可以取任何值。

  2. 计算索引值:

    • 通过哈希值与哈希表的 哈希掩码 做与运算（hash & sizemask）来计算出该键值对在哈希表中的存储位置（索引值）。
    • 哈希掩码 (sizemask) 是哈希表数组的大小减去 1。例如，如果哈希表的大小是 16，那么 sizemask 就是 15（即 16 - 1）。

  3. 确定存储位置:

    • 计算出的索引值即为该数据在 HashTable 中的存储位置，程序会根据这个索引值将键值对插入到相应的位置。

HashTable 怎么扩容?

  1. 分配新的哈希表（1 号表）:

    • Redis 首先为 HashTable 分配一个新的哈希表（1 号表）。这个新表的大小是旧表（0 号表）大小的两倍，或者是第一个大于等于当前哈希表大小乘以 2 的 2 的幂。

  2. 设置 rehash 标记:

    • 在 rehash 过程中，Redis 使用一个标记位 rehashidx 来表示 rehash 进度。rehashidx 初始值为 -1，表示未开始 rehash。

  3. 渐进式 rehash:

    • 每次对字典进行增删改查操作时，Redis 会顺带将哈希表 0 号表中 rehashidx 位置的数据迁移到 1 号表，并将 rehashidx 增加 1。
    • 这种做法是为了将 rehash 操作分摊到多次增删改查操作中，避免一次性 rehash 造成的性能问题。

  4. 完成 rehash:

    • 当所有键值对都从 0 号表迁移到 1 号表后，Redis 将 1 号表设为新的 0 号表，并清空原 0 号表（现在已经不再需要）。

HashTable 怎么缩容?

  1. 分配新的哈希表（1 号表）:

    • 程序会为 HashTable 分配一个新的哈希表（1 号表）。新表的大小是第一个大于等于当前哈希表已使用节点数（used）的 2 次幂。

  2. 设置 rehash 标记:

    • 缩容操作开始时，rehashidx 标记位设为 0，表示开始 rehash 操作。

  3. 渐进式 rehash:

    • 每次对字典进行增删改查操作时，Redis 会将 0 号表中 rehashidx 位置的数据迁移到 1 号表，然后将 rehashidx 加 1。
    • 这种逐步迁移操作将 rehash 的成本分散到多次字典操作中，避免了一次性操作带来的性能开销。

  4. 完成 rehash:

    • 当所有键值对都从 0 号表迁移到 1 号表后，Redis 将 1 号表设为新的 0 号表，并清空原 0 号表（现在已经不再需要）。

什么时候扩容，什么时候缩容?

HashTable 的扩容和缩容是根据负载因子来进行的。

  • 扩容: 当以下两个条件中的任意一个被满足时，哈希表会自动扩容：

    1. 服务器当前没有在执行 BGSAVE 或者 BGREWRITEAOF，并且负载因子 >= 1。
    2. 服务器当前正在执行 BGSAVE 或者 BGREWRITEAOF，并且负载因子 >= 5。

  • 缩容: 当哈希表的负载因子 < 0.1 时，程序会自动开始对哈希表进行缩容操作。

通过这样动态调整哈希表的大小，Redis 能够在节省内存和保证查询性能之间取得平衡。

跳表插入一条数据的平均时间复杂度是多少?

跳表（Skiplist）是一种支持快速查找、插入和删除操作的数据结构。它通过在一维有序链表的基础上增加多层索引，从而实现类似于二分查找的高效查找性能。跳表的索引层数通常会在插入或删除节点时根据概率随机调整，这使得跳表可以在平均情况下保持较低的索引高度。

由于跳表每一层的节点数量是递减的，大多数情况下查找一个元素不需要遍历所有节点，因此在查找、插入和删除操作的平均时间复杂度都是 O(log⁡n)O(\log n)O(logn)，其中 nnn 是跳表中的节点数。

为什么跳表和 HashTable 要配合使用?

Redis 中的有序集合（ZSet）底层使用了两种数据结构：跳表（Skiplist）和 HashTable。之所以使用这两种数据结构，是为了让有序集合能够同时具备这两者的优势，以便在不同场景下能够快速、高效地完成操作。

  • HashTable 的优势：能够在 O(1)O(1)O(1) 的时间复杂度内，根据成员名直接查找到对应的分值。适用于根据成员名直接查找分值的操作，比如 ZSCORE、ZADD、ZREM 等。
  • 跳表 的优势：是一种有序的数据结构，能够在 O(log⁡n)O(\log n)O(logn) 的时间复杂度内完成有序查找、范围查找和插入操作。适用于根据分值进行排序的操作，比如 ZRANK、ZRANGE、ZREVRANGE 等。

因此，使用跳表和 HashTable 结合的方式能够充分利用两者的优势，实现快速的分值查找和高效的范围操作。

跳表中一个节点的层高是怎么决定的?

跳表的核心思想是通过在有序链表的基础上增加多层索引来加速查找操作。每个节点的层高（Level）是随机生成的，且遵循幂次定律，即生成更高层数的概率更低。

具体来说，在跳表中插入一个节点时，为了决定该节点的层高，Redis 使用了一种随机化策略：最底层的节点（Level 1）一定存在，而每增加一层的概率是 25%（或 1/4），最高层数是 32 层。这意味着：

  • 每个节点的初始层高至少是 1。
  • 随机算法确保了大部分节点的层高较低，而只有少数节点具有较高的层高。

这种概率分布有助于在保持跳表结构简单的同时，实现高效的查找和插入操作。

饭叮叮的学习日记
关注
Redis学习笔记之位图
weixin_30367543的博客
03-02 248
目录 位图定义 应用场景 基本使用 查找统计 位图定义 位图并不是一种数据结构，其实就是一种普通的字符串，也可以说是byte数组。基本语法是setbit/getbit，刚才说了是一个byte数组，所以也可以用set/get设置或获取 SetBit语法： Setbit ...
基于redis生成自增流水号(格式：标志位 + 年月日时分秒 + 自增流水号)
_修铁路的、的博客
08-09 4556
最近开发时，又遇到一个需求，后端需要生成自增的流水号，流水号格式一般就是：标志位 + 年月日时分秒 + 一定位数的流水号 组成，例如： T20190809135743000001 。 根据先前的查询和总结实现，现在对该需求的解决方法做一个整理记录。 先前在网上看各位大佬对自增流水号的处理，一般分成三种： 1. 通过在Java类中生成； ...
四，标志位操作指令
用心做事，用爱生活
11-26 1190
1，清除进位标志指令：CLC ；置CF = 0 2，进位标志置位指令：STC；置CF = 1 3，进位标志取反指令：CMC；CF取反 4，清除方向标志指令：CLD；置DF=0 5，方向标志置位指令：STD;置DF = 1 6，清除中断标志指令：CLI;置IF = 0 7，中断标志置位指令：STI;置IF =1
深入了解Redis
ErixHao的专栏
08-16 1万+
本文将主要从Redis适用范围，与Memcached, Java容器对比，核心功能（Pipelining，Pub/Sub，LRU，Transactions， Persistence， Replication），分布式架构设计，Cluster，内部实现及数据结构来深入了解Redis，适用于已经了解并有Redis操作经验之程序员。
redis成神系列：redis基础（一）
m0_55839103的博客
09-01 943
Redis 是一个基于内存的存储系统，支持多种数据结构，可以作为数据库、缓存和消息中间件。它支持的数据结构包括字符串（strings）、哈希（hashes）、列表（lists）、集合（sets）、有序集合（sorted sets）等。此外，Redis 还支持位图（bitmaps）、HyperLogLogs 和地理空间（geospatial）索引及半径查询等功能。
Redis成神系列：redis执行与持久化
m0_55839103的博客
09-01 1017
新的 Incr AOF 日志和新的 Base AOF 日志共同构成了完整的新的 AOF 日志。因此，Redis 6.0 通过多线程优化了核心处理流程中的解包和发包两个耗费 CPU 时间的 I/O 操作，以充分利用多核的优势。在多数情况下，Redis的瓶颈在于内存和网络I/O，而不是CPU计算，使用单线程避免了线程调度和锁竞争的问题，使得Redis的处理效率更高。AOF 混合持久化方案将 RDB 持久化函数用于 AOF 的重写，将内存数据以 RDB 格式写入新的 AOF 文件中。
redis成神系列：redis过期删除、内存淘汰、集群
m0_55839103的博客
09-01 1183
分析LRU (Least Recently Used) 算法是一种常见的缓存淘汰策略，Redis 使用近似的 LRU 算法而非标准的 LRU 算法。回答LRU 算法，即最近最久未使用，记录每个 key 的最近访问时间，淘汰最久未访问的数据。Redis 使用的是近似的 LRU 算法，而不是标准的 LRU 算法，这样可以减少内存开销。如果你想了解更多关于 Redis 如何实现近似 LRU 的细节，可以展开讲讲。分析LRU 算法只关注最近访问时间，忽略了访问频率。LFU 算法则将访问频率也纳入了考量。
Redis List：打造高效消息队列的秘密武器【redis实战 一】
热门推荐
todoitbo的博客
12-20 8万+
本文将深入研究如何使用 Redis 中的 List 数据结构构建高效的消息队列。我们将探讨消息队列的基本概念，然后详细介绍如何通过 Redis 的 List 实现消息的生产和消费。通过学习本文，你将了解 Redis List 的强大之处，以及如何利用它为你的应用程序建立可靠的消息传递系统。
初探 Redis 客户端 Lettuce：真香！
vivo互联网技术
07-12 1539
笔者因项目需要，在一些场景下切换成 Lettuce 进行开发，并且希望能类似 Jedis pipeline 一样提升批量查询的性能。在对 Lettuce 进行了学习和踩坑后，笔者将过程中遇到的各种关键点总结成文章分享给大家。
Redis高频面试笔记：java字符串相加原理
m0_57081438的博客
07-12 109
栈和队列部分（10） 设计一个有getMin功能的栈（士★☆☆☆） 由两个栈组成的队列（尉★★☆☆） 如何仅用递归函数和栈操作逆序一个栈（尉★★☆☆） 猫狗队列（士★☆☆☆） 用一个栈实现另一个栈的排序（士★☆☆☆） 用栈来求解汉诺塔问题（校★★★☆） 生成窗口最大值数组（尉★★☆☆） 构造数组的MaxTree（校★★★☆） 求最大子矩阵的大小（校★★★☆） 最大值减去最小值小于或等于num的子数组数量（校★★★☆） 链表问题（20） 打印两个有序链表的公共部
Spring Boot进阶(63)：「超详细」利用 Redis 实现高效延时队列：踩坑、优化、实践
**My Coding Family**
08-31 3517
这篇文章分享了作者在使用 Redis 实现延时队列的过程中所遇到的坑和优化经验。作者首先介绍了 Redis 的有序集合数据结构，以及如何利用有序集合作为延时队列的底层实现。接着，作者分享了在实践中遇到的一些问题，例如服务宕机重启后需要重新拉取超时任务，任务过多导致 Redis 内存占用过高等。最后，作者给出了对延时队列的优化建议，例如采用批量删除任务和使用多个 Redis 实例来分散负载等。整篇文章结合了理论和实践，对于想要使用 Redis 实现高效延时队列的开发者来说是一份很有价值的参考资料。
redis的五种数据类型
学Java，找哪吒
05-15 5万+
（1）Redis（Remote Dictionary Server 远程字段服务）是一个开源的使用ANSI C语言编写、支持网络、科技与内存亦可持久化的日志型、key-value数据库，并提供多种语言的API。（2）Redis是一个key-value存储系统，它支持存储的value类型相对更多，包括string、list、set、zset（sorted set --有序集合）和hash。这些数据结构都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。
redis详解(持续更新)
Ferao的博客
11-19 3万+
redis
【redis系列】（二）redis中五种value类型与其常用方法
asd13518662的博客
05-07 3829
本文主要介绍在命令行中，如何使用redis的五种不同类型的value，分别是字符串，散列，列表，集合与有序集合。
缓存是什么？缓存机制、Spring缓存管理、Redis数据一致性、缓存问题（缓存穿透、缓存雪崩、缓存击穿）及Redis与MySQL使用场景对比
最新发布
项目git同名HuYaochao，未入职
09-30 1291
缓存机制、Spring缓存管理、Redis数据一致性、缓存问题（缓存穿透、缓存雪崩、缓存击穿）及Redis与MySQL使用场景对比
Redis: 持久化之RDB和AOF
Wang的专栏
09-29 1034
Redis 有一个高质量的课题：数据安全性与数据可靠性Redis 是一个内存型数据库，数据大部分都是存在内存里面当信息在内存中流通时，Redis 节点突然就故障挂掉当重新启动的时候，内存中的数据肯定是全部丢失了如果在这种情况下，Redis 提供了对应的持久化方案，它有两种持久化方案RDB和AOF可以把内存中的数据保存到磁盘，避免数据的流失关于RDB，我们需要了解到什么是持久化什么是快照RDB的工作原理，包括它的优点和缺点关于AOF，需要知道为什么需要有AOF。
Redis-常见数据类型(修改ing)
qq_74812898的博客
09-29 991
redis常用数据类型
Redis 全方位解析：从基础到集群搭建
简单字符串、哈希表、列表、集合"这些基础数据类型，还支持有序集合、位图、HyperLogLog等高级数据结构，使得它在各种场景下都能发挥出色性能。 3. 高性能【Redis完全在内存中操作，通过主从复制和分布式集群实现高...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值