立即前往

活动

天翼云最新优惠活动,涵盖免费试用,产品折扣等,助您降本增效!
查看全部活动
热门活动
  • 智算采购季 热销S6云服务器2核4G限时88元/年起,部分主机可加赠对象存储组合包!
  • 免费体验DeepSeek,上天翼云息壤 NEW 新老用户均可免费体验2500万Tokens,限时两周
  • 云上钜惠 HOT 爆款云主机全场特惠,更有万元锦鲤券等你来领!
  • 算力套餐 HOT 让算力触手可及
  • 天翼云脑AOne NEW 连接、保护、办公,All-in-One!
  • 一键部署Llama3大模型学习机 0代码一键部署,预装最新主流大模型Llama3与StableDiffusion
  • 中小企业应用上云专场 产品组合下单即享折上9折起,助力企业快速上云
  • 息壤高校钜惠活动 NEW 天翼云息壤杯高校AI大赛,数款产品享受线上订购超值特惠
  • 天翼云电脑专场 HOT 移动办公新选择,爆款4核8G畅享1年3.5折起,快来抢购!
  • 天翼云奖励推广计划 加入成为云推官,推荐新用户注册下单得现金奖励
免费活动
  • 免费试用中心 HOT 多款云产品免费试用,快来开启云上之旅
  • 天翼云用户体验官 NEW 您的洞察,重塑科技边界

智算服务

打造统一的产品能力,实现算网调度、训练推理、技术架构、资源管理一体化智算服务
智算云(DeepSeek专区)
科研助手
  • 算力商城
  • 应用商城
  • 开发机
  • 并行计算
算力互联调度平台
  • 应用市场
  • 算力市场
  • 算力调度推荐
一站式智算服务平台
  • 模型广场
  • 体验中心
  • 服务接入
智算一体机
  • 智算一体机
大模型
  • DeepSeek-R1-昇腾版(671B)
  • DeepSeek-R1-英伟达版(671B)
  • DeepSeek-V3-昇腾版(671B)
  • DeepSeek-R1-Distill-Llama-70B
  • DeepSeek-R1-Distill-Qwen-32B
  • Qwen2-72B-Instruct
  • StableDiffusion-V2.1
  • TeleChat-12B

应用商城

天翼云精选行业优秀合作伙伴及千余款商品,提供一站式云上应用服务
进入甄选商城进入云市场创新解决方案
办公协同
  • WPS云文档
  • 安全邮箱
  • EMM手机管家
  • 智能商业平台
财务管理
  • 工资条
  • 税务风控云
企业应用
  • 翼信息化运维服务
  • 翼视频云归档解决方案
工业能源
  • 智慧工厂_生产流程管理解决方案
  • 智慧工地
建站工具
  • SSL证书
  • 新域名服务
网络工具
  • 翼云加速
灾备迁移
  • 云管家2.0
  • 翼备份
资源管理
  • 全栈混合云敏捷版(软件)
  • 全栈混合云敏捷版(一体机)
行业应用
  • 翼电子教室
  • 翼智慧显示一体化解决方案

合作伙伴

天翼云携手合作伙伴,共创云上生态,合作共赢
天翼云生态合作中心
  • 天翼云生态合作中心
天翼云渠道合作伙伴
  • 天翼云代理渠道合作伙伴
天翼云服务合作伙伴
  • 天翼云集成商交付能力认证
天翼云应用合作伙伴
  • 天翼云云市场合作伙伴
  • 天翼云甄选商城合作伙伴
天翼云技术合作伙伴
  • 天翼云OpenAPI中心
  • 天翼云EasyCoding平台
天翼云培训认证
  • 天翼云学堂
  • 天翼云市场商学院
天翼云合作计划
  • 云汇计划
天翼云东升计划
  • 适配中心
  • 东升计划
  • 适配互认证

开发者

开发者相关功能入口汇聚
技术社区
  • 专栏文章
  • 互动问答
  • 技术视频
