自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(69)
  • 收藏
  • 关注

原创 破晓分布式之巅:拜占庭将军问题的底层博弈与共识本质

拜占庭将军问题作为分布式系统领域的“圣杯级”难题,由图灵奖得主 Leslie Lamport 提出,核心探讨在存在恶意节点与不可靠网络的分布式环境下如何达成全局一致。本文将军事寓言映射为计算机底层模型,从理论极限(异步系统的不可能性)、容错边界(3m13m+13m1理论)及 Paxos 与 PBFT 的底层设计分化切入,深度拆解工程界如何通过环境假设、CRC 校验与多轮共识跨越信任鸿沟。

2026-08-28 14:14:35 258

原创 架构底层探秘:分布式全局唯一 ID 的演进之路与核心实现

在分布式架构演进中,全局唯一 ID 是承载高并发写、分库分表与数据对账的基石。本文从底层存储引擎与物理模型出发,深度剖析 UUID 的索引灾难、数据库号段模式的批次缓冲机制,以及雪花算法(Snowflake)基于位运算的极致时序艺术。通过对比不同方案在磁盘 I/O、并发吞吐与时钟回拨等维度的表现,揭示分布式 ID 选型的本质权衡。UUID(通用唯一识别码)标准长度为 128 位,通常表现为 36 个字符的字符串(含连字符)。理解分布式 ID 的底层运作,必须透视其在极限并发与极端环境下的失效边界。

2026-08-28 14:14:05 261

原创 分布式锁与 CAP 理论:底层机制、CP/AP 权衡与选型破局之道

本文从单机并发的局限性切入,深度拆解分布式锁的定义、解决的核心痛点以及 CAP 理论的底层博弈。在此基础上,结合存储引擎、共识算法与主从复制模型,透彻剖析 Redis、ZooKeeper 及 MySQL 在分布式锁实现上的失效本质,最后给出高并发生产环境下的选型决策矩阵与工程兜底方案。在动手优化或选型之前,必须先理清分布式锁的物理定义、它所消解的痛点,以及制约其架构设计的底层理论天花板。单机并发的局限:在传统单体应用时代,多个线程运行在同一个 JVM 进程内,共享同一片内存空间。

2026-08-28 14:08:59 330

原创 深入浅出 CAP 理论:分布式系统的设计边界与权衡艺术

CAP 理论常被戏称为“帽子理论”:它由加州理工大学伯克利分校的 Eric Brewer 教授在 2000 年 7 月的 ACM PODC 会议上首次提出。

2026-08-28 14:08:04 278

原创 分布式 ID 方案:Snowflake 算法与时钟回拨处理深度剖析

Snowflake(雪崩算法)作为分布式 ID 生成的核心方案,凭借其高性能、趋势递增与无依赖特性广泛应用于订单与用户体系。然而,时钟回拨(Clock Rollback)是其在生产环境中最致命的隐患。本文深度剖析 Snowflake 的结构设计、时钟回拨的产生根源,并给出基于“时间槽位比较”与“最大等待机制”的生产级防御方案。

2026-08-28 14:04:28 283

原创 Seata AT 与 TCC 模式深度对比:从一阶段锁机制到二阶段回滚实现

本文深入对比 Apache Seata 框架中 AT 模式与 TCC 模式的核心运行机制。重点剖析两者在一阶段资源预留(本地事务与业务软状态)、二阶段提交/回滚的底层加锁逻辑(本地数据库锁与全局锁的演进),并结合高并发生产环境,给出锁冲突调优、空回滚防范及架构选型策略。

2026-08-27 07:39:40 293

原创 CAP 与 BASE 理论权衡:从分布式一致性证明到生产架构折中设计

本文深入剖析分布式系统的基石——CAP 定理与 BASE 理论。通过理论推演厘清网络分区(P)的不可避免性,对比 CP 与 AP 系统的底层权衡逻辑,延伸至更细颗粒度的 PACELC 定理,并结合生产中间件(如 Nacos、ZooKeeper)的底层选型实践,给出高并发分布式架构的落地折中策略。

2026-08-27 07:38:44 380

原创 分布式架构知识体系:如何记忆

面对如此庞大的,死记硬背不仅痛苦而且容易遗忘。对于资深技术人员而言,最高效的记忆方法不是去背孤立的名词,而是建立“逻辑闭环”“工程痛点驱动”的认知模型。

