Staraven.-CSDN博客

原创 Hot100 42｜接雨水：如何确定每一格的水位？

给定柱子高度数组，接雨水问题的核心是计算每个位置能蓄水的总量。关键在于：某位置的水位由其左右两侧最高柱子中的较低者决定。通过预处理前缀最大值 $L[i]$ 与后缀最大值 $R[i]$，可得每格蓄水量为 $\min(L[i], R[i]) - \text{height}[i]$，总和即为答案。时间复杂度 $O(n)$，空间 $O(n)$。进一步优化可用双指针法，仅用 $O(1)$ 额外空间：维护左右最大值，每次根据短板方向结算并移动对应指针，确保每位置仅处理一次，高效求解总蓄水量。

2026-11-12 23:23:41 330

原创 Sentinel 哨兵机制：如何检测宕机并完成自动选主？

在 Redis 主从架构中，哨兵（Sentinel）集群实现高可用：通过心跳探测与多数派协商判定主节点客观下线，选举唯一执行者进行故障转移。新主基于优先级、复制偏移量和 Run ID 三级排序选出，确保数据一致性。哨兵不代理流量，仅提供主节点地址更新，客户端通过订阅或轮询感知切换。尽管可自动选主，但存在不可用窗口与网络分区下的脑裂风险，无法保证零停机与零数据丢失，需合理配置 down-after-milliseconds、quorum 及 min-replicas-to-write 等参数以平衡可用性与一致

2026-11-12 23:21:14 256

原创 Hot100 11｜盛最多水的容器：为什么每次都移动短板？

LeetCode 11题“盛最多水的容器”通过双指针法高效求解：初始化左右指针于数组两端，每次移动短板指针，确保不遗漏最大面积。核心思想是向内移动长板无法提升面积，从而实现 $O(n)$ 时间复杂度与 $O(1)$ 空间复杂度。该策略可推广至三数之和等题目，利用排序与单调收敛优化搜索。

2026-11-10 15:16:59 139

原创主从复制的工作原理：从全量同步到 repl_backlog 增量同步

Redis 主从复制在工程实现上通过三段机制完成了对吞吐、延迟与容灾成本的平衡：冷启动阶段通过 RDB 快照奠定静态全量基线，配合复制流缓冲区拉平快照生成期间的动态写入差额；正常传播期凭借异步 RESP 命令流与单调递增的字节偏移量换取极高吞吐；网络异常后则依靠共享的滑动历史窗口以极低代价完成自愈。这种设计将绝大多数偶发网络抖动的恢复代价，精准限制在了内存续传范围内。

2026-11-10 15:08:57 202

原创 Hot100 1｜两数之和：如何用哈希表省掉重复查找？

LeetCode 1. 两数之和可通过哈希表优化暴力枚举。核心思想：遍历时检查目标补数是否已出现，若存在则直接返回下标对。通过“先查后存”确保不自匹配、不漏解，且支持重复元素。时间复杂度降为 $O(n)$，空间复杂度 $O(n)$。该策略可推广至字母异位词分组（按排序字符生成规范键）与最长连续序列（仅从序列起点展开），均依赖哈希表实现高效查找与去重。

2026-11-08 15:49:20 503

原创键到期了为什么还占内存？Redis的过期删除与8种内存淘汰策略

Redis运维中常见反直觉现象源于过期删除与内存淘汰两大机制的分离。TTL仅标记逻辑失效，物理释放依赖惰性删除或主动过期扫描；而内存超限时，淘汰策略（如allkeys-lru）会优先驱逐冷键，即使其未到期。两者正交：过期不保证立即释放内存，淘汰也不受TTL约束。实际内存占用受抽样机制、策略配置及系统缓冲影响，maxmemory非操作系统RSS硬限，需结合used_memory与碎片率综合判断。

2026-11-08 15:03:50 517

原创大Key为什么会拖慢Redis？从排查到UNLINK异步回收

大Key因占用过多内存或成员数量，导致Redis主线程在执行遍历、删除等操作时产生阻塞，引发服务延迟。其影响核心在于单线程模型下命令串行执行，全量操作会独占主线程。DEL同步释放内存易造成卡顿，而UNLINK通过两阶段机制——先快速解绑键，再评估工作量决定是否异步释放——有效缓解阻塞。生产中应结合--bigkeys、SCAN与MEMORY USAGE低开销排查，避免直接全量读取，并合理使用UNLINK与惰性释放机制，以保障高可用与低延迟。

2026-11-07 19:58:35 362

