Redis

简介: Redis

Redis 快的原因


  1. 1.基于内存实现

  2. 2.高效的数据结构 : 简单动态字符串, 双端链表,压缩列表,字典,跳跃表

  3. 3.合理的数据编码

  4. 4.合适的线程模型 : I/O多路复用, 避免上下文切换,单线程模型


一. Redis是基于内存的数据库


Redis相对于磁盘数据库来说,省去了将数据I/O进内存的一个过程


二. 高效的数据结构


Redis有多种数据类型,每种数据类型的底层由一种或多种数据结构来支持。

20201023090950977.png

1. 简单动态字符串SDS

20201023091132560.png

在C语言中字符串的结尾以\0为结尾代表结束,如需获取字符串的全部信息就需要遍历。


Redis中用一个len字段记录当前字符串的长度,获取长度直接获取len。时间为O(1)


内存重新分配


C语言设计修改字符串会重新分配内存,频繁修该,内存分配就会频繁。内存分配会消耗性能。

在Redis 中设计到字符串频繁修改操作,就会采取两种优化策略: 空间预分配, 惰性空间释放。


(1)空间预分配 :


当字符串进行阔容得时候,除了分配锁必须的空间外,还会多分配一些未使用的空间。动态字符串修改之后,如果len长度大于1M, 就会额外分配与len相同长度的未使用空间。如果修改后长度大于1M, 将分配1M的使用空间。


(2)惰性空间释放 :


当动态字符串缩短的时候,并不会回收多余的内存空间,而是使用free字段将多出来的空间记录下来,如果后续有变更操作,就直接使用free中记录的空间,减少实际内存的分配改动。实际相当于一个伪删除


二进制安全


按照动态字符串存储的SDS的len变量直接进行读取,多出来的标志位字符是不会被读取的


2. 双端列表


2020102310101918.png

Redis实现了一个双端列表的结构。


(1)前后节点


链表里每个节点都带有两个指针,prev和next,prev指向前节点,next指向后节点,时间复杂度O(1)可以前向获取和后向获取。


(2)头尾节点


有了头尾几点,对双端节点的处理时间复杂度可以降至O(1),可以在队前加入并且还可以向后端进行操作。


(3)链表长度


长度可以通过世界获取储存的变量len, 时间复杂度降低至O(1)


3. 压缩列表

20201023101804589.png

当存储下数据的时候,不使用双端列表和额外的空间存储信息。用一个线性列表进行存储。压缩表的内存是连续分配的,遍历的速度非常快。在列表的头位置保存了

占用字节,偏移量(列表的长度), 节点的数量, 节点内容, 特殊标记符为结尾。

它是经过特殊编码,专门为了提升内存使用效率设计的。所有的操作都是通过指针与解码出来的偏移量进行的。


4. 字典


Redis 是 K-V型数据库,键值对是存在字典中的。


添加, 获取,删除都是O(1) 时间复杂度。


4. 跳表

20201023102423798.png

Redis中的跳表在链表的基础上增加了索引,使得查询效率提升。查询的时间复杂度为O(logN)。在头节点中存储相关信息。


三. 合理的数据编码


对于每一种数据类型来说,底层的支持可能是多种数据结构,什么时候使用哪种数据结构,这就涉及到了编码转化的问题。


那我们就来看看,不同的数据类型是如何进行编码转化的:


String:存储数字的话,采用int类型的编码,如果是非数字的话,采用 raw 编码;


List:字符串长度及元素个数小于一定范围使用 ziplist 编码,任意条件不满足,则转化为 linkedlist 编码;


Hash:hash 对象保存的键值对内的键和值字符串长度小于一定值及键值对;


Set:保存元素为整数及元素个数小于一定范围使用 intset 编码,任意条件不满足,则使用 hashtable 编码;


Zset:zset 对象中保存的元素个数小于及成员长度小于一定值使用 ziplist 编码,任意条件不满足,则使用 skiplist 编码。


四. 线程模型

20201023102700100.png

(1)I/O多路复用


  • I/O: 网络I/O

  • 多路:多个TCP连接

  • 复用:公用一个线程或进程


生产环境中的使用,通常是多个客户端连接 Redis,然后各自发送命令至 Redis 服务器,最后服务端处理这些请求返回结果。


应对大量的请求,Redis 中使用 I/O 多路复用程序同时监听多个套接字,并将这些事件推送到一个队列里,然后逐个被执行。最终将结果返回给客户端。


(2)使用单线程,减少上下文切换


不使用多线程,省去了上下文切换的过程。


(3)单线程

20201023103130752.png

Redis使用Reactor单线程模型。


总结


基于内存实现


数据都存储在内存里,减少了一些不必要的 I/O 操作,操作速率很快。


高效的数据结构


底层多种数据结构支持不同的数据类型,支持 Redis 存储不同的数据;


不同数据结构的设计,使得数据存储时间复杂度降到最低。