2026-08-27 07:38:21 267

原创 深入浅出分布式架构:接口幂等性设计与硬核防重机制解析

分布式系统由于网络抖动、微服务重试及客户端重复提交,接口遭遇“同一次请求被多次执行”是常态。若缺乏幂等性保障,将直接导致数据错乱、资金资损等灾难性后果。本文从存储引擎的唯一索引约束、分布式锁的原子抢占模型、状态机的乐观锁演进等底层视角出发,系统性拆解接口幂等性的核心实现原理、并发防重失效的物理本质,并给出工业级的高性能防重架构落地指南。

2026-08-27 07:38:04 337

原创 资深 Java 工程师与架构师知识体系全景图

服务暴露、寻址、网络传输与动态代理;发布订阅与点对点模式对比。: 缓存穿透、击穿、雪崩的成因与治理方案;: String、Hash、List、Set、ZSet 底层编码与结构;: Nacos、Eureka、Consul、Apollo / Spring Cloud Config 架构对比;: 数组、链表、栈、队列、哈希表底层实现;红黑树、平衡二叉树、B 树、B+树特征与应用场景;

2026-08-27 07:37:33 353

原创 深度解密 BASE 理论:高并发分布式系统底部的最终一致性哲学

BASE 理论(Basically Available, Soft state, Eventually consistent)是 CAP 定理在工程实践中的延伸与妥协。面对大规模分布式环境下的网络分区常态,追求强一致性(CP)往往以牺牲可用性为代价。BASE 理论通过放弃实时强一致性,换取系统的基本可用与高吞吐,最终通过异步收敛达到数据的一致状态。本文从底层存储、一致性模型、核心三大支柱、工程应用场景以及柔性事务演进等多个维度,深度拆解分布式系统的一致性哲学与高并发落地实践。

2026-08-26 15:09:10 240

原创 Redis 知识体系

可以从底层数据结构、核心原理、高可用架构、生产环境常见问题及高级应用五个维度来进行系统化拆解。(避免高并发下多线程修改导致的数据覆盖问题)。导读:构建一个完整的。

2026-08-26 15:08:30 311

原创 深入分布式事务内核:从 2PC/XA 到 Seata AT 模式的架构演进与权衡

在微服务与分布式架构下,保证跨服务、跨数据库的数据强一致性是系统设计的核心挑战。本文深入剖析分布式事务的底层演进逻辑,重点拆解基于数据库内核的2PC/XA 协议(含 Prepare、Commit 与 Rollback 完整状态机推演及回滚防丢失机制)以及主流开源方案Seata AT 模式的物理模型、状态机运转本质与失效机制。不仅从理论上揭示了从传统两阶段提交的同步阻塞到 Seata AT 非侵入式 Undo Log 与全局锁的演进过程,更结合“用户注册送积分”这一经典业务场景,全面推演了2PC/XA 方案。

2026-08-26 14:59:50 376

原创 破局CAP魔咒:分布式柔性事务的底层机理与工程落地全解

在微服务架构与海量并发浪潮下,强一致性的两阶段提交(2PC/XA)因跨网络同步阻塞与数据库锁竞争遭遇严重性能瓶颈。以BASE理论为指导的柔性事务成为分布式系统架构解耦的核心支柱。本文深入解构分布式最终一致性的三大主流范式:控制力极高的TCC模式、吞吐量与解耦兼备的可靠消息一致性(本地消息表与MQ事务消息),以及长事务利器Saga模式。从状态机物理模型、工程异常防护到底层性能权衡,全景剖析柔性事务的内核本质。首先,定义一个库存服务接口,并通过注解明确指定一阶段Try方法以及二阶段的Confirm(提交)和。

2026-08-26 14:59:19 333

原创 华住会系统化的供应链业务知识架

为您将核心业务域、特色场景、技术落地及进阶路径进行深度融合,并在各个系统缩写旁补充了完整的英文全称及业务定义介绍,构建了一套结构清晰、重点突出的供应链业务知识架构:🏷️ 物资分类体系:精准区分客房布草(毛巾、床单)、一次性易耗品、清洁消杀、工程机电、办公用品及餐饮食材 (F&B) 供应链。🗂️ 品牌标准与 SPU / SKU:SPU (Standard Product Unit):标准化产品单元。SKU (Stock Keeping Unit):库存量单位。华住对多品牌调性有严格要求(如汉庭、全季、桔子

2026-08-26 09:23:22 345

原创 分布式架构知识体系

本文系统梳理了分布式架构的六大核心知识体系:1)理论基础(CAP定理、BASE理论等);2)一致性共识与分布式事务(Raft/Paxos算法、2PC/TCC);3)基础设施(注册中心、RPC、消息队列);4)存储方案(分库分表、分布式缓存);5)高可用设计(限流熔断、负载均衡、可观测性);6)微服务与云原生演进(DDD、K8s、Service Mesh)。内容涵盖分布式系统设计的关键理论与生产实践,为构建高并发、高可用系统提供完整技术图谱。

