- 博客(137)
- 收藏
- 关注
RSS订阅原创 Maven 打包惨遭 surefire-plugin 报错？恭喜，这是离成功最近的一次失败
摘要： Maven打包时遇到surefire-plugin测试失败报错，实际上是编译成功的信号。这类错误通常由严格的单元测试或环境依赖导致，而非代码问题。文章提供两种快速解决方案：1) 命令行执行mvn clean package -Dmaven.test.skip=true跳过测试；2) IDEA中启用"Skip Tests"模式。解释了skipTests与maven.test.skip的区别，后者完全跳过测试编译更高效。最终成功打包后，即可通过java -jar运行项目。这是开发者快
2026-01-10 08:45:00
871
原创 避坑指南：Maven 编译前端报错 404？彻底搞懂 frontend-maven-plugin 的镜像配置与运行机制
摘要： 在Java全栈开发中，frontend-maven-plugin插件常用于统一前后端构建流程，但常因404下载错误导致构建失败。本文提供一键解决方案（配置华为云镜像），并深入解析插件机制：Maven全局镜像仅管理Java依赖，而该插件需独立下载Node.js和Yarn二进制文件，绕过Maven镜像配置。插件采用两级存储策略，先缓存到本地Maven仓库，再解压到项目target目录运行。针对极端网络环境，还提供手动离线模式操作指南。
2026-01-09 19:45:00
1186
原创 Maven 版本迷思：本地装了 JDK 21，POM 里写 Java 8 会冲突吗？
摘要：Maven项目中配置高版本JDK（如JDK 21）编译低版本目标（如Java 8）不会冲突。pom.xml中的maven.compiler.source和target指定语法检查和生成兼容的字节码版本，而settings.xml配置的JDK版本仅决定使用的编译工具。这种"高版本编译低版本"的做法是推荐的标准实践，既能利用新版编译器的性能优化，又能确保产出的jar包兼容旧环境。核心原理是JDK的向下兼容性，类似"用现代工具按古法制作仿古家具"。
2026-01-09 08:45:00
482
原创 深入源码：Jedis 线程不安全的本质与连接池的“隔离术”
Jedis线程不安全根源在于其BIO模型的有状态连接设计，每个实例对应一个TCP连接，共享输入输出流会导致并发情况下的字节流污染。连接池通过"借出-归还"机制实现线程封闭，让每个线程独占Jedis实例，本质是资源隔离而非线程安全改造。相比基于Netty的Lettuce采用NIO多路复用，Jedis需要创建大量连接应对高并发。解决方案不是修改Jedis底层，而是通过连接池实现线程级隔离，这是BIO模型的必然选择。
2026-01-08 19:45:00
721
原创 揭秘 pom.xml 背后的魔法：Maven 插件机制全解
本文深入揭秘了 Maven 的插件机制，阐明 Maven 核心框架本质上仅是协调流程管理的“包工头”，而编译、测试、打包等所有实质性构建任务全赖“插件”这一实际执行者完成。文章详细划分了插件的两类形态——即基于“约定优于配置”自动绑定生命周期的默认插件，和需显式配置以满足特定需求（如 Spring Boot 打包或代码检查）的额外插件，并指出开发者修改 pom.xml 的主要目的在于定制默认行为（如升级 JDK 版本）及通过锁定版本确保团队开发环境的一致性。此外，文中还通过生动的比喻厘清了 Plugin（工
2026-01-08 08:45:00
741
原创 拨开云雾见月明：彻底搞懂 Maven 三大生命周期与构建逻辑
本文深入解析Maven的三大生命周期(Clean、Default、Site)及其构建逻辑。通过高速公路的比喻，阐明三条生命周期独立运行、互不干扰的特性，重点剖析Default生命周期的关键阶段(compile→test→package→install→deploy)及其级联执行机制。文章解释了常用命令mvn clean install的工作原理，并提供了各阶段产出对照表，建议开发者养成使用clean命令确保构建纯净性的习惯，避免增量编译带来的潜在问题。
2026-01-07 19:45:00
1067
原创 Windows 本地部署 RocketMQ 全指南：配置、启动与避坑
本文详细介绍了在Windows本地部署RocketMQ的完整流程，包括环境准备、关键配置、服务启动和常见问题排查。重点讲解了JDK环境要求、内存参数调整、启动顺序以及自动创建Topic的配置技巧。文章还提供了可视化控制台的安装指南，帮助开发者更高效地管理RocketMQ。针对Windows环境下常见的内存溢出、路径错误等问题给出了具体解决方案，适合需要快速搭建本地开发环境的开发者参考。
2026-01-07 08:45:00
893
原创 揭秘中间件的 bin 目录：为什么 Windows 改 .cmd，Linux 改 .sh？
本文探讨了中间件安装包中 bin 目录下同时存在 .cmd 和 .sh 脚本的原因。文章指出这是 Windows 和 Linux 系统差异所致：Windows 依赖 .cmd 后缀和 CMD.exe 解释器，而 Linux 通过 Shebang 识别 .sh 脚本。作者对比了两种脚本在变量定义、注释、路径分隔符和换行符等方面的语法差异，并提醒开发者注意平台对应的脚本文件。最后提到随着 WSL、PowerShell Core 和 Docker 的发展，这种"双轨制"可能逐渐改变，但目前仍需
2026-01-06 19:45:00
911
原创 Linux 解压命令全集：从 tar 到 7z 的工程化实践指南
本文系统梳理了Linux下各类压缩文件的解压命令及工程实践要点。重点介绍了万能tar命令（-xvf参数）及其智能识别压缩格式的特性，详细说明了gzip、bzip2、xz等不同压缩格式的参数差异。同时涵盖zip、rar等跨平台格式的解压方法，强调指定解压目录的重要性。针对常见问题如中文乱码、权限管理和"炸弹包"防护提供了解决方案，并总结了常用压缩格式的速查表。掌握这些命令能有效提升Linux运维和开发效率。
2026-01-06 08:45:00
1057
原创 深度解密：Redis RDB 持久化策略——滑动窗口还是累积计数？
Redis RDB持久化触发机制解析：save <seconds> <changes>参数采用简单高效的双条件判断，而非滑动窗口算法。源码显示Redis仅维护两个变量：server.dirty（自上次保存后的修改次数）和server.lastsave（上次保存时间）。当同时满足"当前时间-上次保存时间≥配置时间"且"修改次数≥配置次数"时即触发bgsave，触发后计数器清零。以save 60 1000为例，若在70秒时累计修改达1000次即会触
2026-01-05 19:45:00
985
原创 2026年入坑消息队列：为什么我劝你首选 RocketMQ？
对于国内 Java 后端开发者而言，RocketMQ 是学习消息队列的绝对首选。相比于侧重“大数据管道”的 Kafka 和存在性能瓶颈且维护困难（Erlang 语言）的 RabbitMQ，RocketMQ 被视为各项指标均衡的“六边形战士”。它既兼顾了高吞吐与堆积能力，又完美支持事务消息、顺序消息和任意精度延时等复杂业务场景，是解决分布式事务的标准答案。更重要的是，RocketMQ 由纯 Java 编写，源码极具可读性，方便调试与深度掌控，已成为国内后端面试的“硬通货”。文章建议遵循“核心架构—业务场景—底
2026-01-05 08:45:00
641
原创 Lombok 速查指南：从基础注解到避坑实录
摘要：本文深入解析了Lombok工具的核心注解与实战应用技巧。重点介绍了@Getter/@Setter的访问控制、构造器注解与Spring整合的最佳实践，特别强调@RequiredArgsConstructor可替代@Autowired实现优雅注入。针对常见的@Data陷阱，详细分析了其在JPA实体中的禁用原因（性能问题和可变字段风险），并给出解决方案。文章还提供了@Builder和@Value等进阶用法，最后附上注解决策图谱，强调Lombok应服务于代码清晰度而非隐藏逻辑。特别提醒开发者检查JPA实体中是
2026-01-03 22:00:00
868
原创 为什么一个简单的 SELECT 会把 DDL 给卡死？
摘要：MySQL的元数据锁(MDL)机制保护表结构一致性，读操作(共享锁)和写操作(排它锁)的互斥关系常导致DDL被未提交的SELECT阻塞。MDL锁在事务提交后才释放，长事务会持续持有锁。同一事务内从共享锁升级到排它锁是允许的，阻塞通常由其他事务的未提交操作引起。建议执行DDL前检查并处理长事务，避免锁冲突导致系统性能问题。
2026-01-03 17:34:41
965
原创 硬核图解：MySQL 是如何利用 MVCC + 锁实现“可重复读”的？
摘要：本文通过银行转账与财务审计的并发场景，深入解析MySQL如何利用MVCC和锁机制实现"可重复读"隔离级别。当两个事务并发执行时，MVCC通过Read View和Undo Log版本链保证事务读取数据的一致性，而锁机制则确保并发写操作的安全性。文章详细拆解了事务执行过程中数据的流转过程，揭示了MySQL通过读写分离（MVCC处理读并发，锁处理写并发）来保证数据绝对安全的底层原理。这种组合机制既避免了读写阻塞，又防止了数据不一致问题，是数据库隔离性的核心保障。
2026-01-02 16:38:17
1188
原创 深度分页的性能陷阱：为什么 MySQL 索引无法实现“瞬移”？
摘要 深度分页查询（如 LIMIT 1000000, 10）是常见的MySQL性能陷阱。虽然用户期望数据库能直接定位到第100万行，但实际上MySQL必须扫描并丢弃前100万条记录才能获取结果。这是因为：1）B+树索引不支持按记录数直接定位；2）物理数据不连续，无法通过简单计算找到位置。优化方案包括：1）游标法（利用已知ID快速定位）；2）延迟关联（先轻量级扫描ID，再精确获取数据）。从根本上，应重新评估业务需求，限制分页深度或改用搜索引擎处理海量数据分页。理解数据库物理限制，避免让其执行不擅长的操作，才是
2026-01-02 16:36:08
779
原创 为什么 epoll 监听不了本地磁盘？深挖 Linux IO 模型的“双重标准”
本文从Linux内核视角分析了IO多路复用技术在网络与磁盘I/O上的本质差异。核心指出epoll等机制对磁盘文件失效的原因：内核将文件视为"永远就绪"，导致epoll无法真正避免阻塞。针对服务器处理磁盘I/O的工业级方案，文章提出三种演进路径：主流的线程池方案(如Node.js/Java NIO)、存在缺陷的Linux Native AIO，以及革命性的io_uring技术(Linux 5.1+)。最后强调技术选型的关键：网络开发首选epoll，存储系统应选择线程池或io_uring，理
2026-01-01 19:45:00
491
原创 架构误区：Redisson 和 Seata 功能重复？二选一就够了？
本文深入剖析了Redisson分布式锁与Seata分布式事务的本质区别，指出两者在分布式架构中必须配合使用而非二选一。通过外科手术的生动比喻，解释了Redisson解决并发竞争问题（如防止超卖），而Seata保证数据原子性（如事务回滚）。文章通过电商场景案例证明，单独使用任一组件都会导致数据不一致或超卖问题。最后强调正确的架构设计应采用"外层Redisson防并发+内层Seata保一致"的组合策略，并详细对比了两者在锁机制上的根本差异。
2026-01-01 08:45:00
1357
原创 Seata AT 模式：应用层回滚 vs 引擎层回滚
本文解析了Seata AT模式中的undo_log机制与MySQL底层undo log的本质区别。Seata的undo_log是应用层生成的数据快照（前后镜像），通过JDBC代理在执行业务SQL前后自动记录，并以JSON格式存入业务库的undo_log表。与MySQL引擎层的undo log不同，Seata的undo_log在事务提交后仍有效，用于分布式事务回滚时执行补偿SQL。这种设计通过一阶段本地提交释放数据库锁，解决了XA模式的长事务锁竞争问题，实现了高性能分布式事务。文章通过时序图和对比表，清晰展示
2025-12-31 19:45:00
788
原创 “幂等性”：分布式系统可靠性的最后一道防线
幂等性是分布式系统可靠性的核心防线，其本质在于确保同一操作请求无论执行多少次，对系统状态的影响均与仅执行一次时完全一致。 本文由浅入深，从电梯按钮的生活直觉引出概念，剖析了数据库操作中的天然幂等与高危非幂等场景（如相对值更新），指出在分布式网络超时引发重试、消息重复投递等不确定性因素下，幂等性设计对于防止“重复扣款”等生产事故至关重要。文章最终给出了基于唯一业务流水号的工程化解决方案，建议通过数据库唯一索引、Redis Token 防抖及状态机 CAS 机制等手段，构建“识别请求身份、拒绝重复执行”的防御体
2025-12-31 08:45:00
2074
原创 深入 Nacos 持久化机制：为什么重启后配置还在，权重却丢了？
摘要： 在微服务架构中，Nacos重启后配置数据保留但服务权重丢失的现象源于其数据持久化策略差异。配置中心数据(Config)采用强持久化存储，而服务发现(Naming)中的临时实例权重默认存储在内存中。当Nacos重启时，客户端重新注册会覆盖内存中的权重设置。解决方案包括：1)通过配置文件固定权重值；2)将实例设为持久化(CP模式)。这体现了Nacos在数据一致性与服务可用性间的权衡，理解其AP架构设计原理有助于正确使用中间件。(149字)
2025-12-30 19:45:00
1860
原创 深入 Spring Cloud Feign：为什么你的配置类没有被扫描，却依然生效了？
本文深入解析了Spring Cloud Feign配置类生效的底层机制。当在@FeignClient中指定配置类时，即使不加@Component且不在扫描路径下，配置依然能生效，这是因为Feign通过FeignClientFactory手动注册配置类到子容器中，而非依赖自动扫描。文章揭示了Spring Cloud的核心设计——父子上下文隔离机制：父容器包含业务代码和Feign代理，子容器独立维护各服务的配置。这种架构使得主业务代码无法注入子容器的Bean，但实现了细粒度的服务治理。最后提醒开发者避免错误地为
2025-12-30 08:45:00
860
原创 微服务容错设计：Sentinel 全局异常处理与 Feign 降级策略的边界权衡
微服务容错设计中，Sentinel全局异常处理与Feign降级策略存在本质差异：FallbackFactory是"全能兜底"机制，捕获所有Feign调用异常并返回默认值；而SentinelExceptionHandler则是"最后防线"，处理未被降级处理的异常。两者的协作形成漏斗效应：FallbackFactory优先消化异常，仅当降级失败时异常才会传递到全局处理器。实践建议：内部调用优先降级保证流程连续性，外部接口必须明确报错，区分可降级与关键异常。理解这种&quo
2025-12-29 19:45:00
1232
原创 深入网络编程基石：什么是 Socket 与客户端请求？
本文深入探讨了网络编程中的核心概念Socket及其在客户端请求中的应用。Socket本质上是操作系统提供的特殊文件句柄，用于网络数据收发，由IP地址和端口号组成。文章将客户端Socket请求比作"打电话"过程，详细解析了创建、连接、发送、接收和关闭五个关键步骤。通过肯德基点餐和Redis客户端实例的生动类比，帮助读者理解Socket在真实场景中的应用。理解Socket这一底层机制，有助于开发者更好地掌握网络编程的核心原理，无论上层协议如何封装，最终都回归到Socket的基础读写操作。
2025-12-29 08:45:00
1408
原创 源码级解密：Spring Cloud Gateway 负载均衡 (lb) 模式下，如何“猜”出下游协议？
本文解析了Spring Cloud Gateway在负载均衡(lb)模式下如何确定下游服务协议的关键机制。通过源码分析发现，Gateway通过ServiceInstance接口的isSecure()方法判断协议类型：默认HTTP(false)，HTTPS需显式配置(true)。文章详细介绍了协议重构流程，并给出Nacos中开启HTTPS的两种配置方式，体现了Spring Cloud"约定优于配置"的设计理念。最后提醒开发者注意协议匹配问题，避免因配置不当导致连接异常。
2025-12-28 19:45:00
559
原创 Spring:第三方 JAR 包 Bean 注册的 5 种姿势，你还在用 ComponentScan 吗？
本文探讨了在Spring Boot项目中注册第三方JAR包Bean的5种方案。问题源于Spring默认只扫描主项目包路径，导致外部依赖的Bean无法自动注册。解决方案分为两类：消费端硬编码（包括@ComponentScan、@Import和手动@Bean）和提供端自动装配（自定义@EnableXXX注解和SPI自动装配）。文章分析了每种方案的优缺点，推荐优先使用SPI自动装配（Starter模式），遵循"约定大于配置"原则实现无感接入。最后提供了选型决策矩阵，帮助开发者根据场景选择最适合
2025-12-28 08:45:00
1247
原创 深入 Redis 7.0 内核：Listpack 是如何彻底消灭“连锁更新”的？
Redis 7.0 引入 Listpack 替代 Ziplist，彻底解决了"连锁更新"问题。Ziplist 由于节点间相互依赖，当修改节点长度时可能引发级联更新，导致性能退化到O(N^2)。Listpack 通过将节点长度信息存储在当前节点尾部(Backlen)，实现节点完全独立。这种设计虽然仍需内存移动(O(N))，但消除了逻辑上的连锁反应，保证了稳定的时间复杂度。Listpack 保留紧凑内存布局优势，同时通过巧妙的结构调整，成为Redis 7.0+中Hash/List/ZSet等
2025-12-27 19:45:00
1141
原创 微服务高可用实战：服务列表缓存更新延迟引发的“调用悬空”问题与解法
摘要：本文探讨微服务架构中因服务列表缓存更新延迟导致的"调用悬空"问题。当服务实例宕机而消费者缓存未及时刷新时，请求会被错误路由到已失效节点。解决方案包括：1)客户端负载均衡器(Ribbon/LoadBalancer)的重试机制，自动切换健康节点；2)Nacos注册中心通过Push+Pull机制缩短服务状态感知延迟。文章特别强调重试机制需谨慎配置，避免非幂等操作导致数据不一致，建议仅对GET请求开启重试功能。
2025-12-27 08:45:00
1611
原创 Epoll 核心解密：服务端如何区分“新连接”与“老数据”？
本文深入解析了高性能网络服务器如何区分新连接请求与已有连接数据。核心在于服务器通过两类文件描述符（FD）实现：监听Socket（处理新连接请求）和已连接Socket（处理业务数据）。内核基于TCP四元组和标志位将数据包精准分发到对应的FD，Epoll通过监控这两类FD实现高效事件驱动。服务端通过判断被唤醒的FD类型来决定执行accept()建立新连接或read()处理业务数据。这种设计完美解耦连接管理与业务处理，实现了O(1)复杂度的事件响应，是支撑十万级并发的关键机制。
2025-12-26 19:45:00
770
原创 Redis ZSet 底层揭秘：Ziplist 是如何存储 Member 与 Score 的？
Redis ZSet底层采用Ziplist存储时，Member和Score并非拼接成字符串，而是作为相邻的两个独立Entry存储。这种设计既保证了二进制安全（避免特殊字符冲突），又提升了性能（Score可单独编码为整数）。Ziplist内部按[元素,分数,元素,分数...]顺序排列，严格按分数排序。源码中通过连续两次插入操作实现这种存储方式，体现了Redis对空间和时间的极致优化。
2025-12-26 08:45:00
688
原创 计算机组成原理：大端序与小端序的原理与权衡
本文深入解析了计算机底层数据存储的两种字节序：大端序(Big-Endian)和小端序(Little-Endian)。大端序将高位字节存储在低地址，符合人类阅读习惯，主要用于网络协议和部分RISC架构；小端序将低位字节存储在低地址，更利于机器处理，是x86/ARM架构的主流选择。文章详细比较了两者在内存布局、类型转换、运算效率等方面的差异，并分析了大端序在网络传输和调试中的优势。两种字节序各有侧重，反映了计算机设计中面向人类可读性和面向机器效率的不同权衡。
2025-12-25 19:45:00
585
原创 ⭐️深入 IO 多路复用：数据的“生产”与“消费”模型解析⭐️
本文深入解析了IO多路复用的核心机制，重点比较了select/poll和epoll的工作方式差异。文章指出所有IO多路复用技术底层的数据准备流程是一致的，由硬件中断和内核自动完成，不需要应用层干预。关键区别在于"就绪状态"的感知方式：select/poll采用无状态的轮询机制，每次调用都需要全量扫描所有文件描述符；而epoll采用有状态的事件驱动机制，通过注册和回调实现高效的就绪通知。文章用"老师收作业"的生动比喻，形象说明了两种模式的工作差异，最终指出epoll的高
2025-12-25 08:45:00
830
原创 ⭐️深入Redis内核：从redisObject看Hash结构的嵌套误区⭐️
摘要： Redis的redisObject结构虽可封装多种数据类型，但Hash结构内部存在严格限制。通过分析源码发现，Redis维护了两层字典结构：全局字典（支持多类型Value）和Hash内部字典（仅限String类型Value）。物理上dictEntry的void*指针虽可指向任意地址，但逻辑上Hash内部Value被强制限定为字符串类型。这种设计避免了Redis成为文档型数据库，简化了持久化等机制。实际工程中如需嵌套数据结构，可采用序列化、Key命名空间或RedisJSON模块等解决方案。理解Redi
2025-12-24 19:45:00
2473
原创 深入 Redis Listpack：倒序遍历时如何定位变长长度的首地址？
Redis Listpack采用变长编码机制存储节点长度信息，通过最高位标记法(MSB)实现高效倒序遍历。每个字节的最高位作为信号灯：1表示继续左移，0标识首地址。这种设计无需额外存储长度信息，仅通过位运算和指针移动即可在O(1)时间内定位变长字段起始位置，体现了Redis在位级编码上的精妙优化，既保持内存紧凑又支持高效双向遍历。
2025-12-24 08:45:00
1070
原创 深入 Redis 内核：Dict 扩容是为了生存，缩容是为了经济
本文深入探讨了Redis字典(Dict)的扩容与缩容机制。通过分析源码，揭示了二者底层均采用渐进式Rehash的数据迁移方式，但在触发策略上存在本质差异：扩容是用户请求驱动的同步操作，在哈希表负载因子≥1时立即执行以保证性能；缩容则是后台任务触发的异步操作，仅当负载因子<0.1且无持久化操作时才谨慎执行。这种设计通过复用代码逻辑降低复杂度，同时利用10%的极低缩容阈值防止"扩容-缩容"抖动，体现了Redis在内存利用率与系统稳定性间的精妙权衡。
2025-12-23 19:45:00
974
原创 Redis 故障检测进化论：从 Sentinel 到 Cluster 的机制演变
Redis 故障检测机制经历了从 Sentinel 到 Cluster 的演变，体现了两种不同的架构哲学。Sentinel 采用外部观察者模式，通过中心化的仲裁机制实现故障判定；而 Cluster 则采用去中心化的 Gossip 协议，让数据节点自身参与状态确认。两者虽然都基于PING/PONG心跳机制，但在共识达成方式上存在本质差异：Sentinel依赖Quorum投票，Cluster通过Gossip传播和过半Master确认。这种演变反映了Redis从简单主从架构向大规模分片场景的适应过程，但也带来了G
2025-12-23 08:00:00
817
原创 避坑指南：如何优雅地使用 StringRedisTemplate 将对象存储为 Redis Hash
摘要： 本文探讨了使用StringRedisTemplate存储Java对象为Redis Hash时常见的序列化问题。当对象包含非String类型字段或嵌套结构时，默认的toString()转换会导致数据损坏。解决方案包括：1) 全量JSON策略（适合复杂对象）；2) 手动扁平化（适合简单对象）；3) 推荐使用Jackson2HashMapper进行自动扁平化处理，支持嵌套结构且代码简洁。建议根据对象复杂度选择方案，对于复杂对象优先考虑JSON String或Jackson2HashMapper，避免数据序
2025-12-22 09:00:00
713
原创 Redis Hash 调优深水区：从 ZipList 陷阱到分片之道
Redis Hash 类型在内存优化中存在ZipList与HashTable的编码选择权衡。本文指出BigKey的定义与底层编码无关，关键在于数据量和内存占用。强行使用大ZipList虽省内存但会导致O(N)查找性能问题，造成CPU瓶颈。相比之下，将大数据拆分为多个小型Hash是更优方案：既能保持ZipList的压缩优势，又因控制每个Hash长度而维持高效访问。结论表明，Hash优化应在内存与CPU间平衡，推荐水平分片策略而非无限调大ZipList阈值，以实现空间与时间效率的双赢。
2025-12-21 08:00:00
1242
原创 Redis 性能优化必读：不仅 Value，Key 也需要“编码”
Redis 性能优化不仅涉及 Value 编码，Key 同样遵循编码规则。Key 作为独立对象，当长度≤44字节时采用 embstr 编码（内存连续高效），超过则转为 raw 编码（内存分散低效）。最佳实践推荐结构化短 Key（如"业务:类型:id"），既提升可读性又确保 embstr 状态。亿级数据场景下，控制 Key 长度对减少内存碎片和指针开销至关重要。优化 Redis 需要同时关注 Key 的 embstr 保持和 Value 的合适数据结构选择，才能实现完全的内存效率。
2025-12-20 12:27:29
916
原创 深入剖析 Redis 客户端：Sentinel 模式下的“寻址”与“感知”艺术
Redis客户端在哨兵模式下通过"动静结合"策略实现主节点寻址与感知：启动阶段主动询问哨兵获取主节点地址，运行时订阅+switch-master频道被动接收故障转移通知。这与哨兵间通信的__sentinel__:hello频道不同，客户端关注的是最终结果而非内部状态。这种设计既保证了初始连接的效率，又能实时感知集群变化，实现高可用架构下的自动故障转移。
2025-12-19 16:57:00
951
原创 解密 Redis 哨兵集群的自动发现机制：无需配置的“默契”
Redis哨兵集群通过Master节点的Pub/Sub机制实现自动发现，无需显式配置其他哨兵地址。每个哨兵启动后订阅Master的__sentinel__:hello频道，并每隔2秒广播自身信息。其他哨兵收到消息后建立直接连接，形成P2P网络。这种设计解决了配置解耦问题，支持动态扩缩容，无需引入额外服务发现组件，是"利用中心化节点完成去中心化拓扑构建"的典范。
2025-12-19 16:34:03
477
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人