小红的布丁-优快云博客

原创 IP、子网、私有地址、ARP 与 Ping 通信全过程

判断是本地直发还是交给网关通过 ARP 找到这一跳对应的 MAC 地址把这两个问题搞清楚，后面再看 TCP 建连、HTTP 请求，就不会觉得数据是在“凭空飞过去”。如果这篇文章对你有帮助，欢迎继续阅读本系列后续内容。若文中有不准确或需要补充的地方，也欢迎指出。

2026-05-09 11:36:28 986

原创 TCP 核心原理：三次握手、四次挥手、粘包拆包、TCP 与 UDP 区别

最常见的做法是消息由“消息头 + 消息体”组成，消息头里写明消息体长度。接收方先读长度，再按长度读取完整消息。这是工程上最稳妥、最常见的做法。通过三次握手建立可靠连接通过序列号和确认机制保证可靠传输通过四次挥手关闭双向连接只提供字节流，不负责应用层消息边界如果你能把这些点讲清楚，TCP 这部分基础就已经比较扎实了。如果这篇文章对你有帮助，欢迎继续阅读本系列后续内容。若文中有不准确或需要补充的地方，也欢迎指出。

2026-05-09 11:36:20 1474 1

原创公网 IP、私网 IP、路由表、转发表与 MAC 地址的关系

公网 IP 是可以在互联网范围内参与路由的地址。通常一个家庭宽带、一个企业出口、一个云服务器，都会有一个或多个公网 IP。从互联网的视角看，真正能被外部网络直接识别和访问的，通常是这个公网 IP。私网 IP 是保留给局域网内部使用的地址，不能直接在公网中路由。10.0.0.0/8到这类地址更准确地叫“私网 IP”，不是“虚拟 IP”“在链路上”表示目标是直连可达的，不需要经过下一跳网关路由表负责选路，转发表负责高速转发MAC 地址属于数据链路层，IP 地址属于网络层。

2026-05-08 15:03:07 6389 5

原创从浏览器输入 URL 到页面返回：一次互联网通信全过程

把整个过程压缩成一句话就是：“先解析域名，再建立 TCP 连接，然后发送 HTTP 请求，服务器返回响应，浏览器解析资源并渲染页面，最后按需复用或关闭连接。DNS 解析TCP 三次握手HTTP 请求与响应路由转发与网关TCP 四次挥手这也是理解整个互联网通信过程最好的入口。如果这篇文章对你有帮助，欢迎继续阅读本系列后续内容。若文中有不准确或需要补充的地方，也欢迎指出。

2026-05-08 15:03:01 1518

原创操作系统与高性能 IO：零拷贝、一次读 IO、CPU 缓存与伪共享

CPU 缓存不是按“一个变量”来管理的，而是按“缓存行”来管理的。缓存行通常是 64 字节，它是缓存系统中最小的管理单位和失效单位。CPU 读取一个变量时，往往会把它周围相邻的一块数据一起读入缓存所以连续内存访问通常更高效，因为它更容易命中缓存行。伪共享是并发编程里一个很常见但不容易一眼看出来的性能问题。线程 A 修改变量x线程 B 修改变量yx和y虽然是两个不同变量，但它们刚好落在同一个缓存行里一个线程修改其中一个变量时，会导致另一个 CPU 核心上对应缓存行失效。

2026-05-07 09:40:01 1279

原创 Redisson 分布式锁实现：可重入与看门狗

在分布式架构中，多台服务器共享同一资源时，传统的 JVM 锁已无法保障数据一致性，分布式锁由此成为关键。Redisson 基于 Redis 实现的分布式锁，不仅支持可重入、自动续期，还通过发布订阅机制高效处理锁竞争。本文从加锁、锁续命、锁释放三个环节，深入解析 Redisson 的核心设计，包括 Lua 脚本保证原子性、Watch Dog 看门狗的定时续期机制，以及如何灵活控制锁的失效策略。

2026-05-07 09:39:48 949

原创单线程 Redis 的高性能之道