2026-08-24 21:50:02 173

原创 深度解密 Redis 核心引擎:从 MULTI/EXEC 事务机制到 EVAL 脚本的原子性演进

Redis 的高并发与高性能常归功于其单线程事件循环与内存存储模型。然而,当面临多步骤复杂业务逻辑时,如何保证数据状态的一致性至关重要。本文深入 Redis 内核,剖析MULTI/EXEC事务的隔离性缺陷、队列缓冲机制,以及 Lua 脚本(EVAL)如何通过服务端沙箱化执行彻底实现原子性,并结合实际架构场景给出选型指南。

2026-08-24 21:48:14 300

原创 Redis 深度内核解析与高性能运维调优指南

Redis 作为单/多线程混合模型的高性能内存数据库,极易受到“大 Key 阻塞”、“热 Key 倾斜”以及“内存碎片/CoW 内存膨胀”的严重威胁。本文从底层内存模型(jemalloc)、事件驱动视角及写时复制(CoW)机制出发,系统拆解 Big Key 的非阻塞删除(UNLINK)、Hot Key 的本地缓存防护、慢查询日志(Slowlog)的精准定位策略,以及内存碎片自动整理机制(通过生动的业务场景剖析高并发下的 Redis 调优底层逻辑,构建高可用运维防线。

2026-08-24 21:47:34 359

原创 Redis 主从复制内核深潜:从物理模型到全量增量同步的本质

Redis 主从复制是构建哨兵集群与分片集群的底层基石。本文从存储引擎与网络I/O视角出发,深度解构了主从复制的物理模型,详细剖析了全量同步(RDB快照与复制缓冲区协作)与部分重同步(基于复制积压缓冲区与 Offset/RunID 的环形复用机制)的底层运作逻辑。同时,指出了复制积压区溢出导致全量同步风暴的失效本质,并给出了针对主从延迟与拓扑优化的生产实践方案,助力彻底掌握 Redis 数据高可用的核心本质。

2026-08-24 21:46:52 1559

原创 深度解密:Redis 线程模型与高性能 I/O 演进之路

Redis 能够轻松支撑每秒数十万次请求,其核心奥秘在于基于 Reactor 模式的非阻塞 I/O 多路复用机制与纯内存操作。面对百G网卡时代的网络吞吐瓶颈,Redis 6 引入多线程处理网络读写,但核心命令执行依然保持单线程。本文深入拆解 Redis 线程与 I/O 模型的底层架构、演进逻辑及性能本质,揭示其在无锁状态下压榨极致硬件性能的工程智慧。

2026-08-24 21:46:24 292

原创 底层视角拆解:Redis Lua脚本原子性、主线程阻塞与主从不一致全解析

当 Lua 脚本执行时,主线程会独占该脚本的运行周期,期间不交出执行权,从而彻底规避了多命令并发下的竞态条件。例如在秒杀扣减库存场景中,将‘查库存、做判断、扣减’写在同一个 Lua 脚本里,由于主线程在同一时刻只能干一件事,这几条命令在内存中是串行、连续执行的,中间不会被任何其他客户端打断,从根本上杜绝了超卖现象。由于 Redis 主线程在同一时刻只能执行一个任务,当 Lua 脚本开始运行时,主线程的执行权完全被该脚本绑架,直到脚本彻底执行完毕并返回结果,事件循环才会恢复对其他客户端命令的响应。

2026-08-22 19:17:38 304

原创 Redis Cluster 为什么选择 ‌16384 个虚拟槽(Hash Slot)

虚拟槽方案就像是在“数据”和“物理节点”之间加了一层“可移动的集装箱(Slot)”。扩容时,我们只搬运集装箱,而不需要重新打包里面的货物。为了让你更直观地理解 Redis Cluster 为什么选择 16384 个虚拟槽(Hash Slot),而不是直接对节点数取模或使用一致性哈希,我们可以通过一个“图书馆分书”的类比来拆解这个设计。想象你要管理一个巨大的图书馆(Redis 集群),里面有成千上万本书(Key-Value 数据)。现在,你要增加第 4 个书架(节点 D)。二、 举例说明:扩容时的“神操作”

2026-08-22 19:16:52 248

原创 高可用底座:Redis 哨兵机制(Sentinel)底层内核拆解

Redis 哨兵是一个独立运行的进程,用于监控多个主从(Master-Slave)集群。其核心目的是实现自动化监控与故障切换,当 Master 节点宕机时,能够自动将 Slave 节点提升为新的 Master 节点。

2026-08-22 19:16:32 361

原创 Redis 主从复制内核深潜:从物理模型到全量增量同步的本质

Redis 主从复制是构建哨兵集群与分片集群的底层基石。本文从存储引擎与网络I/O视角出发,深度解构了主从复制的物理模型,详细剖析了全量同步(RDB快照与复制缓冲区协作)与部分重同步(基于复制积压缓冲区与 Offset/RunID 的环形复用机制)的底层运作逻辑。同时,指出了复制积压区溢出导致全量同步风暴的失效本质,并给出了针对主从延迟与拓扑优化的生产实践方案,助力彻底掌握 Redis 数据高可用的核心本质。

2026-08-22 19:15:59 318

原创 深度解密 Redis 分布式锁:从单机原子语义到集群架构博弈

🔍 150字摘要: Redis分布式锁利用单线程原子性实现资源互斥,通过SET NX PX指令避免死锁。核心陷阱包括:1)超时误删(需UUID校验+看门狗续期);2)主从丢锁(异步复制导致,严苛场景需切ZK/Etcd)。工业级方案推荐Redisson,其Lua脚本保证原子操作,看门狗自动续期防GC卡顿。生产环境需结合锁粒度拆分与业务幂等设计,面试需涵盖原子性、续期机制及高可用权衡。Redis锁适合高频低冲突场景,强一致需求需换方案。