原创 Redis 生成 RDB 快照时，写时复制如何让主进程继续处理请求？

内存数据库持久化面临主线程高并发与后台落盘的冲突。Redis 采用 BGSAVE + 写时复制（COW）机制：通过 fork() 创建子进程，父子进程共享物理页，仅在写操作时触发按页复制，确保快照具有时点一致性。子进程写入临时文件后原子替换原 RDB，避免数据损坏。虽不强制内存翻倍，但高写负载下仍可能显著增加内存开销，并引发 fork() 停顿与 I/O 竞争。生产环境需配置 overcommit_memory=1 并监控内存、I/O 及快照耗时，合理权衡性能与可靠性。

2026-11-07 19:52:33 382

原创分库分表到底解决什么问题？从分片键到跨分片查询

分库分表是突破单机数据库瓶颈的架构妥协，但其成效取决于对底层瓶颈的准确识别与合理设计。单表性能衰减主因非行数，而是内存、I/O与连接数等物理资源耗尽。垂直/水平拆分各有边界，原生分区不支持跨机扩展。分片键选择决定路由效率：哈希分片易致数据倾斜，范围分片引发写入热点。查询需避免广播扇出，可通过基因法、映射表或双写解决。跨片操作如分页、JOIN与事务带来显著开销，应优先收敛事务边界，采用游标分页与最终一致性方案。分布式ID需嵌入分片信息以支持精准路由，扩容须平滑迁移，避免取模基数变更导致数据错位。

2026-11-06 23:53:46 307

原创 Redis 的 AOF 日志为什么先执行再记录？重写时又发生了什么？

Redis 采用写后日志（AOF）机制，先执行内存修改再记录日志，以保障低延迟。其核心在于主线程优先完成命令执行，随后通过 write() 写入内核页缓存，并由 appendfsync 策略控制物理落盘：always（强同步）、everysec（后台异步，最长丢失1秒）、no（交由操作系统回写）。为应对日志膨胀，Redis 引入后台重写机制，通过读取内存快照生成精简日志。自 Redis 7.0 起采用 Multi-Part AOF 架构，分离底座（BASE）与增量（INCR）文件，结合 Manifest 文

2026-11-03 12:36:43 267

原创为什么 ZSet 选用跳表，而不是红黑树或 B+ 树？

Redis 有序集合（ZSet）通过跳表与哈希字典的复合结构，高效支撑排行榜三大核心操作：点查（ZSCORE）、范围查询（ZRANGEBYSCORE）与排名（ZRANK）。跳表以分层链表实现 $O(\log N)$ 的平均查找与 $O(\log N + M)$ 的范围扫描，结合 span 字段累加实现 $O(\log N)$ 排名计算；字典则保障 $O(1)$ 成员定位。相较红黑树与 B+ 树，跳表无需旋转或分裂，工程实现更简洁，内存开销可控。小集合时采用紧凑的 ListPack 编码，进一步优化内存效率。

2026-11-03 12:20:08 647

原创哈希表扩容，Redis 为什么不用停下来搬家？

Redis 采用渐进式哈希扩容机制，解决单线程下一次性搬迁导致的阻塞问题。通过双表共存与迁移游标 rehashidx，将节点搬迁分摊至读写操作中，实现平滑扩容。新增数据直接写入新表，查询按“旧表→新表”两段探测，删除与更新亦遵循此路由逻辑。结合被动推进（操作顺带）与主动定时任务（serverCron），确保搬迁持续进行。尽管有效避免了长时间延迟，但内存分配、链表过长及双重驻留仍可能引发瞬时性能波动，体现了工程权衡下的理性设计。

2026-11-01 23:37:32 331

原创插入一个元素，为什么后面都要改？详解 ZipList 与 ListPack

Redis 从 ZipList 到 ListPack 的演进，核心在于解决紧凑存储中的“连锁更新”问题。ZipList 因 prevlen 依赖前驱长度，插入导致后续节点级联扩容，最坏时间复杂度达 $O(N^2)$，引发高延迟。ListPack 通过引入自描述的 backlen，使每个节点独立记录自身长度，彻底解耦相邻节点，避免内存重分配与字节搬移，既保持连续内存的高压缩比，又实现稳定高效的双向遍历，是内存优化与性能保障的平衡之选。

2026-10-31 22:53:35 302

原创 Redis 为什么不用 C 字符串？从长度、扩容到二进制安全拆解 SDS