Redis 以单线程模型处理网络请求与命令操作，却能在高并发场景下保持惊人的吞吐能力。（哈希表、跳表等）以及，让单线程能够高效处理海量连接。随着 Redis 6.0 引入多线程 IO，网络读写被拆分给多个线程并行处理，进一步突破了网络瓶颈；而命令执行依然坚守单线程，避免了复杂并发控制，确保 Lua 脚本和事务的原子性。本文将从单线程的设计精髓，到主线程与 IO 线程的协作流程，深入浅出地解析 Redis 为何“又快又稳”。

2026-05-06 10:31:46 1116 2

原创雪花算法：高并发场景下的分布式唯一ID生成方案解析

雪花算法将64位整数划分为时间戳（41位）、机器ID（10位）和序列号（12位），结合高位位移运算实现毫秒级ID生成，单机每秒可承载超400万次请求。其核心逻辑通过时间有序性确保ID单调递增，同时借助机器ID的分段设计支持横向扩展。然而，时钟回拨问题可能威胁算法的可靠性，为此衍生了多种容错策略，例如短暂等待、备份机器切换及容错序列复用等，兼顾了灵活性与鲁棒性。

2026-05-06 10:31:14 1052

原创 Redis 内存淘汰与过期策略

Redis 作为内存数据库，内存资源有限，必须妥善处理内存占用问题。决定内存达到上限时如何移除数据，涵盖 noeviction、LRU、LFU 等多种算法及其实现细节；（惰性删除 + 定期删除）负责及时清理已过期的键，并说明如何避免读到过期数据。掌握这些机制，有助于合理配置 Redis 实例，平衡内存效率与数据可用性。

2026-04-28 09:34:30 996

原创 Reactor 模型详解：单 Reactor、主从 Reactor 与 Netty 思想

谁负责接收连接谁负责监听读写事件谁负责真正业务处理从单 Reactor 到主从 Reactor，本质上就是不断把职责拆开，让系统更适合高并发场景。如果你在学习 Netty，这篇内容一定要和前面的epoll、NIO 一起理解。只有把这三者连起来，才算真正看懂高性能网络服务的底层设计。如果这篇文章对你有帮助，欢迎继续阅读本系列后续内容。若文中有不准确或需要补充的地方，也欢迎指出。

2026-04-27 09:42:28 724

原创 BIO、NIO、AIO 与 IO 多路复用：select、poll、epoll 详解

IO 多路复用的目标是：“让一个线程同时监听多个文件描述符，当其中某些就绪时再处理。selectpollepoll它们本质上都在做同一件事：帮助应用进程找到“哪些连接现在可以读写”。BIO：一个线程盯一个连接，简单但浪费NIO：线程不阻塞，可以管理多个连接IO 多路复用：帮助线程高效发现哪些连接就绪epoll：Linux 高并发场景下最常见的选择AIO：由系统在完成后主动通知，更偏异步如果你后面准备继续学 Netty、Reactor 模型，这一篇就是基础前置。

2026-04-27 09:42:17 934

原创 Redis 集群详解：主从哨兵和切片集群有什么区别

Redis 集群常见有两种方式：主从哨兵和切片集群主从哨兵主要解决高可用问题，切片集群主要解决水平扩展问题Redis Cluster 使用 16384 个哈希槽实现 key 到实例的映射key 先通过 CRC16 计算，再对 16384 取模，确定所属槽客户端通过缓存槽位映射关系来定位数据MOVED表示槽已经正式迁移完成，客户端需要更新缓存ASK表示槽仍在迁移中，只做一次临时重定向理解 Redis 集群，关键不是只记住“有哨兵”和“有哈希槽”，而是要看清它们分别解决的是哪一类问题。

2026-04-27 09:42:10 800 2

原创计算机网络入门：OSI 五层模型、各层协议和数据单位

五层模型是整个计算机网络的地图。后面学习 ARP、IP、TCP、HTTP 时，看起来像是分散的知识点，其实都在这张地图上有明确位置。IP、子网、MAC、ARPPing 与路由转发TCP 三次握手和四次挥手HTTP 与 HTTPS只要顺着这个脉络走，网络知识会越学越顺。如果这篇文章对你有帮助，欢迎继续阅读本系列后续内容。若文中有不准确或需要补充的地方，也欢迎指出。

2026-04-24 10:09:20 1417 2

原创 Redis 持久化详解：AOF、RDB 与混合持久化如何平衡性能和可靠性