2026-08-22 19:15:11 360

原创 Redis 内存管理与回收全景解析:从底层分配模型到驱逐算法内核

📝 Redis内存管理与回收机制解析 核心要点: 底层架构 采用redisObject结构体(16字节)统一封装数据,结合jemalloc内存分配器的阶梯对齐策略,有效减少内存碎片。 过期键清理 双轨策略:惰性删除(访问时检查) + 定期删除(每秒随机抽样20个键),平衡CPU与内存效率。 内存淘汰策略 8种策略按作用范围(全库/过期键)和算法(LRU/LFU/随机/TTL)组合,默认noeviction拒绝写入。 近似算法:通过随机采样(默认5个键)和24位lru字段(时间戳+频次计数器)实现高效淘汰,

2026-08-21 08:53:26 285

原创 深度解密 Redis 分布式锁:从底层原语到生产级落地

🔍 文章摘要 分布式锁是微服务架构下解决资源竞态的核心组件。本文从存储引擎和协议层深度剖析Redis与ZooKeeper的分布式锁实现原理。Redis基于单线程原子命令和内存模型,通过SET NX PX指令和Lua脚本保证原子性,但面临主从异步复制的AP风险;ZooKeeper则依托Zab协议和临时顺序节点的树形结构,实现强一致的CP保证。二者在性能、一致性和容错性上存在本质差异:Redis吞吐量高但存在脑裂风险,适合电商秒杀等场景;ZooKeeper一致性严格但性能较低,适用于金融交易等强一致性场景。文

2026-08-21 08:52:40 284

原创 Redis 持久化全景拆解:从 RDB 快照到 AOF 日志的底层博弈

Redis持久化机制深度解析:从内存快照到混合持久化 本文系统剖析Redis三大持久化方案(RDB、AOF、混合持久化)的底层原理与生产实践。RDB通过fork和写时复制(CoW)实现内存快照,牺牲实时性换取高性能;AOF以增量日志确保数据安全,支持always/everysec/no三种刷盘策略,并通过重写压缩文件。Redis 4.0+引入混合持久化,结合RDB的快速恢复与AOF的数据完整性,文件头部为RDB二进制数据,尾部为AOF增量日志。 关键优化点包括:避免fork大内存实例的页表复制延迟,关闭Li