资源与工具
  • OpenAPI中心
开放能力
  • EasyCoding敏捷开发平台
培训与认证
  • 天翼云学堂
  • 天翼云认证
魔乐社区
  • 魔乐社区

支持与服务

为您提供全方位支持与服务,全流程技术保障,助您轻松上云,安全无忧
文档与工具
  • 文档中心
  • 新手上云
  • 自助服务
  • OpenAPI中心
定价
  • 价格计算器
  • 定价策略
基础服务
  • 售前咨询
  • 在线支持
  • 在线支持
  • 工单服务
  • 建议与反馈
  • 用户体验官
  • 服务保障
  • 客户公告
  • 会员中心
增值服务
  • 红心服务
  • 客户支持计划
  • 专家技术服务
  • 备案管家

了解天翼云

天翼云秉承央企使命,致力于成为数字经济主力军,投身科技强国伟大事业,为用户提供安全、普惠云服务
品牌介绍
  • 关于天翼云
  • 智算云
  • 天翼云4.0
  • 新闻资讯
  • 天翼云APP
基础设施
  • 全球基础设施
  • 产品能力
  • 信任中心
最佳实践
  • 精选案例
  • 超级探访
  • 云杂志
  • 分析师和白皮书
  • 天翼云·创新直播间
市场活动
  • 2025智能云生态大会
  • 2024智算云生态大会
  • 2023云生态大会
  • 2022云生态大会
  • 天翼云中国行