Redis 为克服原生 C 字符串的长度未知、容量不可控、重分配复杂等缺陷，自研了高效安全的动态字符串（SDS）。SDS 通过紧凑结构体（如 sdshdr8）在字符数据前嵌入长度与容量元信息，实现 $O(1)$ 长度查询与快速扩容。其指针直接指向数据首部，兼容标准 C 库函数；采用空间预分配策略（小量翻倍，大量增量），减少频繁内存分配。追加操作中，先检查剩余容量，足够则直接写入，不足才按规则扩容，兼顾性能与安全性，是 Redis 高并发场景下的核心设计之一。

2026-10-31 22:38:55 866

原创存一个数字也要对象头？拆解 redisObject 的 16 字节开销

Redis 存储数字 1 时，看似仅需 1 字节，实则因 redisObject 对象头占用 16 字节。该结构包含类型（4位）、编码（4位）、LRU时间戳（24位）和引用计数（4字节），共 16 字节。其中 ptr 指针在整数编码下直接内联存储数值，避免额外内存分配。类型与编码分离设计实现多态调度与内存弹性，如字符串支持 int、embstr、raw 三种编码，小数据用紧凑结构，大时自动升级为高效结构。共享整数池虽优化性能，但在启用 LRU/LFU 淘汰策略时会被跳过，以保证淘汰准确性。

2026-10-29 23:59:28 276

原创 Redis 6.0 引入多线程后，为什么命令执行依然是单线程？

Redis 6.0 的多线程 I/O 并非全链路并发，而是仅将网络读写与协议解析分摊至工作线程，核心命令执行、数据结构操作及响应生成仍由单主线程串行完成。其设计旨在缓解高并发下套接字系统调用与协议解析的瓶颈，而非提升命令计算吞吐。多线程仅在读写阶段并行，且需满足负载条件；慢查询、复杂计算与脚本仍会阻塞主线程。该架构平衡了性能与一致性，避免了共享内存并发带来的复杂性，是针对内存数据库场景的高效工程选择。

2026-10-29 23:55:39 307

原创单线程的 Redis 凭什么这么快？详解 epoll 与事件循环

Redis虽为单线程架构，却能支撑高并发，核心在于其事件驱动模型与I/O多路复用机制。主线程通过epoll监控所有客户端连接，仅在有数据就绪时被唤醒，避免阻塞与轮询开销。网络读写、命令解析及数据操作由单一主线程串行处理，而大内存释放、AOF刷盘等耗时操作交由后台线程异步执行。多线程I/O（Redis 6.0+）仅用于网络数据传输，命令执行仍保持单线程。epoll以红黑树管理监听集合、双向链表高效传递就绪事件，实现“低延迟、高吞吐”的底层调度，使单线程也能驾驭数万并发连接。

2026-10-27 20:15:58 572

原创秒杀系统设计：Redis 预扣库存、一人一单与 Stream 异步下单

本文基于Redis 7.x与MySQL 8.0，设计高并发秒杀系统，通过Redis预扣准入配额、Lua脚本保证原子性校验、Stream消费组实现异步落库，解决库存超卖与状态不一致问题。核心在于区分Redis“准入配额”与数据库“权威库存”，利用同槽键与单线程脚本确保原子性，结合消息队列与事务机制实现最终一致性，兼顾性能与可靠性。

2026-10-26 22:53:59 241

原创从 SETNX 到 Redisson 看门狗：分布式锁的实现与演进

多个应用服务器因本地锁无法跨进程同步，导致并发修改问题。需使用外部锁如Redis实现分布式锁，通过SET key value NX PX原子设置锁并设定租约。释放时必须校验令牌防止误删他人锁，避免竞态。租约过期后业务线程仍可能执行，需结合看门狗机制自动续期。Redisson通过Hash结构记录持有者与重入计数，看门狗周期性续期，确保锁在任务完成前不失效，保障分布式环境下资源访问的互斥性与安全性。

2026-10-24 23:53:45 319

原创先更新数据库还是先删缓存？详解缓存双写一致性

商品价格更新后，缓存未及时同步导致读取旧值。尽管数据库已提交新数据，但因缓存删除时机不当或写入延迟，仍可能回填旧值。即使采用“先提交后删缓存”策略，若读请求在数据库提交前已获取旧数据，仍会将旧值写回缓存。此外，网络延迟、长事务、读副本延迟等均加剧此问题。仅靠单次删除无法保证一致性，需结合版本控制、原子性写入及可靠重试机制，确保缓存与数据库最终一致。

2026-10-23 23:45:05 385

原创 SingleFlight 实战：在 JVM 进程内合并热点并发查询