2026-08-21 08:52:06 336

原创 Redisson 分布式锁看门狗机制:从 HashedWheelTimer 异步续期到 Lua 脚本原子校验

Redisson的看门狗机制是分布式锁自动续期的核心实现,通过后台Netty定时任务为持有锁的线程提供"心跳续命"功能。当未显式设置锁超时时间时,默认以30秒为基准,每隔10秒通过Lua脚本校验并延长锁有效期,既防止业务未完成锁提前释放,又避免服务宕机导致死锁。该机制基于Redis Hash结构存储锁信息,利用时间轮算法高效调度,在保障分布式锁安全性的同时,为性能优化提供了兜底方案,但需注意慢事务可能引发的线程饥饿问题。

2026-08-21 08:51:41 367

原创 Redis 缓存与 MySQL 一致性:延迟双删机制的工程痛点与架构演进

摘要: 延迟双删策略旨在解决高并发下缓存与数据库的一致性问题,但存在显著缺陷。其核心依赖严格的时间窗口控制(需大于主从同步、从库读取和缓存写入的总耗时),而实际生产中这些时间参数不可控,导致策略失效。问题包括:延时参数难以精确设定、同步阻塞降低吞吐量、二次删除可能失败、高并发下仍存在脏数据风险。替代方案推荐通过监听数据库Binlog异步删除缓存(如Canal/Debezium),或使用分布式读写锁(如Redisson)实现强一致性。前者解耦业务代码并支持重试,后者适用于金融等高要求场景,而延迟双删仅适合低流

2026-08-21 08:51:11 281

原创 Redis缓存和MySQL数据一致性方案详解

Redis与MySQL数据一致性解决方案 摘要 本文探讨了高并发系统中Redis缓存与MySQL数据库的数据一致性问题。首先分析了Cache-Aside模式下读写并发导致的数据不一致场景,包括"先删缓存再写库"和"先写库再删缓存"两种策略的缺陷。 文章介绍了两种过渡方案:延时双删策略和删除缓存重试机制,并指出了它们的局限性。随后提出企业级解决方案——"先更新DB再删缓存+Canal订阅Binlog异步兜底"架构,该方案通过Spring事务事件驱动确保数据库事务成功后删除缓存,并利用Canal监听Binlog

2026-08-20 18:27:57 473

原创 Redis底层视角拆解:缓存穿透/击穿/雪崩 高并发防御全指南

本地缓存挡热点,Redis 缓存挡 DB,DB 做兜底——通过"层层拦截"让请求在最快的地方被处理,同时用随机 TTL 和故障降级来抵御雪崩风险。这是一个典型的用空间换时间、用复杂度换性能的方案,适合读多写少的高并发场景。

2026-08-20 18:27:21 290

原创 深度解析 RocketMQ 消费端限流与重平衡(Rebalance):分布式队列分配与流控防雪崩本质

📝 摘要 RocketMQ消费端通过Rebalance和限流机制协同保障高可用与高吞吐。Rebalance采用去中心化设计,消费者通过心跳同步信息并本地计算队列分配方案,实现动态负载均衡;ProcessQueue作为核心数据结构,既是消息缓冲区又提供限流监控指标。消费端通过消息条数和内存大小双阈值实施主动流控,防止下游过载。二者共同作用时需注意:Rebalance可能导致消费停顿和重复消费,而频繁重平衡会影响性能。优化方向包括调整心跳参数减少抖动、顺序消息加锁保序,以及根据下游承载能力精细调优限流阈值。这

2026-08-20 08:41:34 409

原创 深度解析 RocketMQ 集群部署模式:传统多主多从与现代化 Controller 架构的演进本质

📌 RocketMQ集群架构演进剖析 摘要:本文深入解析RocketMQ从传统静态主从架构到Controller动态治理模式的演进本质。传统多主多从模式通过主从同步保障可靠性,但存在切换效率低的问题;而基于Raft协议的Controller架构实现了秒级故障自愈。文章对比了异步复制与同步双写的I/O开销差异,指出前者牺牲短期可靠性换取吞吐量,后者通过引入网络延迟保证强一致性的设计取舍。同时提出生产环境的优化建议:金融场景推荐"同步双写+Controller选主"组合,非核心链路可采用异步复制提升性能。架构

2026-08-20 08:40:29 339

原创 深度解析 RocketMQ 消费起点:ConsumeFromWhere 底层加载机制与失效陷阱

