深入剖析Redis系列:Redis数据结构与全局命令概述
mhr18 2024-10-21 05:42 38 浏览 0 评论
前言
Redis 提供了 5 种数据结构。理解每种数据结构的特点,对于 Redis 的 开发运维 非常重要,同时掌握 Redis 的 单线程命令处理 机制,会使 数据结构 和 命令 的选择事半功倍。
接下来的几篇文章,将从如下几个方面介绍 Redis 的几种数据结构,命令使用及其应用场景。
- 预备知识:几个简单的 全局命令,数据结构 和 内部编码,单线程命令 处理机制分析。
- 数据结构特性:5 种 数据结构 的特点、命令使用、应用场景。
- 数据管理:键管理、遍历键、数据库管理。
正文
1. 预备知识
在介绍 5 种 数据结构 之前,需要先了解 Redis 的一些 全局命令、数据结构 和 内部编码、单线程命令处理机制。
- Redis 的命令有 上百个,理解 Redis 的一些机制,会发现这些命令有很强的 通用性。
- Redis 不是万金油,有些 数据结构 和 命令 必须在 特定场景 下使用,一旦 使用不当 可能对 Redis 本身 或者 应用本身 造成致命伤害。
2. 全局命令
Redis 有 5 种 数据结构,它们是 键值对 中的 值,对于 键 来说有一些通用的命令。
2.1. 查看所有键
keys *
下面插入了 3 对字符串类型的键值对:
127.0.0.1:6379> set hello world
OK
127.0.0.1:6379> set java jedis
OK
127.0.0.1:6379> set python redis-py
OK
命令会将所有的键输出:
127.0.0.1:6379> keys *
1) "python"
2) "java"
3) "hello"
2.2. 键总数
dbsize
下面插入一个 列表类型 的 键值对(值是 多个元素 组成):
127.0.0.1:6379> rpush mylist a b c d e f g
(integer) 7
dbsize 命令会返回当前数据库中 键的总数。
127.0.0.1:6379> dbsize
(integer) 4
dbsize 命令在 计算键总数 时 不会遍历 所有键,而是直接获取 Redis 内置的键总数变量,所以 dbsize 命令的 时间复杂度 是 O(1)。而 keys 命令会 遍历 所有键,所以它的 时间复杂度 是 O(n),当 Redis 保存了 大量键 时,线上环境 禁止 使用。
2.3. 检查键是否存在
exists key
如果键存在则返回 1,不存在则返回 0:
127.0.0.1:6379> exists java
(integer) 1
127.0.0.1:6379> exists not_exist_key
(integer) 0
2.4. 删除键
del key
del 是一个 通用命令,无论值是什么 数据结构 类型,del 命令都可以将其 删除。
127.0.0.1:6379> del java
(integer) 1
127.0.0.1:6379> exists java
(integer) 0
127.0.0.1:6379> del not_exist_key
(integer) 0
127.0.0.1:6379> exists not_exist_key
(integer) 0
返回结果为 成功删除 的 键的个数,假设删除一个 不存在 的键,就会返回 0。
2.5. 键过期
expire key seconds
Redis 支持对 键 添加 过期时间,当超过过期时间后,会 自动删除键,例如为键 hello 设置 10 秒过期时间:
127.0.0.1:6379> set hello world
OK
127.0.0.1:6379> expire hello 10
(integer) 0
ttl 命令会返回键的 剩余过期时间,它有 3 种返回值:
- 大于等于 0 的整数:表示键 剩余 的 过期时间。
- 返回 -1:键 没设置 过期时间。
- 返回 -2:键 不存在。
可以通过 ttl 命令观察 键 hello 的 剩余过期时间:
# 还剩7秒
127.0.0.1:6379> ttl hello(integer)
(integer) 7
...
# 还剩1秒
127.0.0.1:6379> ttl hello(integer)
(integer) 1
# 返回结果为-2,说明键hello已经被删除
127.0.0.1:6379> ttl hello(integer)
(integer) -2
127.0.0.1:6379> get hello
(nil)
2.6. 键的数据结构类型
type key
例如键 hello 是的值 字符串类型,返回结果为 string。键 mylist 的值是 列表类型,返回结果为 list。如果键不存在,则返回 none。
127.0.0.1:6379> set a b
OK
127.0.0.1:6379> type a
string
127.0.0.1:6379> rpush mylist a b c d e f g
(integer) 7
127.0.0.1:6379> type mylist
list
3. 数据结构和内部编码
type 命令实际返回的就是当前 键 的 数据结构类型,它们分别是:string(字符串)、hash(哈希)、list(列表)、set(集合)、zset(有序集合),但这些只是 Redis 对外的 数据结构。如图所示:
对于每种 数据结构,实际上都有自己底层的 内部编码 实现,而且是 多种实现。这样 Redis 会在合适的 场景 选择合适的 内部编码,如图所示:
image
可以看到,每种 数据结构 都有 两种以上 的 内部编码实现。例如 list 数据结构 包含了 linkedlist 和 ziplist 两种 内部编码。同时有些 内部编码,例如 ziplist,可以作为 多种外部数据结构 的内部实现,可以通过 object encoding 命令查询 内部编码:
127.0.0.1:6379> object encoding hello
"embstr"
127.0.0.1:6379> object encoding mylist
"quicklist"
可以看到键 hello 对应值的 内部编码 是 embstr,键 mylist 对应值的 内部编码 是 ziplist。
Redis 这样设计有两个好处:
- 其一:可以改进 内部编码,而对外的 数据结构 和 命令 没有影响。例如 Redis3.2 提供的 quicklist,结合了 ziplist 和 linkedlist 两者的优势,为 列表类型 提供了一种 更加高效 的 内部编码实现。
- 其二:不同 内部编码 可以在 不同场景 下发挥各自的 优势。例如 ziplist 比较 节省内存,但是在列表 元素比较多 的情况下,性能 会有所 下降,这时候 Redis 会根据 配置,将列表类型的 内部实现 转换为 linkedlist。
4. 单线程架构
Redis 使用了 单线程架构 和 I/O 多路复用模型 来实现 高性能 的 内存数据库服务。那为什么 单线程 还能这么快,下面分析原因:
4.1. 纯内存访问
Redis 将所有数据放在 内存 中,内存的 响应时长 大约为 100 纳秒,这是 Redis 达到 每秒万级别 访问的重要基础。
4.2. 非阻塞I/O
Redis 使用 epoll 作为 I/O 多路复用技术 的实现,再加上 Redis 自身的 事件处理模型 将 epoll 中的 连接、读写、关闭 都转换为 事件,从而不用不在 网络 I/O 上浪费过多的时间,如图所示:
image
4.3. 单线程避免线程切换和竞态产生的消耗
采用 单线程 就能达到如此 高的性能,那么不失为一种不错的选择,因为 单线程 能带来几个好处:
- 单线程 可以简化 数据结构和算法 的实现,开发人员不需要了解复杂的 并发数据结构。
- 单线程 避免了 线程切换 和 竞态 产生的消耗,对于服务端开发来说,锁和线程切换 通常是性能杀手。
单线程 的问题:对于 每个命令 的 执行时间 是有要求的。如果某个命令 执行过长,会造成其他命令的 阻塞,对于 Redis 这种 高性能 的服务来说是致命的,所以 Redis 是面向 快速执行 场景的数据库。
小结
本文堆 Redis 的几种 数据结构 进行了概述,介绍了几个简单的 全局命令,数据结构 和 内部编码 以及 单线程命令 处理机制分析。
参考
《Redis 开发与运维》
相关推荐
- 订单超时自动取消业务的 N 种实现方案,从原理到落地全解析
-
在分布式系统架构中,订单超时自动取消机制是保障业务一致性的关键组件。某电商平台曾因超时处理机制缺陷导致日均3000+订单库存锁定异常,直接损失超50万元/天。本文将从技术原理、实现细节、...
- 使用Spring Boot 3开发时,如何选择合适的分布式技术?
-
作为互联网大厂的后端开发人员,当你满怀期待地用上SpringBoot3,准备在项目中大显身手时,却发现一个棘手的问题摆在面前:面对众多分布式技术,究竟该如何选择,才能让SpringBoot...
- 数据库内存爆满怎么办?99%的程序员都踩过这个坑!
-
你的数据库是不是又双叒叕内存爆满了?!服务器监控一片红色警告,老板在群里@所有人,运维同事的电话打爆了手机...这种场景是不是特别熟悉?别慌!作为一个在数据库优化这条路上摸爬滚打了10年的老司机,今天...
- springboot利用Redisson 实现缓存与数据库双写不一致问题
-
使用了Redisson来操作Redis分布式锁,主要功能是从缓存和数据库中获取商品信息,以下是针对并发时更新缓存和数据库带来不一致问题的解决方案1.基于读写锁和删除缓存策略在并发更新场景下,...
- 外贸独立站数据库炸了?对象缓存让你起死回生
-
上周黑五,一个客户眼睁睁看着服务器CPU飙到100%——每次页面加载要查87次数据库。这让我想起2024年Pantheon的测试:Redis缓存能把WooCommerce查询速度提升20倍。跨境电商最...
- 手把手教你在 Spring Boot3 里纯编码实现自定义分布式锁
-
为什么要自己实现分布式锁?你是不是早就受够了引入各种第三方依赖时的繁琐?尤其是分布式锁这块,每次集成Redisson或者Zookeeper,都得额外维护一堆配置,有时候还会因为版本兼容问题头疼半...
- 如何设计一个支持百万级实时数据推送的WebSocket集群架构?
-
面试解答:要设计一个支持百万级实时数据推送的WebSocket集群架构,需从**连接管理、负载均衡、水平扩展、容灾恢复**四个维度切入:连接层设计-**长连接优化**:采用Netty或Und...
- Redis数据结构总结——面试最常问到的知识点
-
Redis作为主流的nosql存储,面试时经常会问到。其主要场景是用作缓存,分布式锁,分布式session,消息队列,发布订阅等等。其存储结构主要有String,List,Set,Hash,Sort...
- skynet服务的缺陷 lua死循环
-
服务端高级架构—云风的skynet这边有一个关于云风skynet的视频推荐给大家观看点击就可以观看了!skynet是一套多人在线游戏的轻量级服务端框架,使用C+Lua开发。skynet的显著优点是,...
- 七年Java开发的一路辛酸史:分享面试京东、阿里、美团后的心得
-
前言我觉得有一个能够找一份大厂的offer的想法,这是很正常的,这并不是我们的饭后谈资而是每个技术人的追求。像阿里、腾讯、美团、字节跳动、京东等等的技术氛围与技术规范度还是要明显优于一些创业型公司...
- mysql mogodb es redis数据库之间的区别
-
1.MySQL应用场景概念:关系型数据库,基于关系模型,使用表和行存储数据。优点:支持ACID事务,数据具有很高的一致性和完整性。缺点:垂直扩展能力有限,需要分库分表等方式扩展。对于复杂的查询和大量的...
- redis,memcached,nginx网络组件
-
1.理解阻塞io,非阻塞io,同步io,异步io的区别2.理解BIO和AIO的区别io多路复用只负责io检测,不负责io操作阻塞io中的write,能写多少是多少,只要写成功就返回,譬如准备写500字...
- SpringBoot+Vue+Redis实现验证码功能
-
一个小时只允许发三次验证码。一次验证码有效期二分钟。SpringBoot整合Redis...
- AWS MemoryDB 可观测最佳实践
-
AWSMemoryDB介绍AmazonMemoryDB是一种完全托管的、内存中数据存储服务,专为需要极低延迟和高吞吐量的应用程序而设计。它与Redis和Memcached相似,但具有更...
- 从0构建大型AI推荐系统:实时化引擎从工具到生态的演进
-
在AI浪潮席卷各行各业的今天,推荐系统正从幕后走向前台,成为用户体验的核心驱动力。本文将带你深入探索一个大型AI推荐系统从零起步的全过程,揭示实时化引擎如何从单一工具演进为复杂生态的关键路径。无论你是...
你 发表评论:
欢迎- 一周热门
- 最近发表
- 标签列表
-
- oracle位图索引 (74)
- oracle批量插入数据 (65)
- oracle事务隔离级别 (59)
- oracle主从同步 (56)
- oracle 乐观锁 (53)
- redis 命令 (83)
- php redis (97)
- redis 存储 (67)
- redis 锁 (74)
- 启动 redis (73)
- redis 时间 (60)
- redis 删除 (69)
- redis内存 (64)
- redis并发 (53)
- redis 主从 (71)
- redis同步 (53)
- redis结构 (53)
- redis 订阅 (54)
- redis 登录 (62)
- redis 面试 (58)
- redis问题 (54)
- 阿里 redis (67)
- redis的缓存 (57)
- lua redis (59)
- redis 连接池 (64)