在高并发场景下，单一请求的缓存击穿问题可通过 SingleFlight 模式优化。通过 ConcurrentHashMap 与 CompletableFuture 实现进程内请求合并：首个线程执行查库逻辑，后续同 Key 请求共享结果，避免重复查询。核心优势在于降低 Redis、数据库压力，提升系统吞吐。需规避三大陷阱：禁用 computeIfAbsent 中的 I/O 操作、确保异常时完成未来任务、添加超时机制防止慢查询连坐。代码简洁高效，是应对热点数据并发访问的利器。

2026-10-22 20:08:40 577

原创如何应对缓存穿透、缓存击穿与缓存雪崩？

在高并发读写分离架构中，Redis 缓存失效可能引发缓存穿透、击穿与雪崩，导致数据库瞬间瘫痪。针对缓存穿透，可通过参数校验与空值缓存拦截非法请求，结合布隆过滤器实现高效前置过滤；针对缓存击穿，可采用分布式互斥锁或逻辑过期策略，确保热点数据重建时仅单线程回源，避免瞬时流量冲击。合理设计缓存治理方案，是保障系统稳定的核心。

2026-10-21 22:25:14 294

原创从打卡签到到附近的人：Redis 三大高级数据结构的业务选型与边界

系统初期用常规数据结构可快速实现功能，但用户量达数百万后，内存与性能瓶颈凸显。Redis 通过 Bitmap、HyperLogLog 和 GEO 三大特性高效应对：Bitmap 利用位运算将签到记录压缩至极低内存，适合稠密整数偏移；HyperLogLog 以固定 12KB 内存估算海量独立访客，误差可控；GEO 基于 ZSet 与 GeoHash 编码，实现高效附近搜索。三者均基于底层结构巧妙设计，兼顾性能与空间效率，是高并发场景下统计与查询的利器。

2026-10-18 21:08:14 181

原创 String、Hash、List、Set、ZSet：五大基础数据类型的业务选型

本文剖析了Redis在实际项目中被误用为“JSON堆放场”的常见问题，指出整包序列化存储导致的性能瓶颈与并发覆盖风险。通过对比String、Hash、List、Set、ZSet五种数据类型，强调应根据读写粒度、并发需求、是否需排序去重等场景合理选型：如用Hash实现字段级更新避免全量读写，用ZSet构建实时排行榜，用Set做集合运算与去重，用List实现阻塞队列，避免大Key与高耗时操作。核心建议是：数据建模应贴近业务访问模式，善用原生数据结构，而非简单序列化堆砌。

2026-10-18 19:44:47 274

原创 MySQL 已经有 Buffer Pool 了，为什么系统还需要引入 Redis？

尽管内存数据库如Redis在延迟和并发性能上远超传统关系型数据库，但其无法完全替代MySQL。核心原因在于：架构目标本质不同——MySQL面向磁盘设计，强调数据持久性与事务一致性；而Redis基于纯内存，追求极致低延迟与高吞吐。即使将MySQL全量数据放入内存，其仍需承担SQL解析、锁竞争、脏页刷盘等开销，难以突破多线程瓶颈。相比之下，Redis通过单线程事件循环、无锁内存寻址与原生数据结构，在秒级响应与万级QPS上具备压倒性优势。然而，受限于内存成本、容量天花板及持久化可靠性，两者应协同使用：热数据走Re

2026-10-16 23:03:43 362

原创 Java 转 Python 后端 04: GIL 机制、单线程事件循环与异步并发实战

本章系统解析Python并发机制，核心聚焦GIL对多线程的限制及异步编程在Agent后端的必要性。针对I/O密集型场景，推荐使用asyncio协程实现万级并发；CPU密集型任务则需采用多进程突破GIL瓶颈。通过对比Java的CompletableFuture，阐明async/await的调度机制与并发模式差异，强调避免同步阻塞操作。重点实战异步生成器与SSE流式传输，实现大模型输出的实时推送，构建高效、低延迟的Agent服务架构。

2026-10-16 23:02:36 320

原创 Java 转 Python 后端 03: 函数一等公民、三层装饰器与流式生成器

本章阐述Python函数的一等公民特性：函数可赋值、传参、存入容器，支持lambda与Callable类型标注。装饰器作为直接执行的函数包装，实现无框架的AOP（如计时、重试），结合@functools.wraps保持元信息。闭包需用nonlocal声明外部变量，避免UnboundLocalError。上下文管理器with实现资源自动管理，通过__enter__/__exit__或@contextmanager定义。生成器则提供内存高效的惰性求值，支持yield实现迭代逻辑，是构建异步与流式处理的基础。