合理的数据编码


根据字符串的长度及元素的个数适配不同的编码格式。


合适的线程模型


I/O 多路复用模型同时监听客户端连接;


单线程在执行过程中不需要进行上下文切换,减少了耗时。




相关文章
|
7月前
|
数据采集 人工智能 API
AI 智能体项目的费用
AI智能体开发费用远超普通编程,涵盖人力(60%-70%)、算力(API或私有GPU年费15万+)、数据工程(3万-10万)及持续调优(年维护费≈开发费20%)。预算从3万元低代码起步,到百万级企业级方案不等。
|
3月前
|
存储 人工智能 安全
CodeGraph爆火:编程Agent的效率革命,一张代码地图替代无限上下文
在AI编程快速普及的当下,编程Agent正成为开发者的核心生产力工具,但大型项目中的上下文困境始终难以突破。传统Agent依赖反复grep、glob、read等操作探索代码,不仅消耗海量Token,还常因信息遗漏导致逻辑错误,尤其在数十万行代码的复杂项目中,效率与成本问题愈发突出。CodeGraph的爆火,正是直击这一痛点——它用一张提前构建的代码地图,替代了无限堆砌的上下文,让编程Agent从“盲人摸象”升级为“精准导航”,彻底改变AI编程的底层逻辑。
320 1
|
9月前
|
JSON 监控 API
借助京东API,轻松分析用户行为,优化店铺页面布局!
本文介绍如何利用京东开放平台API获取用户浏览、点击、加购、搜索等行为数据,通过分析PV、UV、转化率、热力图等关键指标,洞察用户行为路径与页面问题,进而科学优化店铺首页布局、导航结构、商品展示及购物流程,并结合A/B测试与数据可视化工具持续迭代,提升用户体验与销售转化。
|
4月前
|
运维 监控 机器人
告警覆盖率90%以上,值班团队却越来越累?问题出在告警治理这一步
监控覆盖率做到90%以上,值班团队反而越来越累?本文从实际项目出发,拆解告警分级、去重、归并、路由4个动作,附Python去重逻辑和钉钉通知代码,帮你把"告警洪水"变成可直接处理的事件流。
572 1
|
5月前
|
JSON 供应链 监控
阐述:通过1688商品ID获取1688商品详情数据API教程
本文详解1688商品详情API(item.get):含标准JSON返回结构、50+字段解析(基础/价格/规格/交易/商家/详情六大维度)、实战要点及避坑指南,适用于ERP同步、跨境铺货、比价选品与供应链管理等场景。
|
6月前
|
搜索推荐 开发者
阿里云账号实名认证教程方法(快速实名)2026年最新个人和企业用户实名认证全流程
本教程详解2026年阿里云最新实名认证流程:个人用户可通过支付宝扫码快速完成(5分钟内),企业用户支持法人扫脸、企业银行卡/支付宝等4种方式,最快几分钟通过。认证后可申领上云权益。
1317 1
|
6月前
|
存储 缓存 NoSQL
Redis主从复制
Redis主从复制通过全量同步、命令传播与增量复制三大机制,保障高可用与数据一致性。主节点处理读写并同步数据,从节点分担读请求;借助repl_backlog_buffer环形缓冲区与偏移量机制,实现断线后高效增量恢复,有效避免单点故障与数据丢失。
305 0
|
8月前
|
人工智能 自然语言处理 供应链
拒绝“满头大汗”的工作:看顶级 AI 调度官如何优雅地解决跨部门纠纷
本文提出“AI调度官”新范式,以Agentic Workflow为引擎、RAG构建唯一真理库、LUI+Generative UI实现无情绪协作,将跨部门内耗转化为算法博弈。告别“人肉路由器”,用确定性替代情绪化争执,助力管理者从救火队员跃升为系统建筑师。
471 2
|
9月前
|
JSON 数据格式 Docker
08-Registry搭建docker私仓
Docker Registry是Docker官方提供的私有镜像仓库工具,支持本地部署。通过拉取registry镜像并运行容器,可快速搭建私服。需配置insecure-registries以支持HTTP访问,推送镜像前添加私仓地址tag,再使用docker push上传。通过curl查看镜像目录,验证上传结果,也可拉取镜像进行测试,实现镜像的集中管理与分发。
331 1
|
机器学习/深度学习 人工智能 自然语言处理
AI 世界生存手册(二):从LR到DeepSeek,模型慢慢变大了,也变强了
大家都可以通过写 prompt 来和大模型对话,那大模型之前的算法是怎样的,算法世界经过了哪些比较关键的发展,最后为什么是大模型这条路线走向了 AGI,作者用两篇文章共5.7万字详细探索一下。 第一篇文章指路👉《AI 世界生存手册(一):从LR到DeepSeek,模型慢慢变大了,也变强了》
AI 世界生存手册(二):从LR到DeepSeek,模型慢慢变大了,也变强了