- 博客(123)
- 资源 (10)
- 收藏
- 关注
RSS订阅原创 ISR 大量宕机后的“补员“机制——Kafka 的灾难生存指南
Kafka的ISR（同步副本集）与OSR（落后副本集）机制解析：OSR不会自动补入ISR，而是通过"自我救赎"方式满足同步条件后重新加入。核心机制包括：1）ISR入队需满足30秒内同步（replica.lag.time.max.ms）和追上Leader的LEO；2）OSR永远不能成为Leader（金融场景必须保持unclean.leader.election.enable=false）；3）宕机恢复时需先复活Leader，OSR再通过持续拉取数据重新同步。
2026-06-27 11:25:19
342
原创 Kafka vs RabbitMQ：高可用实现的核心差异
Kafka与RabbitMQ高可用机制对比摘要（140字）： Kafka采用分片复制（Partition+ISR）机制实现高可用，通过Leader/Follower副本和acks配置保障数据可靠性，吞吐量达百万级，适合日志流场景。RabbitMQ依赖镜像队列（MirrorQueue）进行主从复制，新版QuorumQueue基于Raft实现强一致，延迟低至微秒级，适合交易场景。核心差异在于架构基因：Kafka为分布式日志设计（分区存储+批量拉取），RabbitMQ是传统消息队列（内存缓冲+实时推送）。
2026-06-27 11:10:07
474
原创 kafka和rabbitmq的broker的组成差异
Kafka和RabbitMQ的核心架构对比：Kafka采用分区副本机制（Leader+Follower），基于JVM实现，依赖Zookeeper或KRaft协调，定位为高吞吐的分布式日志系统，适合日志流和事件源场景；RabbitMQ基于Erlang虚拟机，采用Exchange-Queue路由模型，支持多协议，属于消息队列路由器，更适合任务队列和灵活路由。两者设计哲学不同，Kafka侧重持久化有序日志，RabbitMQ强调消息分发能力。
2026-06-27 10:47:12
250
原创 gRPC和自定义TCP是不是都比http强
文章摘要：协议选择取决于使用场景。HTTP是通用协议，适合公网访问、浏览器调用和调试；gRPC/自定义TCP性能更优但兼容性差。内部系统可选用高效专用协议（如gRPC），对外接口宜采用通用HTTP协议。关键是根据实际需求权衡性能与兼容性，而非单纯追求底层协议。
2026-06-27 10:41:40
226
原创 Raft 为什么比 Kafka 更抗网络抖动
摘要： etcd与Kafka在抗抖动能力上存在本质差异。etcd基于Raft协议，适用于KB级元数据存储，采用同步复制和快速失败机制（抖动时立即选举新Leader），单次操作延迟低（<1ms），适合低延迟场景。Kafka处理MB级消息，依赖异步ISR复制和批量写入，抖动会导致ISR收缩、延迟累积甚至超时重试，设计更侧重高吞吐。核心区别在于数据量（小vs大）、同步模式（同步vs异步）及抖动响应策略（快速恢复vs延迟放大），因此etcd适合强一致性需求，Kafka则适合最终一致性高吞吐场景。
2026-06-26 19:07:01
255
原创 有仲裁机制了，为什么还要 Leader
摘要：分布式系统中，仲裁机制（如Raft、Quorum）确保数据安全性和故障容忍，而Leader机制解决决策效率问题。Leader作为协调中心，统一处理写入请求并同步到Followers，保证操作有序和一致性。没有Leader时，多节点协调复杂且可能导致数据不一致。Kafka的Partition Leader同理，确保分区写入顺序。简言之，仲裁保障数据安全，Leader提升决策效率，二者协同工作以维持系统稳定高效运行。
2026-06-26 18:59:02
123
原创 Kafka 为什么不用 Raft协议？
Raft作为强一致性协议，其串行写入、多数派确认等特性会严重限制吞吐量，而Kafka作为分布式日志系统，核心诉求是高吞吐（百万级/秒）和水平扩展（数千Partition）。通过副本因子、最小同步副本数和生产者ACK配置的组合，Kafka实现了"类Quorum"的弱一致性保障，在数据安全性与性能之间取得平衡。这种设计使Kafka在CAP定理中默认选择AP特性，但通过unclean.leader.election=false等配置可切换至CP模式。Kafka的ISR机制以可控的弱一致性为代价，换取到了高吞吐量
2026-06-26 18:44:28
413
原创 Kafka acks=all 为什么比 Raft 快
摘要： Kafka通过批处理、顺序IO+PageCache、异步刷盘、零拷贝等优化手段，在保证acks=all强一致性的同时实现远超Raft的吞吐性能（10-30倍）。核心差异在于：Raft单条同步处理，而Kafka批量处理+异步流水线化，以延迟和实现复杂度为代价换取吞吐量。优化包括：1) 批处理降低网络往返；2) PageCache+顺序写减少磁盘IO；3) 零拷贝减少CPU开销；4) 异步复制加速Leader写入；5) 多分区并行扩展吞吐。代价是弱化严格一致性、延迟波动及系统复杂度。
2026-06-26 18:32:24
357
原创 XXL-Job 分片广播底层机制
XXL-Job分片广播机制通过调度中心逐个触发执行器节点，仅传递分片参数（shardIndex/shardTotal），由执行器本地完成数据过滤处理。其核心特点是：1）无数据跨节点传输，仅通过RPC触发；2）分片参数通过ThreadLocal传递，与任务生命周期绑定；3）与Elastic-Job等基于ZK协调的方案不同，采用去中心化设计，框架不介入数据分片过程。业务层可自行实现一致性hash等分片策略，但分片总数在任务启动时即固定，适合静态分片场景。该机制通过参数化触发实现高效分布式处理，避免中心化协调开销
2026-06-26 13:49:52
326
原创 TCC实现逻辑
TCC分布式事务模式相比Seata的XA/AT更复杂，需手动实现三阶段逻辑： 实现复杂度高：需编写Try（预留资源）、Confirm（提交）、Cancel（回滚）三个方法，业务代码量激增（如转账场景需改动9处）； 边界问题处理： 幂等性：三阶段均需幂等设计（如事务状态表），避免重复扣款； 空回滚：Cancel可能在Try未执行时触发，需记录状态防误操作； 悬挂问题：Try延迟到达时需判断是否已Cancel； 可靠性保障：需定时任务补偿未完成的Confirm/Cancel，防止资源永久冻结；
2026-06-25 12:10:32
337
原创 微服务限流实战
限流技术实战指南（150字摘要） 限流用于应对突发流量（如秒杀QPS暴涨40倍）和恶意攻击，核心方案包括： Nginx限流：漏桶算法（limit_req控制速率，burst缓冲突发）和并发限制（limit_conn）； 网关限流：SpringCloud Gateway结合令牌桶算法（replenishRate填充速率+burstCapacity突发容量），支持IP/路径细粒度控制； 四大算法：固定窗口（简单但边界突刺）、滑动窗口（金融首选）、漏桶（流量整形）、令牌桶（秒杀蓄洪）。
2026-06-24 15:36:09
242
原创 连接泄漏问题分析
监控Threads_connected是否持续增长。 定位泄漏点： HikariCP：启用leak-detection-threshold，日志直接输出泄漏堆栈。 DBCP/Tomcat：配置remove-abandoned-timeout和log-abandoned，超时自动回收并打印日志。 通用方案： 检查MySQLprocesslist，识别长时间Sleep的连接。 封装DataSource手动记录未关闭连接的堆栈。修复代码：使用try-with-resources确保连接释放
2026-06-24 15:01:08
186
原创 JMeter初体验和坑分享
JMeter使用存在GUI配置和代码层两大痛点。GUI配置问题包括：关联配置繁琐（需多组件配合）、CSV参数化易错、执行顺序与界面排列不一致、.jmx文件版本管理困难。代码层问题主要有：JMeter API不直观（需记忆上下文变量）、Groovy脚本性能陷阱（如重复解析JSON）、异常处理机制缺失（需手动标记失败）。场景选择方案：简单请求用GUI配置，复杂逻辑用GUI+Groovy，高并发压测减少Groovy使用，特殊协议开发Java Sampler。核心原则是将JMeter作为配置工具，避免过度编程
2026-06-24 14:38:59
264
原创 JMeter使用心得
压测优化指南 网络抖动：跨机房延迟导致毛刺→同机房部署（延迟<1ms） JVM预热不足：未预热性能差3-5倍→压测前低负载运行10-15分钟 连接池瓶颈：默认配置易打满→按峰值调大（如HikariCP设为50） 缓存冷启动：空缓存RT差5倍→预先加载热点数据 GC抖动：高频STW→G1调优（MaxGCPauseMillis=100） 稳定压测五步法 基线法：取三轮中位数（偏差>10%阻断发布） 环境隔离：独立集群+数据库，避免干扰 健康检查：压测前确认CPU<30%、堆内存<60%，预置生产数据
2026-06-24 14:25:46
396
原创 SkyWalking实战应用
本文详细介绍了金融项目选择SkyWalking而非Zipkin的三大核心优势：零侵入探针、多语言统一视图和内置告警功能。文章深入解析了SkyWalking的核心组件OAP和JavaAgent的工作原理，并提供了完整的SpringBoot项目接入指南。针对生产环境，重点阐述了OAP高可用架构设计，通过Nginx负载均衡和Keepalived实现故障自动切换。最后通过真实案例展示了SkyWalking在慢查询定位、调用链追踪和自定义告警等方面的应用价值，并分析了性能影响及采样控制策略。
2026-06-24 13:35:17
332
原创 Feign + Hystrix 实现降级 + 熔断
本文对比分析了Feign整合不同容错组件的实现方案：1. 纯Feign仅支持降级（返回兜底数据），不支持熔断和自动恢复；2. Feign+Hystrix组合实现完整熔断降级机制（含线程隔离和限流），但Hystrix已停止维护；3. 新项目推荐Feign+Sentinel方案，支持流量控制、熔断降级、热点防护等5大功能。文章通过代码示例展示了各方案的配置方式，并指出Sentinel作为SpringCloud Alibaba主推组件，在功能性和维护性上更具优势，特别适合对高可用要求严格的新建系统。
2026-06-16 18:20:14
200
原创 Java NIO和Java AIO的区别
重点指出Java NIO基于epoll实现事件驱动，属于同步非阻塞模型，用户线程需主动查询I/O状态；而Java AIO才是真正的异步非阻塞，由操作系统内核主动回调。实际开发中，由于Linux平台AIO实现不成熟（性能不如epoll），主流高并发项目如Netty、Redis、Kafka等都采用NIO而非AIO。文章通过代码对比、性能分析和应用场景说明，强调NIO与AIO的核心区别在于同步/异步机制，并澄清了"epoll是回调但NIO仍属同步"的技术误区。
2026-06-16 18:09:31
361
原创 NIO的channel中什么是 fd（File Descriptor，文件描述符）
摘要： 文件描述符（fd）是Linux内核为每个打开的文件、网络连接或设备分配的非负整数ID，是I/O操作的核心句柄。关键点包括：1）fd是进程级资源，每个进程独立管理；2）所有I/O（文件、网络、设备等）均通过fd操作；3）fd数量有限（默认1024/进程），高并发需调整ulimit -n；4）Java NIO中，Channel本质是对fd的封装，Selector通过epoll管理fd集合实现高效事件驱动。NIO通过单线程轮询多路fd，避免BIO的线程爆炸问题，支撑高并发场景。
2026-06-15 17:03:30
184
原创 NIO 的 Channel 里有多个 BIO 吗？
NIO的Channel是操作系统内核级的文件描述符，支持非阻塞和双向通信，必须配合Buffer使用，并能注册到Selector实现多路复用。而BIO的Socket是JDK包装的用户态对象，只能单向阻塞通信，不支持多路复用。核心差异在于NIO通过一个Selector线程可管理上万个连接（基于epoll事件驱动），而BIO需要为每个连接创建独立线程。NIO的Channel类型包括FileChannel、SocketChannel等，它们共享同一个Selector，彼此无直接关联。
2026-06-15 16:57:30
321
原创 3 大 I/O 模型BIO / NIO / AIO
本文系统解析了三种I/O模型（BIO/NIO/AIO）的核心差异与实现原理：1. 模型本质：BIO（同步阻塞）采用线程挂起等待；NIO（同步非阻塞）通过多路复用实现，包含select/poll轮询和epoll事件驱动两种方式；AIO（异步非阻塞）基于操作系统回调通知。2. NIO核心：采用Selector多路复用器管理Channel通道，通过零拷贝、事件驱动等机制实现单线程处理万级连接，对比传统轮询具有更高性能和更低资源消耗。
2026-06-15 16:41:11
179
原创 CAP 定理：为什么不能同时实现 C、A、P？
CAP定理指出分布式系统无法同时满足一致性（C）、可用性（A）和分区容错性（P）。P是必选项（网络故障不可避免），因此需在C与A间权衡： CP系统（如ZooKeeper、HBase）：强一致，牺牲可用性（如选举期间不可用）。 AP系统（如Eureka、Cassandra）：高可用，接受最终一致（如主从延迟）。 CA系统实为单机（如MySQL单节点），非分布式。 关键结论：分布式场景下，P必须满足，C与A互斥；选型取决于业务需求（金融强一致选CP，高并发场景选AP）。记忆口诀："P必选，C和A二选一"。
2026-06-15 10:17:31
203
原创 Spring Cloud 5 大组件 · 单个服务开发顺序
详细介绍了微服务架构中五大核心组件的开发顺序与实现方法。开发顺序严格遵循：1）先搭建Eureka注册中心作为服务发现基础；2）通过Feign实现服务间远程调用；3）利用Ribbon进行负载均衡（集成于Feign）；4）使用Hystrix实现服务熔断降级；5）最后通过Gateway构建统一网关入口。文中提供了包括Eureka Server配置、Feign接口声明、Ribbon策略设置、Hystrix熔断机制以及Gateway路由规则等完整代码示例，并强调组件间的依赖关系，特别指出注册中心是其他组件运行的前提。
2026-06-14 11:27:32
221
原创 MYSQL RR 解决“脏读+不可重复读“和“幻读“的本质区别
摘要： MySQL的RR隔离级别通过MVCC机制复用ReadView，确保事务内快照读的一致性，既解决了单行不可重复读（值变化），也解决了范围幻读（行数变化），本质都是“看不到其他事务的新数据”。标准SQL定义中RR不解决幻读，但InnoDB通过MVCC（快照读）和Next-Key Lock（当前读）双重机制突破标准，几乎消除幻读。实际应用中，如MOVA报表需RR保证数据一致性，而mpvs关键时点则用RC获取最新数据。核心口诀：“MVCC一箭双雕，Next-Key锁防插入；单行不可重复读，范围幻读同根源。”
2026-06-12 16:16:43
179
原创 缓存延迟双删的两种策略
摘要：比较两种缓存更新策略，策略A（先删缓存→更新DB→延迟再删）能有效解决并发读在删除和更新DB之间导致的脏数据问题，通过延迟删除清理缓存。策略B（先更新DB→删缓存→延迟删）依赖DB更新后直接读取新值，但延迟删除冗余。分析表明策略A是标准方案，因其明确阻断旧值回填；策略B虽简化但适用范围有限，需理解其前提条件。结论推荐策略A作为延迟双删的标准实现。
2026-06-12 15:02:29
233
原创 分布式锁 5 种实现
本文介绍了分布式锁的几种实现方案及对比。主要内容包括：1）MySQL分布式锁通过唯一索引实现，简单但性能差；2）Redis基础方案使用SETNX+EX，存在误删锁等问题；3）Redisson提供完整解决方案，支持可重入、自动续期、读写锁等特性；4）ZK实现强一致但性能较差；5）RedLock红锁适合金融等高一致性场景。综合比较，Redisson在性能、功能和易用性上表现最佳，是多数场景的首选方案，而MySQL方案适合小流量场景，ZK和RedLock适用于特定强一致需求。
2026-06-12 14:53:38
354
原创 Redis 3 大问题 + 5 大扩展问题
Redis三大经典问题与解决方案 Redis常见三大问题包括：1.雪崩（大量key同时过期导致DB压力），解决方案为过期时间加随机值+多级缓存；2.穿透（恶意查询不存在key），采用空值缓存+布隆过滤器拦截；3.击穿（热点key失效），通过分布式锁+逻辑过期解决。集群模式推荐：小数据用Sentinel，大数据用Cluster。双写一致性方案包含Cache Aside模式、延迟双删和Binlog同步。大Key需拆分压缩，热Key采用本地缓存+多副本。项目实践中组合使用布隆过滤器、多级缓存和分布式锁可有效应对
2026-06-12 14:19:14
229
原创 Spring 3 级缓存解决循环依赖
摘要：Spring通过三级缓存机制解决循环依赖问题： 三级缓存结构： 一级缓存（singletonObjects）存储完整Bean 二级缓存（earlySingletonObjects）存储半成品Bean（已实例化未初始化） 三级缓存（singletonFactories）存储ObjectFactory，动态生成早期引用（支持AOP代理） 核心流程： 实例化A → 暴露ObjectFactory到三级缓存 → 注入B时触发B的创建 → B通过ObjectFactory获取A的代理/原始对象 → 完成依赖注入
2026-06-11 12:03:54
344
原创 broker和exchange/queue的区别
RabbitMQ核心组件解析：Broker是RabbitMQ服务进程（类比快递公司），管理连接、队列等；Exchange是路由中心（类比分拣中心），根据规则将消息分发至对应Queue；Queue是消息存储队列（类比仓库），供消费者获取。三者协作流程：生产者→Broker→Exchange（按路由键）→Queue→消费者。常见问题包括未绑定Exchange导致消息无法接收、消费者未及时启动等。关键区别：Broker是整体服务，Exchange处理路由，Queue负责存储，通过Binding建立关联关系。
2026-06-11 11:04:07
177
原创 Spring Bean 生命周期
Spring Bean生命周期详解 摘要： Spring Bean生命周期包含四大阶段：1)Bean定义阶段（扫描注解生成BeanDefinition）；2)实例化阶段（通过构造方法创建对象，此时依赖未注入）；3)初始化阶段（依赖注入→Aware接口回调→BeanPostProcessor前置处理→初始化方法→BeanPostProcessor后置处理生成AOP代理）；4)销毁阶段。关键点包括：构造方法与初始化方法分离、AOP代理在BeanPostProcessor#after阶段生成、三级缓存解决循环依赖
2026-06-11 10:52:29
378
原创 Spring Boot 2.0 改 CGLIB 后，接口实现是否有影响
直接new对象（如OrderService self = new OrderService()），绕过容器导致事务/拦截失效，CGLIB因类型兼容更易误用； 强制类型转换到具体类，CGLIB代理虽能强转成功（继承实现类），但可能混淆代理逻辑（如super调用绕过增强）； 混用自定义JDK代理（如Proxy.newProxyInstance）与Spring管理的CGLIB代理，行为可能不一致。 原因：CGLIB无需接口、性能优化，但需警惕final/private限制。核心口诀：避免手动实例化、慎用强转
2026-06-10 12:03:31
190
原创 CGLIB 代理 vs JDK 代理：能解决哪些事务失效问题？
摘要：JDK动态代理基于接口实现，只能代理public方法；CGLIB通过继承方式能代理private/protected方法，但无法代理final/static方法。SpringBoot 2.x+默认使用CGLIB代理。CGLIB主要解决"方法可见性"问题，对于事务失效的核心问题（异常处理、this调用等）仍需通过手动回滚、配置rollbackFor、注入self等方式解决。关键结论：调整代码逻辑才是解决事务失效的根本，不能仅依赖代理方式。
2026-06-10 11:38:25
289
原创 Spring事务失效的场景
Spring事务失效三大核心原因：1)异常被捕获未抛出导致不回滚；2)检查异常未配置rollbackFor；3)private/final/static方法或同类this调用导致代理失效。记忆口诀：异常吞没、检查遗漏、非公代理。事务传播机制包含7种行为，如REQUIRED（默认）、REQUIRES_NEW等。@Transactional原理基于AOP代理，通过拦截器链管理事务生命周期。排查失效问题需重点关注异常处理、方法修饰符、同类调用等5个关键点。
2026-06-10 11:25:34
183
原创 prototype 注入到 singleton 里，prototype是否还是线程安全的
Spring中prototype作用域的Bean自身是线程安全的，因为每次获取都是独立实例。但注入到singleton时存在“陷阱”：若未配置proxyMode或@Lazy，会导致所有线程共享同一个prototype实例，引发线程不安全。解决方案包括： @Scope(proxyMode=TARGET_CLASS)：通过代理确保每次调用生成新实例； @Lazy：延迟注入代理对象； ObjectProvider：显式调用getObject()获取新实例。 典型场景如异步任务或高并发报表生成，需避免“假多例”问题
2026-06-10 09:03:53
235
原创 Spring 单例 Bean 是线程安全的吗？
摘要： Spring单例Bean的线程安全取决于其状态：无状态Bean（如Service/DAO）因无可变成员变量而天然线程安全；有状态Bean需开发者自行处理同步问题，常用方案包括：@Scope("prototype")：每次注入新实例，但牺牲性能； ThreadLocal（如金融项目中的用户上下文）； 并发工具类（AtomicXxx/ConcurrentHashMap）； 加锁（性能较差）。 Spring不封装多线程，原因包括性能损耗、设计哲学及业务差异。
2026-06-10 08:58:16
359
原创 Exchange 挂了会怎样？
本文分析了RabbitMQ中broker组件故障的影响及应对措施。Exchange作为路由元数据，故障时仅导致消息路由失败，重建即可恢复；而普通Queue（Classic Queue）故障会导致消息永久丢失，即使配置持久化也无法避免单点风险。生产环境推荐使用基于Raft协议的Quorum Queue实现多节点复制，或采用更强健的Stream（追加日志）模式。金融级场景需特别注意：Exchange需声明为durable并幂等重建，队列必须使用Quorum/Stream类型，通过多副本机制保障数据不丢失。
2026-06-09 15:33:41
277
原创 手动删除queue中的消息，用Quorum或Stream能防护吗
RabbitMQ无法按ID删除单条消息，这是AMQP协议的设计限制。Quorum Queue和Stream只能通过Raft/日志复制实现批量删除（清空队列或删除队列），这些删除操作会同步到所有节点且不可逆。它们主要解决节点故障时的消息不丢失问题，而非防护管理员误操作。真正的防护措施在于：严格控制队列删除权限、关键消息落库备份、操作日志审计。Stream的Replay功能仅适用于消费者断连恢复，无法恢复被Purge删除的消息。
2026-06-09 15:28:36
275
原创 【RabbitMQ】消息丢失的 6 大场景及解决方案
RabbitMQ消息传递存在4个关键丢失环节：生产端到Broker、Broker内存崩溃、Broker到消费端、消费端处理失败。解决方案包括：1）生产端启用PublisherConfirms+消息持久化；2）Broker端使用QuorumQueue多副本+队列持久化；3）消费端关闭autoAck，业务处理完成才手动ACK；4）消费端实现幂等处理（唯一键/Redis去重）。金融场景需特别注意：配置DLQ监控告警，惰性队列限制长度，版本兼容性检查。完整方案需组合持久化、确认机制和异常处理，确保消息不丢失、不重复
2026-06-09 14:57:19
448
原创 MySQL执行计划工具EXPLAIN
本文详细解析了MySQL执行计划工具EXPLAIN中的type字段，重点介绍其7个性能等级及其在金融项目中的优化实践。文章首先通过一个生产环境慢SQL案例（从12秒优化到200ms）说明EXPLAIN的重要性，随后系统讲解type的7个等级（从最优的system到最差的ALL），并结合金融业务场景分析每个等级的特点和优化方向。针对金融项目，作者提出调优优先级：消除ALL＞提升ref到const/eq_ref＞缩小range范围＞避免index扫描，并给出具体优化步骤和SQL改写示例。
2026-06-09 10:59:06
303
VisualStudio_Community安装，Microsoft Visual C++ 14.0 is required问题解决方案
2020-12-16
win10、7下安装hadoop，解决依赖性问题文件，直接合并bin文件
2019-04-29
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人