天翼云
  • 活动
  • 智算服务
  • 产品
  • 解决方案
  • 应用商城
  • 合作伙伴
  • 开发者
  • 支持与服务
  • 了解天翼云
    • 关系数据库SQL Server版
    • 企业主机安全
    • 云防火墙
    • CDN加速
    • 物理机
    • GPU云主机
    • 天翼云电脑(政企版)
    • 天翼云电脑(公众版)
    • 云主机备份
    • 弹性云主机
      搜索发现
      关系数据库SQL Server版企业主机安全云防火墙CDN加速物理机GPU云主机天翼云电脑(政企版)天翼云电脑(公众版)云主机备份弹性云主机
    • 文档
    • 控制中心
    • 备案
    • 管理中心
    • 登录
    • 免费注册

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    首页 知识中心 存储 文章详情页

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    2023-02-24 10:12:47 阅读次数:451

    偏移量,RocketMQ,缓存

    RocketMQ的发展历史

    RocketMQ是一个统一消息引擎、轻量级数据处理平台。RocketMQ是一款阿里巴巴开源的消息中间件。 2016 年 11 月 28 日,阿里巴巴向 广西党性培训 Apache 软件基金会捐赠RocketMQ,成为 Apache 孵化项目。 2017 年 9 月 25 日,Apache 宣布 RocketMQ孵化成为 Apache 顶级项目(TLP ),成为国内首个互联网中间件在 Apache 上的顶级项目。

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    RocketMQ的定位说明

    RocketMQ作为一款基于磁盘存储的中间件,具有无限积压能力,并提供高吞吐、低延迟的服务能力,其最核心的部分必然是它优雅的存储设计。本系列文章主要针对于RocketMQ的多个关键特性的实现原理进行深入介绍,并对消息中间件遇到的各种问题进行总结,阐述 RocketMQ如何解决这些问题。

    RocketMQ的核心工作机制

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    由上图可以看到RocketMQ存储的文件主要包括Commitlog文件、ConsumeQueue文件、Index文件。而对于消息存储是RocketMQ中最为复杂和最为重要的一部分,接下来会从RocketMQ的消息存储整体架构、PageCache与Mmap内存映射以及RocketMQ中两种不同的刷盘方式三方面来分别展开叙述。

    RocketMQ的存储设计介绍

    • CommitLog:RocketMQ将所有主题的消息存储在同一个文件中,确保消息发送时按顺序写文件,尽最大能力确保消息发送的高可用性与高吞吐量。

    • ConsumeQueue:消息中间件一般都是基于Topic的订阅与发布模式,消息消费时必须按照主题进行筛选消息,显然从Commitlog文件中按照topic去筛选消息会变得及其低效,为了提高根据主题检索消息的效率,RocketMQ引入了ConsumeQueue文件,俗成消费队列文件。

    • index文件:关系型数据库可以按照字段属性进行记录检索,作为一款主要面向业务开发的消息中间件,RocketMQ也提供了基于消息属性的检索能力,底层的核心设计理念是为Commitlog文件建立哈希索引,并存储在Index文件中。

    在RocketMQ中顺序写入到Commitlog文件后,ConsumeQueue与Index文件都是异步构建的,其数据流向图如下:

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    如果觉得上面的流程过于复杂的话,那么我就就给大家展示一个最简单的模式图:

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    根据上面的图可以看出来了吧。就是三者之间的关系和联系,那么我们来仔细以下这三个介质的的底层实现是什么。

    Commitlog文件

    消息主体以及元数据的存储主体,存储Producer端写入的消息主体内容,消息内容不是定长的。单个文件大小默认1G 。

    CommitLog的命名规则
    • 从上面的图中也可以看得出来,其文件的命名也及其巧妙,使用该存储在消息文件中的第一个全局偏移量来命名文件文件名长度为20位,左边补零,剩余为起始偏移量,比如00000000000000000000代表了第一个文件,起始偏移量为0,文件大小为1G=1073741824;消息主要是顺序写入日志文件,当文件满了,写入下一个文件;这样的设计主要是方便根据消息的物理偏移量,快速定位到消息所在的物理文件,第二个文件为00000000001073741824,起始偏移量为1073741824,以此类推。

    CommitLog的性能读写

    RocketMQ在消息写入过程中追求极致的磁盘的读写性能。所有主题的消息随着到达Broker的顺序写入commitlog文件。Commitlog文件使用顺序写,极大提高了文件的写性能。 当顺序依次追加到文件中,消息一旦写入,就无法再进行修改。Commitlog文件的具体布局如下图所示:

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    基于磁盘文件的与基于内存读取机制有一个本质的不同点,就是在内存读取模式下基本上是现成的数据结构,例如,数据、集合或者哈希表等,对数据的读写非常方便,但是针对于磁盘存储读取的Commitlog文件,我们该如何如何搜索,这时候我们引入了ConsumeQueue,我们后面会进行相关的说明和介绍。

    • RocketMQ与关系型数据会为每一条数据引入一个ID主键,在基于磁盘的读取机制中,也会为一条Message引入一个唯一标志:消息物理偏移量,即消息存储在文件的起始位置。

    • 正是有了物理偏移量的概念,这也与上面提到的Commitlog的文件名命名相互呼应,这样做的好处是给出任意一个消息的物理偏移量,例如消息偏移量为 12345678,可以通过二分法进行查找,快速定位这个文件在第一个文件中,然后用消息的物理偏移量减去该文件的名称所得到的差值,就是在该文件中的绝对地址。

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    ConsumeQueue的读取模式

    ConsumeQueue消息消费队列,引入的目的主要是提高消息消费的性能,由于RocketMQ是基于主题topic的订阅模式,消息消费是针对主题进行的,如果要遍历commitlog文件中根据topic检索消息是非常低效的。

    • ConsumeQueue文件是Commitlog文件基于Topic的索引文件,主要用于消费者根据Topic消费消息,其组织方式为/topic/queue,同一个队列中存在多个文件。

    • Consumer即可根据ConsumeQueue来查找待消费的消息。其中,ConsumeQueue(逻辑消费队列)作为消费消息的索引,保存了指定Topic下的队列消息在CommitLog中的起始物理偏移量offset,消息大小size和消息Tag的HashCode值。

    注意:ConsumeQueue中的每个条目长度固定20个字节(8字节commitlog物理偏移量、4字节消息长度、8字节tag hashcode(这里不是存储tag的原始字符串,而选择存储hashcode)),每个条目的长度固定,可以使用访问类似数组下标的方式快速定位条目,极大地提高了ConsumeQueue文件的读取性能。

    ConsumeQueue的读取消息偏移量
    1. 首先,消息消费者根据topic、消息消费进度(ConsumeQueue逻辑偏移量),即第几个ConsumeQueue条目,这样的消费进度去访问消息的方法为使用逻辑偏移量logicOffset * 20即可找到该条目的起始偏移量(ConsumeQueue文件中的偏移量),然后读取该偏移量后20个字节即得到一个条目,无须遍历ConsumeQueue文件。

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    • 第N个消ConsumeQueue的元素数据的索引开始:(N-1)* 20+1

    • 第N个消ConsumeQueue的元素数据的索引结束:(N)* 20

    ConsumeQueue文件夹如下:topic/queue/file三层组织结构,地址:$HOME/store/ConsumeQueue/{topic}/{queueId}/{fileName}。单个ConsumerQueue文件由30W个条目组成,可以像数组一样随机访问每一个条目,每个ConsumeQueue文件大小约5.72M;

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    存储结构分析总结

    • 数据单独存储到一个Commit Log完全

    • 队列实际只存储消息在Commit Log的位置信息,并且串行方式刷盘。

    这样做的优点

    • 队列轻量化,单个队列数据量非常少。

    • 对磁盘的访问串行化,避免磁盘竟争,不会因为队列增加导致 IOWAIT 增高。

    这样做的缺点

    • 写虽然完全是顺序写,但是读却变成了完全的随机读。

    • 读一条消息,会先读 Consume Queue,再读 Commit Log,增加了开销。

    • 要保证 Commit Log 与 Consume Queue 完全的一致,增加了编程的复杂度。

    以上缺点如何克服
    • 随机读,尽可能让读命中PAGECACHE,减少 IO 读操作,所以内存越大越好。

    • 访问 PAGECACHE 时,即使只访问1k 的消息,系统也会提前预读出更多数据,在下次读时,就可能命中内存。

    • 随机访问 Commit Log 磁盘数据,系统 IO 调度算法设置为 NOOP 方式,会在一定程度上将完全的随机读变成顺序跳跃方式,而顺序跳跃方式读较完全的随机读性能会高5倍以上。

    4k的消息在完全随机访问情况下,仍然可以达到8K次每秒以上的读性能。RocketMQ与Kafka相比具有一个强大的优势,就是支持按消息属性检索消息,引入consumequeue文件解决了基于topic查找的问题,但如果想基于消息的某一个属性查找消息,ConsumeQueue文件就无能为力了,为了解决此问题RocketMQ引入了Index索引文件,实现基于文件的哈希索引。

    ConsumeQueue和CommitLog的总结介绍

    CommitLog 中存储了所有的元信息,包含消息体,类似于 Mysql、Oracle 的 binlog,所以只要有CommitLog 在,ConsumeQueue即使数据丢失,仍然可以恢复出来。

    IndexFile文件

    IndexFile文件基于物理磁盘文件实现Hash索引。其文件由40字节的文件头、500万个哈希槽,每个哈希槽4个字节,最后由2000万个Index条目,每个条目由20个字节构成,分别为4字节索引key的hashcode、8字节消息物理偏移量、4字节时间戳、4字节的前一个Index条目(哈希冲突的链表结构)。

    IndexFile的文件存储结构如下图所示:

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    其原理和读取方式与ConsumerQueue较为相似,至此不过多赘述。对于IndexFile文件和ConsumerQueue文件都是,Broker端的后台服务线程—ReputMessageService不停地分发请求并异步构建ConsumeQueue(逻辑消费队列)和IndexFile(索引文件)数据。

    页缓存与内存映射

    RocketMQ中,ConsumeQueue逻辑消费队列存储的数据较少,并且是顺序读取,在PageCache机制的预读取作用下,ConsumeQueue文件的读性能几乎接近读内存,即使在有消息堆积情况下也不会影响性能。而对于CommitLog消息存储的日志数据文件来说,读取消息内容时候会产生较多的随机访问读取,严重影响性能。(此时块存储采用SSD的话),随机读的性能也会有所提升。

    内存映射mmap

    虽然基于磁盘的顺序写可以极大提高IO的写效率,但如果基于文件的存储采用常规的JAVA文件操作API,例如 FileOutputStream等,其性能提升会很有限,RocketMQ引入了内存映射,将磁盘文件映射到内存中,以操作内存的方式操作磁盘,性能又提升了一个档次。

    JAVA中可通过FileChannel的map方法创建内存映射文件。在Linux服务器中由该方法创建的文件使用的是操作系统的pagecache,即页缓存。

    • Linux操作系统中的内存使用策略时会尽可能地利用机器的物理内存,并常驻内存中,就是所谓的页缓存。在操作系统的内存不够的情况下,采用缓存置换算法,例如LRU将不常用的页缓存回收,即操作系统会自动管理这部分内存。

    • 如果RocketMQ Broker进程异常退出,存储在页缓存中的数据并不会丢失,操作系统会定时将页缓存中的数据持久化到磁盘,做到数据安全可靠。不过如果是机器断电等异常情况,存储在页缓存中的数据就有可能丢失。

    页缓存PageCache

    页缓存(PageCache)是OS对文件的缓存,用于加速对文件的读写。

    • 程序对文件进行顺序读写的速度几乎接近于内存的读写速度,主要原因就是由于OS使用PageCache机制对读写访问操作进行了性能优化,将一部分的内存用作PageCache。

    • 对于数据的写入,OS会先写入至Cache内,随后通过异步的方式由pdflush内核线程将Cache内的数据刷盘至物理磁盘上。

    • 对于数据的读取,如果一次读取文件时出现未命中PageCache的情况,OS从物理磁盘上访问读取文件的同时,会顺序对其他相邻块的数据文件进行预读取。

    是否使用堆外内存

    RocketMQ为了降低PageCache的使用压力引入了transientStorePoolEnable机制,即内存级别的读写分离机制。

    默认情况下RocketMQ将消息写入PageCache,消息消费时从PageCache中读取,这样在高并发时PageCache的压力会比较大,容易出现瞬时broker busy。

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    RocketMQ还引入了transientStorePoolEnable=true,将消息先写入堆外内存并立即返回,然后异步将堆外内存中的数据提交到pagecache,再异步刷盘到磁盘中。其工作机制如下图所示:

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    消息在消费读取时不会尝试从堆外内存中读,而是从PageCache中读取,这样就形成了内存级别的读写分离,即消息写入时主要面对堆外内存,而读消息时主要面对pagecache。

    • 优点是消息是直接写入堆外内存,然后异步写入pagecache。相比每条消息追加直接写入pagechae,其最大的优势是将消息写入PageCache操作批量化。

    • 缺点是如果由于某些意外操作导致Broker进程异常退出,那么存储在堆外内存的数据会丢失,但如果是放入pagecache,broker异常退出并不会丢失消息。

    刷盘机制

    有了顺序写和内存映射的加持,RocketMQ的写入性能得到了极大的保证,但凡事都有利弊,引入了内存映射和页缓存机制,消息会先写入到页缓存,此时消息并没有真正持久化到磁盘。那么broker收到客户端的消息发送后,是存储到页缓存中就直接返回成功,还是要持久化到磁盘中才返回成功呢?

    这是一个“艰难”的抉择,是在性能与消息可靠性方面进行权衡。为此,RocketMQ提供了多种策略:同步刷盘、异步刷盘。

    同步刷盘

    同步刷盘在RocketMQ的实现中成为组提交,并不是每一条消息都必须刷盘。采用同步刷盘,每一个线程将数据追到到内存后,并向刷盘线程提交刷盘请求,然后会阻塞;刷盘线程从任务队列中获取一个任务,然后触发一次刷盘,但并不只刷与请求相关的消息,而是会直接将内存中待刷盘的所有消息一次批量刷盘,然后就可以唤醒一组请求线程,实现组刷盘。

    同步刷盘的优点是能保证消息不丢失,即向客户端返回成功就代表这条消息已被持久化到磁盘,即消息非常可靠,但这是以牺牲写入响应延迟性能为代价的,由于RocketMQ的消息是先写入pagecache,故消息丢失的可能性较小,如果能容忍一定几率的消息丢失,可以考虑使用异步刷盘。

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    如上图所示,只有在消息真正持久化至磁盘后RocketMQ的Broker端才会真正返回给Producer端一个成功的ACK响应。同步刷盘对MQ消息可靠性来说是一种不错的保障,但是性能上会有较大影响,一般适用于金融业务应用该模式较多。

    异步刷盘

    异步刷盘指的是broker将消息存储到pagecache后就立即返回成功,然后开启一个异步线程定时执行FileChannel的forece方法,将内存中的数据定时刷写到磁盘,默认间隔为500ms。

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    能够充分利用OS的PageCache的优势,只要消息写入PageCache即可将成功的ACK返回给Producer端。消息刷盘采用后台异步线程提交的方式进行,降低了读写延迟,提高了MQ的性能和吞吐量。

    精华推荐 | 【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」透彻剖析贯穿RocketMQ的存储系统的实现原理和持久化机制

    GroupCommitService 从队列中拿出待刷盘请求request, 然后执行刷盘动作, 此时会将write指针与flush指针之间的所有数据刷写到磁盘中,即这里并不只是将request l对应的那一条消息刷写到磁盘

    MySQL的持久化机制对比

    MySQL Redo 日志的引入目的,我们知道在 MySQL InnoDB 的存储引擎中,会有一个内存 Pool,用来缓存磁盘的文件块,当更新语句将数据修改后,会首先在内存中进行修改,然后将变更写入到 redo 文件(刷写到磁盘),然后定时将InnoDB内存池中的数据刷写到磁盘。

    RocketMQ的持久化存储机制总结

    RocketMQ采用的是混合型的存储结构,即为Broker单个实例下所有的队列共用一个日志数据文件(即为CommitLog)来存储。混合型存储结构(多个Topic的消息实体内容都存储于一个CommitLog中),针对Producer和Consumer分别采用了数据和索引部分相分离的存储结构。

    • Producer发送消息至Broker端,然后Broker端使用同步或者异步的方式对消息刷盘持久化,保存至CommitLog中。只要消息被刷盘持久化至磁盘文件CommitLog中,那么Producer发送的消息就不会丢失。

    • Consumer也就肯定有机会去消费这条消息。当无法拉取到消息后,可以等下一次消息拉取,同时服务端也支持长轮询模式,如果一个消息拉取请求未拉取到消息,Broker允许等待30s的时间,只要这段时间内有新消息到达,将直接返回给消费端。

    版权声明:本文内容来自第三方投稿或授权转载,原文地址:https://blog.51cto.com/alex4dream/5878683,作者:洛神灬殇,版权归原作者所有。本网站转在其作品的目的在于传递更多信息,不拥有版权,亦不承担相应法律责任。如因作品内容、版权等问题需要同本网站联系,请发邮件至ctyunbbs@chinatelecom.cn沟通。

    上一篇:SQL:redis缓存数据库深入

    下一篇:c++primer plus 6 读书笔记 第十二章 类和动态内存分配

    相关文章

    2025-04-22 09:40:08

    【ETL工具】Kettle 调优 (使用阻塞组件的同时数据量大)

    【ETL工具】Kettle 调优 (使用阻塞组件的同时数据量大)

    2025-04-22 09:40:08
    组件 , 缓存 , 队列
    2025-04-18 07:10:38

    学习 SSR(Server-Side Rendering)的心得和体会

    在现代的前端开发中,性能优化和用户体验始终是核心考量之一。而在众多优化策略中,服务器端渲染(Server-Side Rendering,简称SSR)是一个重要的概念。

    2025-04-18 07:10:38
    优化 , 客户端 , 服务器 , 服务器端 , 渲染 , 缓存
    2025-04-18 07:09:19

    深入理解Spring中的Bean循环依赖与解决机制

    Bean循环依赖是指两个或多个Bean之间相互依赖,形成依赖闭环的情况。例如,Bean A依赖Bean B,而Bean B又依赖Bean A。这种情况下,如果没有特殊处理,容器将无法正确初始化这些Bean,从而导致应用启动失败。

    2025-04-18 07:09:19
    Bean , Spring , 依赖 , 初始化 , 循环 , 缓存 , 解决
    2025-04-15 09:24:56

    Redis多级缓存指南:从前端到后端全方位优化!

    在现代互联网应用中,高性能和高可用性是两个非常重要的目标。为了达到这些目标,我们通常会使用缓存技术,其中 Redis 是一种非常受欢迎的缓存中间件。

    2025-04-15 09:24:56
    内存 , 存储 , 数据 , 服务器 , 浏览器 , 磁盘 , 缓存
    2025-04-15 09:20:07

    Redis经典问题:缓存击穿

    缓存击穿是指在高并发场景下,同一时刻有大量用户请求同一条数据。当这条数据在缓存中不存在时(即缓存未命中),所有请求同时去查询数据库。这种情况下,数据库会瞬间受到大量请求的压力,导致性能瓶颈或系统崩溃。

    2025-04-15 09:20:07
    互斥 , 数据 , 数据库 , 示例 , 缓存 , 过期
    2025-04-15 09:20:07

    Redis经典问题:数据不一致

    数据不一致是指缓存中的数据和数据库中的数据存在差异。这种问题通常出现在缓存系统与数据库之间的同步过程中。当缓存中的数据与数据库中的数据不匹配时,会导致应用程序读取错误或过时的数据,从而影响应用的稳定性和性能。

    2025-04-15 09:20:07
    一致性 , 写入 , 数据 , 数据库 , 确保 , 缓存
    2025-04-15 09:19:55

    Redis经典问题:BigKey问题

    在Redis中,每个Key都会对应一个Value,而这个Value的大小会影响Redis的性能表现。当我们存储的Value特别大时,就会出现BigKey问题。

    2025-04-15 09:19:55
    Key , Redis , 数据结构 , 系统 , 缓存 , 问题
    2025-04-15 09:19:55

    分布式事务大揭秘:使用MQ实现最终一致性

    在单体应用中,事务的管理相对简单,可以通过数据库的事务机制来保证数据的一致性和完整性。然而,在分布式系统中,由于涉及到多个不同的服务和数据源,保证事务的一致性就变得复杂了。

    2025-04-15 09:19:55
    RocketMQ , 一致性 , 事务 , 分布式 , 发送 , 消息 , 系统
    2025-04-15 09:19:55

    Redis经典问题:数据并发竞争

    Redis经典问题:数据并发竞争

    2025-04-15 09:19:55
    备份 , 并发 , 数据 , 系统 , 缓存 , 读取
    2025-04-11 07:11:40

    java中常用的缓存框架

    java中常用的缓存框架

    2025-04-11 07:11:40
    API , Cache , Java , 分布式 , 缓存
    查看更多
    推荐标签

    作者介绍

    天翼云小翼
    天翼云用户

    文章

    32777

    阅读量

    4794147

    查看更多

    最新文章

    【ETL工具】Kettle 调优 (使用阻塞组件的同时数据量大)

    2025-04-22 09:40:08

    Redis多级缓存指南:从前端到后端全方位优化!

    2025-04-15 09:24:56

    Redis经典问题:数据不一致

    2025-04-15 09:20:07

    Redis经典问题:缓存击穿

    2025-04-15 09:20:07

    Redis经典问题:BigKey问题

    2025-04-15 09:19:55

    thinkphp使用文件缓存的实例

    2025-04-01 10:28:25

    查看更多

    热门文章

    leetcode数据结构-LRU

    2023-03-02 10:21:35

    elasticsearch预加载数据到文件系统缓存

    2024-09-25 10:13:57

    jedis工具类

    2023-02-16 08:14:03

    ajax get缓存问题+ajax post请求

    2023-06-07 07:32:36

    nginx反向代理(2)

    2024-07-01 01:32:03

    自定义注解

    2023-06-16 06:11:10

    查看更多

    热门标签

    存储 缓存 内存 数据库 数据 redis mysql 服务器 数据恢复 Redis linux java sql MySQL 数据结构
    查看更多

    相关产品

    弹性云主机

    随时自助获取、弹性伸缩的云服务器资源

    天翼云电脑(公众版)

    便捷、安全、高效的云电脑服务

    对象存储

    高品质、低成本的云上存储服务

    云硬盘

    为云上计算资源提供持久性块存储

    查看更多

    随机文章

    一分钟get:缓存穿透、缓存击穿、缓存雪崩 - 第304篇

    MySQL学习笔记(一)--逻辑架构学习

    Dubbo【Dubbo高级特性(重试机制、多版本 、负载均衡 、集群容错 、服务降级、服务限流原理 、结果缓存) 】(三)-全面详解(学习总结---从入门到深化)

    【redis】redis缓存穿透及解决方案|缓存穿透,缓存击穿,雪崩的理解

    Linux--CPU简述

    驱动保护 -- 通过PID保护指定进程

    • 7*24小时售后
    • 无忧退款
    • 免费备案
    • 专家服务
    售前咨询热线
    400-810-9889转1
    关注天翼云
    • 权益商城
    • 天翼云APP
    • 天翼云微信公众号
    服务与支持
    • 备案中心
    • 售前咨询
    • 智能客服
    • 自助服务
    • 工单管理
    • 客户公告
    • 涉诈举报
    账户管理
    • 管理中心
    • 订单管理
    • 余额管理
    • 发票管理
    • 充值汇款
    • 续费管理
    快速入口
    • 权益商城
    • 文档中心
    • 最新活动
    • 免费试用
    • 信任中心
    • 天翼云学堂
    云网生态
    • 甄选商城
    • 渠道合作
    • 云市场合作
    了解天翼云
    • 关于天翼云
    • 天翼云APP
    • 服务案例
    • 新闻资讯
    • 联系我们
    热门产品
    • 云电脑
    • 弹性云主机
    • 云电脑政企版
    • 天翼云手机
    • 云数据库
    • 对象存储
    • 云硬盘
    • Web应用防火墙
    • 服务器安全卫士
    • CDN加速
    热门推荐
    • 云服务备份
    • 边缘安全加速平台
    • 全站加速
    • 安全加速
    • 云服务器
    • 云主机
    • 智能边缘云
    • 应用编排服务
    • 微服务引擎
    • 共享流量包
    更多推荐
    • web应用防火墙
    • 密钥管理
    • 等保咨询
    • 安全专区
    • 应用运维管理
    • 云日志服务
    • 文档数据库服务
    • 云搜索服务
    • 数据湖探索
    • 数据仓库服务
    友情链接
    • 中国电信集团
    • 189邮箱
    • 天翼企业云盘
    • 天翼云盘
    ©2025 天翼云科技有限公司版权所有 增值电信业务经营许可证A2.B1.B2-20090001
    公司地址:北京市东城区青龙胡同甲1号、3号2幢2层205-32室
    • 用户协议
    • 隐私政策
    • 个人信息保护
    • 法律声明
    备案 京公网安备11010802043424号 京ICP备 2021034386号