AOF 的全称是 Append Only File。把 Redis 收到的写命令，以追加的方式记录到日志文件中当 Redis 重启恢复时，就可以重新执行这些命令，从而恢复数据。某一时刻 Redis 的全量数据快照RDB 文件是二进制格式，因此恢复时可以直接把快照内容读入内存，而不需要逐条重放命令。RDB 恢复速度通常比 AOF 更快以 RDB 快照作为基础在两次快照之间，用 AOF 记录增量命令定期做一次内存快照快照之后的写操作，再通过 AOF 记录不需要频繁执行全量快照，减少fork。

2026-04-08 15:02:30 796

原创 Redis 哨兵机制详解：哨兵如何发现彼此、判断故障并完成主从切换

你们是否也认为这个主库不可用了客观下线（Objectively Down，简称odown这个判断通常要求达到配置的法定票数，也就是常说的 quorum。需要达到 Sentinel 配置中的法定票数要求只有当主库被判定为客观下线后，后续的故障转移流程才会真正开始。哨兵之间通过主库上的频道互相发现单个哨兵只能判断主观下线，多个哨兵达成共识后才会形成客观下线主库被判定客观下线后，哨兵集群会选出一个 Leader 负责故障转移新主库的选择遵循“筛选 + 打分”的规则，而不是随机挑选。

2026-04-08 15:01:46 726

原创 MySQL 和 Redis 数据一致性，以及 Redis 与 ZooKeeper 分布式锁对比

MySQL 和 Redis 一致性问题，重点在更新和删除场景更常见的实践是“先更新 MySQL，再删除 Redis”删除缓存失败时，MQ 重试通常是更实用的补偿方案Redis 锁性能更好，但在故障场景下的一致性和可靠性要谨慎评估ZooKeeper 锁性能较弱，但自动释放和强一致性更适合高可靠场景RedLock 可以增强 Redis 锁的可靠性，但不等于所有问题都能完全消失真正落地时，不要只看技术名词，而要结合业务对性能、一致性、可恢复性的要求做权衡。

2026-04-08 13:42:33 1009

原创 Redis存储引擎剖析：从哈希表到智能数据结构

在Redis高效表现的背后，是一套精密的存储引擎设计。全局哈希表作为数据的"总目录"，通过指针灵活指向各种RedisObject，实现了统一的快速访问。更巧妙的是，Redis会根据数据特征智能选择最优存储结构：Set：在纯整数场景下采用紧凑的整数数组，复杂场景切换到哈希表。SDS字符串：通过5种精确定制的头部类型，实现极致的内存效率。Zset/List/Hash：在小数据量时使用内存友好的压缩列表，大数据量时自动切换至性能更优的跳表或哈希表。

2025-11-14 13:16:15 1061

原创 ShardingSphere解析：分布式数据库中间件的分片设计与事务管理实践

ShardingSphere以“可插拔架构”为核心设计理念，提供Sharding-JDBC（嵌入式SDK）与Sharding-Proxy（独立数据库代理）两种接入形态，兼顾高性能与多语言兼容性。其标准分片、行表达式、复合分片及Hint强制路由等策略，支持从简单取模分片到多字段联合分片的复杂场景。针对分布式事务难题，ShardingSphere整合XA强一致性事务与Seata AT柔性事务模型，覆盖金融级一致性需求与高吞吐量业务场景。

2025-06-12 16:04:10 1335

原创 Zab协议剖析：崩溃恢复与顺序原子广播

该协议将集群状态划分为领导选举（Leader Election）与提案同步（Proposal Sync）两大核心阶段：选举阶段通过Zxid（全局事务ID）的纪元（Epoch）递增机制，确保新主节点始终携带最新数据视图；同步阶段则利用类两阶段提交（2PC）的原子广播流程，将事务请求以严格递增的Zxid顺序固化到多数节点。其独创的事务提案淘汰规则（如旧Leader重启后自动清除未提交提案）与观察者（Observer）角色的引入，既解决了网络分区导致的数据分歧问题，又通过读写分离架构提升了系统的横向扩展能力。

2025-06-11 11:20:09 693

原创 Raft协议解析：领导者选举与日志复制