RocketMQ消费起点机制深度解析 RocketMQ的ConsumeFromWhere并非全局强制规则,而是消费者首次启动且无历史进度时的兜底策略。其核心依赖客户端OffsetStore与Broker元数据对齐: 生效边界:仅当OffsetStore查询无历史记录(Offset=-1)时触发,否则优先延续旧位点; 配置失效本质:消费组名不变导致历史Offset被复用,需通过更改GroupName或手动重置Offset强制生效; 生产风险:误用FIRST_OFFSET可能引发磁盘IO风暴,建议通过TIMES

2026-08-20 08:39:47 321

原创 深度解析 RocketMQ 死信队列(DLQ):消费重试的终点站、存储隔离与架构容灾本质

摘要:RocketMQ的死信队列(DLQ)是消费重试失败后的最终兜底机制,用于存储无法正常处理的“毒丸”消息。当消息重试次数(默认16次)耗尽后,系统将其转移至独立的%DLQ%队列,实现与主业务Topic的物理隔离。DLQ通过存储命名契约和消息属性(如ORIGIN_TOPIC)保留审计信息,避免污染主链路,同时需人工介入处理。其核心价值在于防止无限重试导致的线程阻塞,保障系统高可用,并通过监控告警提升运维效率。生产环境中需结合幂等性设计,确保安全重发与异常拦截。

2026-08-19 19:12:14 275

原创 深度解析 RocketMQ 传统主从复制:HAService 底层网络同步、位点对齐与架构权衡

本文深入解析了RocketMQ传统主从复制架构的核心机制。通过自研的HAService网络组件,Master与Slave建立TCP长连接实现CommitLog增量同步。文章详细拆解了同步复制(SYNC_MASTER)和异步复制(ASYNC_MASTER)的运作流程、Slave位点上报与字节流对齐机制,并揭示了传统架构在故障切换时的痛点。同时分析了网络批量传输优化和Page Cache隔离等性能设计,为不同业务场景提供了选型建议。最终指出该架构缺乏自动选主能力的局限性,为理解RocketMQ高可用机制提供了系

2026-08-19 19:11:39 267

原创 深度解析 RocketMQ 顺序消息:从核心原理、代码实战到分区有序的底层缺陷

本文深度解析了RocketMQ顺序消息的实现机制,重点探讨了分区有序的工程落地方案。文章从底层存储结构(CommitLog和ConsumeQueue)和物理模型出发,详细拆解了全局有序与分区有序的差异,指出全局有序的吞吐量缺陷。核心原理部分阐述了生产者路由策略(哈希取模)、Broker端队列加锁机制和消费端串行化处理的关键配合。通过完整代码示例展示了全局顺序消息和分区顺序消息的具体实现,包括生产者发送消息到固定队列和消费者注册顺序监听器的关键步骤。RocketMQ通过分区有序方案,在保证业务FIFO逻辑的同

2026-08-19 09:05:36 305

原创 RocketMQ 知识体系

本文系统梳理了Apache RocketMQ的核心知识体系,从五个维度展开: 核心概念与架构:包括消息模型(Topic/Queue/Tag/Key)、四大组件(NameServer/Broker/Producer/Consumer)及其交互机制。 存储设计:重点解析混合存储架构(CommitLog顺序写+ConsumeQueue索引)、刷盘策略(同步/异步)和主从复制机制(同步/异步双写)。 高级特性:详解事务消息(2PC+反查)、顺序消息(队列选择+消费锁)、延时消息(定时Topic)等特殊消息类型的实现

2026-08-19 09:05:03 660

原创 RocketMQ 内核进阶:CommitLog 物理存储引擎与 ConsumeFromWhere 寻址本质拆解

📝 摘要 RocketMQ采用创新的存储架构设计,其核心是: 统一物理日志:所有消息顺序写入全局CommitLog文件(1GB/文件),通过内存映射实现高效IO 二级索引机制:通过定长20字节的ConsumeQueue建立Topic到物理位置的索引映射 消费位点策略: ConsumeFromWhere决定初次启动时的消费起始位置 但持久化Offset优先级更高,导致策略修改常"失效" 仅在全新消费组或数据清理时作为兜底策略生效 该架构通过顺序写+内存映射实现高吞吐,定长索引保证高效检索,但需注意消费位点的

2026-08-19 09:03:58 338

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除