- 博客(138)
- 收藏
- 关注
RSS订阅原创 Netty综合案例（上）
本文介绍了基于Netty的客户端-服务端通信系统实现方案。主要内容包括：1）采用消息头+消息体的实体模型设计；2）客户端异步启动与服务端多线程Reactor模式实现；3）完整的Pipeline责任链设计，包含半包/粘包处理、编解码、心跳检测、认证授权等组件；4）特别说明应用层心跳检测的必要性（弥补TCP keep-alive机制不足）；5）详细目录结构规划和关键代码示例。系统采用模块化设计，通过Handler责任链实现各功能组件的解耦，为业务通信提供稳定可靠的底层框架支持。
2025-07-26 14:51:32
256
原创 Netty核心组件
Netty核心组件与编程模型摘要 本文梳理了Netty框架的核心组件及其编程模型，主要内容包括： 核心组件 Bootstrap：客户端/服务端启动入口 Channel：网络通信抽象层，封装Socket操作 EventLoop：基于Reactor模型的线程处理器，支持多路复用 ChannelHandler：处理网络与业务逻辑，分为入站/出站两种类型 Pipeline：责任链模式组织Handler，管理事件流转 关键机制 EventLoop与Channel绑定机制 Pipeline的双向链表实现及事件处理流程
2025-07-20 11:57:11
940
原创 NIO零拷贝
本文介绍了socket缓冲区与零拷贝技术的实现原理。socket缓冲区包含发送和接收缓冲区，确保消息可靠传输。应用程序使用直接内存而非堆内存，避免垃圾回收带来的问题。零拷贝技术通过减少数据拷贝次数提升性能，包括DMA（直接内存访问）、Linux的MMAP内存映射、sendFile和slice三种实现方式。其中MMAP取消文件读取缓冲区，sendFile避免应用程序缓冲区中转，slice通过共享内存区域优化传输。这些技术有效减少了CPU上下文切换和拷贝开销，提升数据传输效率。
2025-07-19 10:52:59
869
原创 NIO网络通信基础
本文摘要： 文章详细介绍了NIO（非阻塞IO）的核心机制与实现原理。首先对比了BIO（阻塞IO）的局限性，指出NIO通过Reactor模式和多路复用机制实现单线程处理多连接。重点解析了NIO三大组件：Selector（事件调度器）、Channel（双向数据通道）和Buffer（数据缓冲区），以及连接、读写等核心事件类型。通过Socket通信模型图解，说明了服务端与客户端的事件处理流程。文章深入剖析了Reactor模式的三种实现方案，并通过服务端代码示例演示了NIO的实际应用，包括事件注册、轮询处理等关键步骤
2025-07-18 21:51:30
820
原创 RabbitMQ队列的选择
RabbitMQ队列特性与选择指南 本文介绍了RabbitMQ的三种队列类型及其适用场景： Classic经典队列：默认队列类型，支持持久化(durable)、排他(exclusive)、自动删除(autoDelete)等配置选项，适用于单机环境下的常规消息队列需求。 Quorum仲裁队列：基于Raft算法的高可用解决方案，取代传统镜像队列，避免脑裂问题，提供消息重试次数监控和处理机制，适合集群环境中对可靠性要求高的场景。 Stream流式队列：采用AOF文件存储消息，支持消息回溯和重复消费，允许指定消费偏
2025-07-13 15:38:56
875
原创 Redis内存队列Stream
Redis Stream是Redis 5.0推出的持久化消息队列，支持多播功能。它以key-value形式存储，key为队列名，value为消息链表结构，包含ID、消费组、消费者和消息内容等元素。生产端通过XADD添加消息，XDEL删除消息；消费端使用XREAD读取消息，支持阻塞读取和指定范围查询。消费组管理通过XGROUP实现，允许多个消费者组独立消费消息。XINFO命令可查询队列状态、消费组和消费者信息。Stream提供了消息ID自增、ACK机制等功能，确保消息可靠投递和消费跟踪。
2025-07-06 16:12:28
998
原创 Redis性能优化
Redis使用优化笔记 Bigkey问题 定义：字符串型value>10KB或集合元素过多 风险：阻塞命令处理、网络拥塞、批量删除延迟 优化：业务拆分存储、必要字段存储、避免全量查询、分散过期时间 命令使用建议 避免全量查询命令，改用SCAN渐进式遍历 禁用危险命令（如flushall），可重命名保护 合理使用pipeline批量操作（注意非原子性） 连接池配置 关键参数：maxTotal（最大连接数）、maxIdle（最大空闲数）、minIdle（最小空闲数） 建议：maxIdle≈maxTotal
2025-07-05 17:37:48
1135
1
原创 Redis缓存架构实战
本文探讨了Redis在高并发场景下的应用策略，重点分析了缓存热点数据的关键技术要点。文章首先介绍了基础案例工程，展示了缓存与数据库的增改查操作。随后提出数据冷热分离策略，通过设置缓存过期时间+续期机制来自动筛选热点数据。针对缓存击穿问题，建议采用随机过期时间分散key过期压力。对于缓存穿透问题，推荐缓存空值来缓解恶意请求攻击。全文围绕高并发场景下的Redis优化展开，提供了从架构设计到具体实现的解决方案。
2025-07-03 21:21:55
985
原创 Redis分布式锁核心原理源码
Redis分布式锁实现与Redisson方案分析 摘要： 本文分析了Redis实现分布式锁的演进过程，从基础的setnx命令到逐步解决死锁、误删锁等问题，最终实现包含线程标识和lua脚本的版本。同时指出自研方案仍存在锁续期、重入等问题，并介绍了Redisson作为成熟解决方案的优势。文章通过库存扣减案例，详细展示了分布式锁实现的技术细节，包括原子性操作、异常处理和锁超时等关键点，为分布式系统开发提供了实践指导。
2025-06-29 19:39:18
1150
2
原创 Redis集群架构
Redis Cluster集群架构通过数据分片存储在多组主从节点上，解决了传统主从-哨兵模式单机数据量过大的问题。搭建集群需至少三主三从节点，配置16384个哈希槽位分散数据存储。客户端操作时自动计算key的哈希槽位并重定向到对应节点，集群模式下读写均走主节点，从节点仅作备份。实验展示了六节点集群的搭建过程，包括配置文件修改、实例启动和集群创建命令。通过CRC16算法计算key的哈希值确定存储位置，实现数据均衡分布和高效访问。该架构提升了Redis的扩展性和高可用性，适合高并发场景。
2025-06-28 17:59:05
975
原创 Redis主从架构&哨兵模式
Redis主从架构与哨兵机制实现高可用 摘要：本文介绍了Redis高可用解决方案，包括主从模式和哨兵架构。主从架构采用一主多从或主-从-从结构，主节点处理写请求，从节点负责读请求和数据同步。主从同步分为全量复制和增量复制两种机制，首次连接采用全量复制，断线重连则根据偏移量进行增量同步。哨兵架构通过监控集群实现自动故障转移，当主节点失效时自动选举新主节点。文章详细演示了主从和哨兵环境的搭建步骤，并测试了哨兵自动故障恢复功能，确保Redis在节点故障时仍能持续提供服务。
2025-06-26 21:19:10
937
原创 Redis持久化机制
Redis持久化机制解析 Redis提供RDB和AOF两种持久化方式：RDB通过快照存储二进制数据文件，支持手动/自动触发，默认开启但可能丢失数据；AOF记录操作命令，数据更完整但恢复较慢，需要手动开启。生产环境推荐混合持久化（需先开启AOF），在AOF重写时将内存数据转为RDB格式存储，期间增量命令仍以AOF格式追加，兼顾恢复速度与数据完整性。启动时若同时存在两种文件，优先使用AOF恢复。
2025-06-24 20:04:38
862
原创 Redis核心数据结构实战
Redis提供了五种核心数据结构及其应用场景：String（单值缓存/对象缓存/计数器）、Hash（对象缓存/购物车）、List（栈/队列/消息推送）、Set（抽奖/点赞/集合操作）和Zset（有序集合）。String适用于临时数据存储和计数，Hash适合细粒度修改的对象缓存，List可实现消息队列，Set用于去重场景如抽奖和共同关注，Zset则适用于需要排序的场景。每种结构各有优势，可根据业务需求选择合适的Redis数据类型。
2025-06-22 16:05:17
1007
原创 计算机网络学习笔记：应用层概述、动态主机配置协议DHCP
应用层位于计算机网络结构的最上层，用于解决应用进程的交互以实现特定网络应用的问题。万维网WWW，域名系统DNS，动态主机配置协议DHCP，电子邮件，文件传送FTP和P2P文件共享，多媒体网络应用，都是属于应用层的范畴。目前应用层流行的两种架构：C/S和P2P。
2025-06-21 16:48:42
592
原创 计算机网络学习笔记：Wireshark观察TCP通信
Wireshark是一款功能强大的网络抓包和协议分析工具，用于实时捕获和解析网络通信数据，帮助用户诊断网络问题、分析协议细节或进行安全审计。本篇将用Wireshark工具对TCP通信案例进行抓包，分析三报文握手和四报文挥手。
2025-06-21 11:43:26
1141
原创 计算机网络学习笔记：TCP可靠传输实现、超时重传时间选择
TCP可靠传输机制采用滑动窗口和确认机制实现：发送方缓存窗口内的未确认数据，接收方反馈确认报文并进行流量控制。滑动窗口通过指针区分已发送未确认、待发送和窗口外的数据。累计确认策略下，接收方缓存不连续报文并反馈最大连续序号ACK。超时重传采用Karn算法优化RTT估算，避免重传报文ACK干扰，并使用指数退避调整RTO。该机制确保数据传输可靠性，同时兼顾效率与动态网络适应性。
2025-06-19 19:49:26
814
原创 计算机网络学习笔记：TCP流控、拥塞控制
摘要： TCP流量控制通过接收窗口(rwnd)和发送窗口(swnd)协调发送方与接收方的速率匹配，防止接收方缓存溢出，并通过持续计时器避免死锁。拥塞控制则通过拥塞窗口(cwnd)和慢开始门限(ssthresh)动态调整发送速率，结合慢开始、拥塞避免、快重传和快恢复算法，避免网络过载。流量控制关注点对点通信，而拥塞控制关注全局网络稳定性，两者协同保障TCP传输的可靠性与效率。
2025-06-17 21:54:14
733
原创 计算机网络学习笔记：TCP三报文握手、四报文挥手
本文详细介绍了TCP通信的建立与终止过程。在连接建立阶段，通过三报文握手确认双方的收发能力、协商参数并分配资源：客户发送SYN报文，服务端回复SYN+ACK，客户再回复ACK完成连接。在终止阶段采用四报文挥手释放连接：客户发送FIN报文，服务端回复ACK进入半关闭状态，服务端再发送FIN报文，客户回复ACK后等待2MSL时间确保连接完全关闭。文章还解释了三次握手和四次挥手的必要性，防止历史连接干扰和确保可靠终止。整个过程通过状态转换图和参数说明，清晰展示了TCP协议如何实现可靠连接管理。
2025-06-15 16:10:53
1051
原创 计算机网络学习笔记：运输层概述&UDP、TCP对比
运输层位于网络层与应用层之间，为不同主机上的应用进程提供逻辑通信服务，核心功能包括进程间通信、复用分用、差错检测以及流量控制等。TCP和UDP是其两大协议，通过端口号标识进程，实现应用层与传输层的连接。 一次HTTP请求流程：用户输入域名后，DNS查询首先使用UDP协议（端口53）获取IP地址；之后HTTP请求通过TCP协议与服务器通信，完成请求响应交互。整个过程涉及运输层的复用分用机制，确保数据准确交付到目标应用进程。
2025-06-14 19:25:03
1076
原创 BIO网络通信基础（TCP协议）
BIO（阻塞IO）案例展示了Java传统的阻塞式网络通信实现。服务端通过ServerSocket监听端口，在accept()和read()处会阻塞线程，直到客户端连接或发送数据；客户端主动连接后发送"Hello Server"并等待回显。时序图清晰呈现了"连接-发送-回显-断开"的交互流程。调试分析发现，阻塞发生在操作系统底层调用，JVM层面线程仍显示为RUNNABLE状态。最后提出多线程改进方案，通过线程池处理并发客户端请求，解决单线程服务端串行处理的性能瓶颈。该案
2025-06-13 21:16:24
796
原创 @Indexed原理与实战
摘要： @Indexed是Spring提供的用来加速启动速度的注解，配合spring-context-indexer依赖使用，会在编译时生成META-INF/spring.components索引文件。该文件存储了标注@Indexed的类及其注解信息。Spring在扫描组件时优先使用索引文件，减少类路径扫描的开销。@Component等注解本身已包含@Indexed，因此无需手动添加。源码分析表明，索引的生成和读取分别由CandidateComponentsIndexer和ClassPathScanning
2025-06-11 21:48:49
906
原创 @Configuration原理与实战
本文摘要： Spring框架中@Configuration与@Component注解在配置类使用上存在关键差异。实验表明，@Configuration标注类中调用@Bean方法会返回相同实例（单例），而@Component标注类每次调用将创建新实例。这种差异源于Spring对@Configuration类的特殊处理：通过CGLIB生成子类代理，在解析阶段标记配置类为"full"模式，并植入包含BeanMethodInterceptor的拦截器链。该拦截器会在方法调用时检查并维护Bean的
2025-06-10 22:02:40
991
原创 @Lazy原理与实战
Spring的@Lazy注解实现懒加载机制，可作用于类、方法、字段及参数。通过设置bean定义的lazyInit属性，在容器启动时延迟实例化，首次调用时才实际创建对象。解析阶段分为组件扫描和手动注册两种场景，最终由processCommonDefinitionAnnotations设置延迟属性。该机制通过生成代理对象实现延迟注入，既能提升启动性能，又能解决循环依赖问题（除构造器循环外），尤其在处理资源密集型Bean时效果显著。实际调用时通过TargetSource回调触发真实对象的创建与依赖解析。
2025-06-09 22:35:34
1002
原创 @Import原理与实战
摘要： Spring框架的@Import注解提供了三种导入方式：1)直接导入普通类并注册为bean；2)通过ImportSelector实现类动态选择要导入的类；3)通过ImportBeanDefinitionRegistrar实现类自定义注册逻辑。解析过程由ConfigurationClassPostProcessor处理，在refresh阶段的invokeBeanFactoryPostProcessors中完成，分别针对不同类型采用递归解析策略。其中ImportSelector的处理可能延迟进行，而Im
2025-06-08 19:58:55
683
原创 彻底理解Spring三级缓存机制
Spring解决循环依赖问题的关键在于三级缓存机制，包括一级缓存存放完整单例对象、二级缓存存放早期实例化对象、三级缓存保存单例工厂。当存在AOP代理需求时，三级缓存确保相互引用的Bean能获得同一代理对象实例。若仅使用二级缓存，会导致某些Bean持有未经AOP处理的原始对象，而其他Bean持有代理对象，造成不一致。通过代理工厂模式示例证明，AOP会生成新代理对象而非修改原引用，因此早期注入的对象不会自动转为代理对象。三级缓存保证了循环依赖场景下所有Bean都能获得正确的代理实例。
2025-06-01 21:40:18
1101
原创 Listener method could not be invoked with the incoming message
在使用 RabbitMQ 进行消息传递时，生产者发送的消息无法被消费者正确反序列化，导致监听方法调用失败。问题根源在于未配置 RabbitMQ 使用 JSON 消息转换器，Spring Boot 默认使用了 SimpleMessageConverter，无法将 JSON 数据反序列化为目标对象。解决方案是在配置类中显式使用 Jackson2JsonMessageConverter，为 RabbitTemplate 和 SimpleRabbitListenerContainerFactory 设置该转换器，确
2025-05-18 17:40:32
682
原创 Seata AT模式数据库隔离级别与锁设计
一阶段：业务 SQL 正常执行并记录操作前镜像与后镜像（undo_log）二阶段提交：异步清除 undo_log，不影响业务性能二阶段回滚：根据 undo_log 恢复原始数据为了实现这些能力，Seata 需要同时在应用层和数据库层建立一套“软隔离+逻辑锁”的机制，以避免脏写和并发冲突。
2025-05-03 19:08:54
938
原创 Seata RM的事务提交与回滚源码解析
当TC接收到TM的提交/回滚请求后，在处理好自身相关的逻辑后，会向每一个分支事务RM发送请求，驱动RM执行实际的提交/回滚业务逻辑：微服务端处理对应请求，是在在全局事务的一阶段中，业务 SQL 已经通过本地事务提交完成，Spring 的事务已结束。实际操作：删除undo_log表中与本次事务相关的日志记录。实现机制：使用阻塞队列存储待处理的提交上下文（借助定时任务线程池（AsyncWorker）周期性调度任务；结合异步编排机制，确保即使提交队列满时也能自动重试。
2025-05-03 16:14:03
908
原创 Seata RM注册分支事务源码解析
微服务端执行具体业务逻辑的部分，通常被称为事务的参与者RM。需要与Seata服务端TC进行通信，上报并成为分支事务。在微服务架构中，事务参与者在执行本地数据库操作并将事务设置为非自动提交（构建前后镜像（Before/After Image）用于回滚。写入 Undo Log（用于将来回滚）。向发起注册分支事务的请求。如果分支注册成功，提交本地事务；否则回滚并上报一阶段失败。TC（事务协调者）尝试获取全局锁，即向lock_table表插入锁记录。注册分支事务元信息到。
2025-05-03 11:45:01
937
原创 Seata客户端代理增强核心源码解析
当调用到标注了注解的方法，最终会执行到的execute方法：这是一个标准的事务编程模型。是执行目标业务代码的逻辑，其中就包含了如何生成前置镜像、后置镜像、记录undolog、向TC注册分支事务的逻辑。Seata 通过对客户端数据源进行代理增强，实现了在 SQL 执行前后生成前置镜像（Before Image）和后置镜像（After Image），并构建 UndoLog，以支持分布式事务的自动回滚能力。
2025-05-02 17:09:42
1349
原创 Seata服务端同步提交事务核心源码解析
本篇介绍Seata服务端TC如何驱动RM提交事务。释放锁，删除lock_table的记录。将表中的状态改为2。遍历并驱动所有的分支事务提交（Phase Two 提交），每个分支由 TC 向对应的 RM 发起提交请求。根据各分支事务返回的状态进行处理：若分支返回，表示该分支已成功提交，TC 会调用方法：清理内存中的，并删除该分支在和lock_table中的记录。若分支返回，表示分支提交失败且不可重试，TC 会将全局事务状态设置为（属于结束状态），并清理内存中的全局事务会话。
2025-05-01 21:14:37
996
原创 Seata服务端开启事务核心源码解析
Seata服务端作为TC角色，用于接收客户端标注了也就是TM角色的开启事务，提交/回滚事务请求，维护全局和分支事务的状态，并驱动客户端的RM角色真正地去执行开启事务，提交/回滚事务操作。服务端与客户端交互的类，是在顶级接口中，定义了开启，提交/回滚事务的统一处理模板，接收客户端的请求：重写了各自的handle方法，加入了自己的处理逻辑，实际上也是委托子类去完成具体的逻辑的。
2025-05-01 17:11:49
753
原创 Seata客户端事务模型源码解析
的execute方法，是Seata客户端事务模型的体现：本篇主要介绍客户端开启事务，执行事务，提交/回滚与服务端的交互。Seata 客户端（微服务端）在事务处理上遵循与传统事务编程模型一致的理念，这与 Spring 的编程风格保持高度契合。不同之处在于：事务的开启、提交以及回滚并非本地直接完成，而是通过与 Seata 事务协调器（TC）进行通信，由服务端统一调度管理。在整个事务生命周期中，XID（全局事务ID） 是唯一标识符，作为贯穿始终的上下文信息，它驱动各个参与的微服务执行具体的分支事务逻辑。
2025-05-01 11:27:10
689
原创 Seata客户端@GlobalTransactional核心源码解析
Seata是阿里开源的分布式事务解决方案。在Spring传统的事务中，开启事务，执行事务，回滚/提交事务，统一由Spring进行管理，向数据库发起指令。而分布式事务中，分为了客户端（微服务端）和服务端（Seata）、注册中心（通常使用Nacos）这三个部分。Nacos提供了服务注册与发现，以及管理Seata配置的作用。无论是开启事务，执行事务，还是提交事务，都不是单个微服务内部自己决定的，而是统一向服务端发起请求，由服务端进行一系列的处理后，再向微服务端发起请求，驱动微服务端执行操作。
2025-04-30 21:31:51
1138
原创 Sentinel规则持久化push模式改造
Sentinel规则持久化有两种模式，一种是前篇中提到的本地存储的pull模式，主要涉及到了和。前者的目的是为了定时获取配置文件的改动，并且同步到微服务端的内存。后者的目的则是将sentinel控制台推送的配置文件，写入到本地磁盘文件或数据库/redis等中间件中。因为微服务端的内存，需要通过定时任务拉取本地的变更病同步，所以称之为拉模式如果用户直接对本地文件进行的修改，那么同步至少需要3s的时间间隔。控制台在推送配置文件时，带有ip和端口。
2025-04-26 15:56:34
1350
原创 Nacos配置中心客户端处理服务端配置信息源码解析
Nacos配置中心，对于页面上用户操作的配置信息，实际上是使用了推拉结合的模式。服务端将配置信息推送到客户端。客户端主动向服务端发起请求拉取配置信息。本篇介绍服务端将配置信息推送到客户端，客户端的处理方式在 Nacos 配置中心中，服务端在检测到配置内容发生变更后，会客户端推送变更通知。客户端收到推送通知，并不会直接处理变更配置内容，而是通过一系列异步机制完成完整的配置拉取与刷新流程。
2025-04-20 12:12:55
1001
原创 Nacos配置中心服务端源码解析
Nacos除了可以实现服务的注册与发现，还具有统一进行配置管理</</</可以将项目中的配置文件，转移到配置中心：同时需要在项目的resource目录下，加入或spring:name: spring-cloud-nacos-config-demo #微服务名称# active: dev #加载开发环境的配置文件 mall-user-config-demo-dev.ymlcloud:nacos:config: #配置nacos配置中心地址。
2025-04-19 16:04:24
931
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人