该协议将系统节点明确分为领导者（Leader）、跟随者（Follower）和候选者（Candidate）三类角色，通过心跳驱动选举和日志强制同步两大核心机制，既规避了传统算法Paxos的复杂性，又保证了网络分区或节点故障时的快速恢复能力。其任期递增（Term）规则与多数派承诺（Quorum）策略，确保了集群在领导者宕机时能通过严格的选举超时竞争机制快速切换新主节点，而日志连续性校验与状态机复制规则则为跨节点数据一致性提供了数学证明级别的可靠性支撑。

2025-06-11 11:06:50 1312

原创 Paxos协议详解：分布式系统如何通过多数派协商达成数据一致

该协议将节点划分为提案者（Proposer）、接受者（Acceptor）和学习者（Learner）三重角色：提案者通过全局递增提案编号（ProposalID）发起价值提议，接受者依据承诺不退化原则（仅接受更高编号提案）过滤冲突请求，最终在多数派节点间形成确定性决议。其Prepare-Accept双阶段提交机制，既通过最大提案继承策略规避了脑裂风险，又依赖活锁规避设计（提案编号指数退避）解决了多提案者持续竞争的收敛难题。

2025-06-09 15:42:15 1447

原创解析两阶段提交与三阶段提交的核心差异及MySQL实现方案

经典的两阶段提交协议（2PC）通过准备阶段与提交阶段的协调机制，以同步决策模式确保事务原子性。其改进版本三阶段提交协议（3PC）通过增加预提交阶段和超时机制，旨在解决2PC的阻塞风险。值得注意的是，MySQL数据库的Binlog与InnoDB引擎通过内部两阶段提交机制，实现了事务日志与存储引擎状态的一致性保障。

2025-06-09 15:36:10 843

原创 Dubbo高频面试题

本文系统梳理Dubbo高频面试核心知识点，涵盖容错策略、负载均衡、注册中心原理、服务上下线感知等关键技术细节，助您深入理解Dubbo设计思想，从容应对分布式服务架构面试挑战。无论是服务注册发现流程，还是ZooKeeper节点监听机制，这里提供清晰的技术脉络与场景化解析。

2025-05-29 10:40:43 936

原创 MyBatis 一二级缓存深度解析：原理、应用与脏读问题

级缓存基于 SqlSession 的生命周期，默认开启但存在跨会话脏读风险；二级缓存虽能实现跨会话数据共享，却需谨慎处理连表查询、集群部署等场景下的缓存同步难题。

2025-05-29 10:12:39 1542

原创单例模式的隐秘危机

许多开发者误以为“私有构造函数”足以保障其唯一性，却忽视了反射机制、对象克隆、序列化反序列化这三把“隐形利刃”——它们能绕过常规防御，悄无声息地创建多个实例，引发数据污染、资源竞争等灾难性后果。

2025-05-28 10:05:23 868

原创 Elasticsearch父子关系解析

传统关系型数据库通过外键实现的多表关联，在分布式搜索场景下面临性能与扩展性挑战。Elasticsearch通过父子关系（Parent-Child Relationship）提供了一种高效的文档级联方案，支持灵活的多层数据建模与跨文档查询。

2025-05-28 10:01:13 758

原创 Elasticsearch搜索机制与分页优化策略

两阶段查询：协调节点通过Query阶段并行筛选分片结果（基于文档ID与排序值），再经Fetch阶段精准拉取全量数据；混合索引加速：BKD树（数值/日期字段）实现高效范围查询（O(log N)），倒排索引（字符串字段）支持快速关键词匹配；海量数据分页：突破max_result_window默认限制需权衡内存开销，而Scroll API（批量拉取）与Search After（动态分页）分别适用于离线分析与实时场景。

2025-05-27 13:26:53 1382

原创 Elasticsearch索引机制与Lucene段合并策略深度解析

文档生命周期管理：从客户端请求路由到分片定位，从内存缓冲区（Buffer）到事务日志（Translog）的双重写入机制，揭示数据持久化的完整路径；实时性与可靠性平衡：通过剖析Translog同步/异步刷盘策略、内存缓冲区刷新（Refresh）与持久化刷盘（Flush）的触发逻辑，解读搜索可见性与故障恢复的底层保障；Lucene段合并优化：深入对比分层合并（TieredMergePolicy）、字节大小合并（LogByteSizeMergePolicy）和文档数量合并（LogDocMergePolicy）

2025-05-27 13:19:12 1623

空空如也

空空如也