2026-10-13 14:21:24 64

原创 Java 转 Python 后端 02: 面向对象到与数据建模体系

本章系统介绍Python面向对象与数据建模核心机制：类定义灵活无需预声明属性；通过下划线约定实现访问控制，无真正private；使用@property替代getter/setter，保持语法简洁；继承与多态依赖鸭子类型、Protocol或ABC实现；dataclass简化样板代码，但需注意可变默认值陷阱；现代泛型语法（如list[str]）结合pyright实现静态类型检查；核心工具Pydantic在运行时验证数据，是Agent开发中不可或缺的动态校验层。

2026-10-13 10:34:06 121

原创 Java 转 Python 后端 01: 现代工程底座与核心语法避坑

本文系统对比了Java与Python在类型系统、语法结构、项目管理、依赖治理及代码规范等方面的本质差异。核心要点包括：Python采用动态类型+可选类型注解，运行时无校验；一切皆对象，无需new，缩进定义代码块；项目结构以pyproject.toml为核心，依赖通过uv工具管理，强制使用虚拟环境隔离；模块导入基于文件系统路径，需注意sys.path陷阱，推荐使用-m模式启动；统一使用ruff实现Lint与格式化，替代Java生态中的多个工具。

2026-10-12 23:04:28 971

原创【MySQL入门】11：掉电如何保证数据不丢？深入拆解 redo log、binlog 与两阶段提交

为保障断电不丢数据，MySQL 采用 WAL 机制与两阶段提交（2PC）。InnoDB 通过 redo log 实现崩溃恢复：事务提交前先写入顺序日志，确保持久性；日志环形存储，由 write_pos 与 checkpoint 双游标管理空间。同时，binlog 作为逻辑日志，用于主从复制与时间点恢复。两者独立存在易导致主从不一致。因此引入 2PC：先写 redo log 并 prepare，再写 binlog，最后提交 redo log。宕机后根据日志状态判断：若 prepare 且 binlog 存在，

2026-10-11 16:18:12 493

原创【MySQL 入门】10：全表扫描为什么没挤垮内存？深入拆解 MySQL Buffer Pool 架构与 LRU 冷热分区

本文深入剖析 InnoDB Buffer Pool 的内存管理与置换策略。首先介绍 Buffer Pool 的物理内存划分（控制块、数据页、哈希索引表）与 Free、LRU、Flush 三大链表的运行职责；随后指出朴素 LRU 在预读失效与全表扫描场景下会被击穿的问题，并详细讲解 InnoDB 的解法——LRU 冷热分区（Young/Old 区）与 innodb_old_blocks_time 时间窗口屏障，以及 Young 区内部的前 1/4 免移防抖动机制。写路径上，文章阐述了 Change Bu

2026-10-11 15:41:26 505

原创【MySQL入门】09：MySQL 锁全景、加锁退化与死锁排查

MySQL 锁按粒度分为全局锁、表级锁（含MDL、意向锁）与行级锁。全局锁（FTWRL）曾用于备份，现可通过--single-transaction结合MVCC实现无锁一致性备份。MDL保障表结构与数据并发安全，但长事务易引发写锁优先的级联阻塞，需通过监控、超时或在线工具规避。意向锁（IS/IX）降低表级锁检测复杂度，提升性能。行级锁挂载于索引上，无索引更新会导致全表临键锁扩散，等同整表锁定；在RR隔离级别下，临键锁可退化为记录锁或间隙锁以平衡并发与幻读防护。间隙锁虽防幻读，但并发插入可能引发死锁，本质为等

2026-10-10 19:02:56 334

原创【MySQL 入门】08: 读不加锁如何保证一致性？深入拆解 MySQL MVCC 机制与 ReadView 底层判定

本文深入解析InnoDB的MVCC机制，揭示其如何通过隐藏列（DB_TRX_ID、DB_ROLL_PTR）与Undo Log构建版本链，实现读写并发不互斥。快照读依赖ReadView进行可见性判定，核心逻辑基于事务ID与活跃事务列表的四步比对。RC与RR隔离级别的差异在于ReadView创建时机：RC每次查询重建，导致不可重复读；RR仅首次创建，保障可重复读。二级索引通过PAGE_MAX_TRX_ID实现页级快速可见性判断，减少回表开销。尽管RR能避免幻读的常见场景，但间隙锁缺失仍可能导致幻读，故并非彻底消

2026-10-10 19:02:26 424

空空如也

空空如也