- 博客(136)
- 资源 (10)
- 收藏
- 关注
RSS订阅原创 一个 Partition就是一个年级，一个消费者组占用1年级1班，另一个消费者组占用1年级2班，座位号（offset）可以相同，但班级号不同？
你的比喻中“班级不同”暗示数据被分割，实则错误——Kafka的Partition是同一份数据，多个Group（如读书会）可独立订阅并维护各自offset（书签），进度互不影响。正确类比应为：一本书（Partition）被多个读书会（Group）同时阅读，每会自有书签，非分数据，而是多订阅。offset是消费进度，非固定座位。关键：数据共享、进度独立。
2026-09-16 14:45:16
149
原创 1个 Partition 只能被 Group 内 1 个 Consumer 消费，Kafka 怎么保证并发的特性
Kafka的并发并非“单Partition多Consumer”，而是通过多Partition与多Consumer并行实现。每个Partition仅由一个Consumer处理，确保消息顺序；跨Partition无序，但可通过partitionkey（如orderId）固定路由，保障业务顺序。高并发需增加Partition数，而非尝试单Partition内并发——否则破坏顺序、引入锁开销，违背Kafka“分布式日志”设计哲学。本质：加Partition = 加并发，用partitionkey = 保顺序。
2026-09-16 14:12:39
187
原创 Kafka 架构介绍
该图展示Kafka集群中3个Broker节点如何分布管理Topic1（6 Partition）与Topic2（3 Partition，含副本）的架构。每个Broker负责多个Partition的Leader角色，实现水平扩展；通过颜色标识同一Partition的多副本（如蓝色P0在Broker1、Broker2），虚线箭头表示副本同步（ISR机制），体现数据一致性。两个ConsumerGroup订阅Topic2，因分区与消费者数量不匹配，出现1个消费者闲置或1个分区未被消费，直观呈现Kafka的集群特性
2026-09-16 14:02:46
490
原创 BeanFactory和BeanFactoryPostProcessors的区别
BeanFactory是生产Bean实例的工厂，管理Bean生命周期；BeanFactoryPostProcessor是工厂的“装修队”，在Bean创建前修改BeanDefinition。核心区别：作用对象不同（Bean实例 vs BeanDefinition）；执行时机不同（BeanFactoryPostProcessor在refresh()第5步，BeanFactory在第11步实例化Bean）；
2026-09-08 14:55:18
291
原创 BeanPostProcessor的核心作用
registerBeanPostProcessors是Spring refresh()的第6步，位于BeanFactory准备之后、Bean创建之前。它通过PostProcessorRegistrationDelegate找到所有BeanPostProcessor类型的Bean，按PriorityOrdered、Ordered、普通优先级依次注册到BeanFactory。这一步为后续Bean实例化装配好“质检员”，使@Autowired、AOP、@PostConstruct等注解和代理功能得以生效，是前哨站
2026-09-08 14:49:06
145
原创 ReentrantLock 与 AQS 完整学习手册
本文系统讲解ReentrantLock：从API用法（三种获取锁、公平性、Condition）到加锁原理（CAS抢锁→入队→自旋+park），再深入AQS框架（state、CLH队列、LockSupport，模板方法模式）。核心口诀：CAS抢锁，失败入队，自旋+park；AQS定流程，子类定细节。
2026-09-07 11:04:04
181
原创 自旋锁 vs 阻塞锁
自旋锁与阻塞锁：自旋锁拿不到锁时CPU空转，不停CAS，不放弃CPU，适合锁持有时间短；阻塞锁则挂起线程，让出CPU，靠OS唤醒，适合锁持有时间长。自旋开销是CPU空转和缓存失效，线程切换开销是内核态切换和缓存污染。Java中，Atomic类基于CAS自旋；synchronized采用自适应自旋；AQS混合自旋与阻塞。
2026-09-06 10:42:15
307
原创 Java 锁的 6 大分类维度
本文系统讲解Java锁的六大分类：乐观/悲观、公平/非公平、可重入/不可重入、独享/共享、可中断/不可中断、自旋/阻塞。重点详解ReentrantLock，它是JDK层可重入互斥锁，基于AQS，支持公平锁、可中断、超时、多Condition，比synchronized更灵活。简单并发用synchronized，复杂场景用ReentrantLock；二者性能在Java6+后相当。使用ReentrantLock务必在finally中释放，lock应放在try外。
2026-09-06 10:39:12
355
原创 mysql数据库，明明有索引为啥不用
摘要：MySQL全表扫描有时比走索引更高效，原因在于索引查询需要支付回表IO、随机IO和二级索引读取三笔成本，而全表扫描是顺序IO可预读。当回表次数N超过表大小T的1/200KB时，全表扫描更优。MySQL优化器基于成本（CBO）选择执行计划，但统计信息可能不准确。通过EXPLAIN可判断执行计划，修复方法按优先级包括：ANALYZE TABLE更新统计、优化SQL提高选择性、使用覆盖索引、业务层冷热分离。强制索引是最后手段，会限制优化器灵活性。
2026-08-11 23:24:02
308
原创 估值流程java深度版（BPMN + 5 元素 + 两阶段写）
本文以银行资产托管业务中的估值流程为核心，通过真实代码和项目实战经验，深入解析估值流程的设计要点和易错细节。关键点包括：1. 估值采用5元素BPMN直线流程，包含拉持仓、计算NAV（写PENDING记录）、风控复核、确认（写CONFIRMED记录）等核心环节；2. 强调两阶段写入机制的设计原因（合规要求）及实现方式；3. 指出operator字段和status字段的常见理解误区；4. 对比估值与对账流程的差异；5. 分析4个设计取舍点（如assignee模式选择等）；6. 提供5个典型面试问题的应对策略。
2026-08-05 17:59:25
338
原创 对账流程的 OGNL 变量完整数据流
本文概述了OGNL变量在业务流程中的6个关键传递环节，包括：1)Controller启动流程时传入全局变量；2)ServiceTask通过execution.setVariable设置变量；3)Gateway使用OGNL表达式读取变量进行条件判断；4)userTask通过OGNL动态分配处理人；5)ServiceTask读取变量执行业务操作；6)区分local与global变量的使用场景。文章提供了完整的数据流示例和实际代码实现，重点说明了OGNL表达式在条件分支中的应用，以及变量在流程节点间的传递机制
2026-07-31 20:23:37
298
原创 千万级用户画像系统实战
本文介绍了基于MongoDB构建"商户+客户+运营"一体化营销平台的实践经验。针对用户画像和商户标签200+维度的灵活组合需求，MongoDB的文档模型优势明显，相比关系型数据库避免了频繁Schema变更和多表JOIN问题。文章详细阐述了数据模型设计（嵌套文档结构）、分片策略（按userId哈希分片）、索引优化（嵌套字段索引）等核心方案，并对比了MySQL实现方式。通过实际案例展示了千万级数据下的性能优化手段（聚合管道优化、冷热分离等），以及MongoDB 7.0新特性应用
2026-07-31 20:15:11
325
原创 从 0 搭建千万级用户画像 SaaS（PostgreSQL + JSONB + Citus）
文章从技术选型、数据模型设计、SpringBoot工程化、Citus分片部署到实际业务场景应用进行了系统阐述，并提供了完整的GitHub代码实现。 核心亮点包括： 采用PostgreSQL JSONB实现灵活Schema，支持零停机加字段； 通过GIN索引和路径表达式索引实现查询性能44倍提升； 使用Citus分片支持亿级数据P99<200ms；创新性地将用户行为数据存储在JSONB数组中，通过SQL直接生成留存分析桑基图；设计模板化查询接口，使业务人员可自助完成复杂分析。该方案特别适合金融行业...
2026-07-29 15:26:51
336
原创 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
394
原创 Kafka vs RabbitMQ：高可用实现的核心差异
Kafka与RabbitMQ高可用机制对比摘要（140字）： Kafka采用分片复制（Partition+ISR）机制实现高可用，通过Leader/Follower副本和acks配置保障数据可靠性，吞吐量达百万级，适合日志流场景。RabbitMQ依赖镜像队列（MirrorQueue）进行主从复制，新版QuorumQueue基于Raft实现强一致，延迟低至微秒级，适合交易场景。核心差异在于架构基因：Kafka为分布式日志设计（分区存储+批量拉取），RabbitMQ是传统消息队列（内存缓冲+实时推送）。
2026-06-27 11:10:07
542
原创 kafka和rabbitmq的broker的组成差异
Kafka和RabbitMQ的核心架构对比：Kafka采用分区副本机制（Leader+Follower），基于JVM实现，依赖Zookeeper或KRaft协调，定位为高吞吐的分布式日志系统，适合日志流和事件源场景；RabbitMQ基于Erlang虚拟机，采用Exchange-Queue路由模型，支持多协议，属于消息队列路由器，更适合任务队列和灵活路由。两者设计哲学不同，Kafka侧重持久化有序日志，RabbitMQ强调消息分发能力。
2026-06-27 10:47:12
297
原创 gRPC和自定义TCP是不是都比http强
文章摘要：协议选择取决于使用场景。HTTP是通用协议，适合公网访问、浏览器调用和调试；gRPC/自定义TCP性能更优但兼容性差。内部系统可选用高效专用协议（如gRPC），对外接口宜采用通用HTTP协议。关键是根据实际需求权衡性能与兼容性，而非单纯追求底层协议。
2026-06-27 10:41:40
237
原创 Raft 为什么比 Kafka 更抗网络抖动
摘要： etcd与Kafka在抗抖动能力上存在本质差异。etcd基于Raft协议，适用于KB级元数据存储，采用同步复制和快速失败机制（抖动时立即选举新Leader），单次操作延迟低（<1ms），适合低延迟场景。Kafka处理MB级消息，依赖异步ISR复制和批量写入，抖动会导致ISR收缩、延迟累积甚至超时重试，设计更侧重高吞吐。核心区别在于数据量（小vs大）、同步模式（同步vs异步）及抖动响应策略（快速恢复vs延迟放大），因此etcd适合强一致性需求，Kafka则适合最终一致性高吞吐场景。
2026-06-26 19:07:01
292
原创 有仲裁机制了，为什么还要 Leader
摘要：分布式系统中，仲裁机制（如Raft、Quorum）确保数据安全性和故障容忍，而Leader机制解决决策效率问题。Leader作为协调中心，统一处理写入请求并同步到Followers，保证操作有序和一致性。没有Leader时，多节点协调复杂且可能导致数据不一致。Kafka的Partition Leader同理，确保分区写入顺序。简言之，仲裁保障数据安全，Leader提升决策效率，二者协同工作以维持系统稳定高效运行。
2026-06-26 18:59:02
134
原创 Kafka 为什么不用 Raft协议？
Raft作为强一致性协议，其串行写入、多数派确认等特性会严重限制吞吐量，而Kafka作为分布式日志系统，核心诉求是高吞吐（百万级/秒）和水平扩展（数千Partition）。通过副本因子、最小同步副本数和生产者ACK配置的组合，Kafka实现了"类Quorum"的弱一致性保障，在数据安全性与性能之间取得平衡。这种设计使Kafka在CAP定理中默认选择AP特性，但通过unclean.leader.election=false等配置可切换至CP模式。Kafka的ISR机制以可控的弱一致性为代价，换取到了高吞吐量
2026-06-26 18:44:28
434
原创 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
373
原创 XXL-Job 分片广播底层机制
XXL-Job分片广播机制通过调度中心逐个触发执行器节点，仅传递分片参数（shardIndex/shardTotal），由执行器本地完成数据过滤处理。其核心特点是：1）无数据跨节点传输，仅通过RPC触发；2）分片参数通过ThreadLocal传递，与任务生命周期绑定；3）与Elastic-Job等基于ZK协调的方案不同，采用去中心化设计，框架不介入数据分片过程。业务层可自行实现一致性hash等分片策略，但分片总数在任务启动时即固定，适合静态分片场景。该机制通过参数化触发实现高效分布式处理，避免中心化协调开销
2026-06-26 13:49:52
350
原创 TCC实现逻辑
TCC分布式事务模式相比Seata的XA/AT更复杂，需手动实现三阶段逻辑： 实现复杂度高：需编写Try（预留资源）、Confirm（提交）、Cancel（回滚）三个方法，业务代码量激增（如转账场景需改动9处）； 边界问题处理： 幂等性：三阶段均需幂等设计（如事务状态表），避免重复扣款； 空回滚：Cancel可能在Try未执行时触发，需记录状态防误操作； 悬挂问题：Try延迟到达时需判断是否已Cancel； 可靠性保障：需定时任务补偿未完成的Confirm/Cancel，防止资源永久冻结；
2026-06-25 12:10:32
352
原创 微服务限流实战
限流技术实战指南（150字摘要） 限流用于应对突发流量（如秒杀QPS暴涨40倍）和恶意攻击，核心方案包括： Nginx限流：漏桶算法（limit_req控制速率，burst缓冲突发）和并发限制（limit_conn）； 网关限流：SpringCloud Gateway结合令牌桶算法（replenishRate填充速率+burstCapacity突发容量），支持IP/路径细粒度控制； 四大算法：固定窗口（简单但边界突刺）、滑动窗口（金融首选）、漏桶（流量整形）、令牌桶（秒杀蓄洪）。
2026-06-24 15:36:09
263
原创 连接泄漏问题分析
监控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
200
原创 JMeter初体验和坑分享
JMeter使用存在GUI配置和代码层两大痛点。GUI配置问题包括：关联配置繁琐（需多组件配合）、CSV参数化易错、执行顺序与界面排列不一致、.jmx文件版本管理困难。代码层问题主要有：JMeter API不直观（需记忆上下文变量）、Groovy脚本性能陷阱（如重复解析JSON）、异常处理机制缺失（需手动标记失败）。场景选择方案：简单请求用GUI配置，复杂逻辑用GUI+Groovy，高并发压测减少Groovy使用，特殊协议开发Java Sampler。核心原则是将JMeter作为配置工具，避免过度编程
2026-06-24 14:38:59
275
原创 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
409
原创 SkyWalking实战应用
本文详细介绍了金融项目选择SkyWalking而非Zipkin的三大核心优势：零侵入探针、多语言统一视图和内置告警功能。文章深入解析了SkyWalking的核心组件OAP和JavaAgent的工作原理，并提供了完整的SpringBoot项目接入指南。针对生产环境，重点阐述了OAP高可用架构设计，通过Nginx负载均衡和Keepalived实现故障自动切换。最后通过真实案例展示了SkyWalking在慢查询定位、调用链追踪和自定义告警等方面的应用价值，并分析了性能影响及采样控制策略。
2026-06-24 13:35:17
355
原创 Feign + Hystrix 实现降级 + 熔断
本文对比分析了Feign整合不同容错组件的实现方案：1. 纯Feign仅支持降级（返回兜底数据），不支持熔断和自动恢复；2. Feign+Hystrix组合实现完整熔断降级机制（含线程隔离和限流），但Hystrix已停止维护；3. 新项目推荐Feign+Sentinel方案，支持流量控制、熔断降级、热点防护等5大功能。文章通过代码示例展示了各方案的配置方式，并指出Sentinel作为SpringCloud Alibaba主推组件，在功能性和维护性上更具优势，特别适合对高可用要求严格的新建系统。
2026-06-16 18:20:14
231
原创 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
391
原创 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
197
原创 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
349
原创 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
207
原创 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
225
原创 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
251
原创 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
194
原创 缓存延迟双删的两种策略
摘要：比较两种缓存更新策略，策略A（先删缓存→更新DB→延迟再删）能有效解决并发读在删除和更新DB之间导致的脏数据问题，通过延迟删除清理缓存。策略B（先更新DB→删缓存→延迟删）依赖DB更新后直接读取新值，但延迟删除冗余。分析表明策略A是标准方案，因其明确阻断旧值回填；策略B虽简化但适用范围有限，需理解其前提条件。结论推荐策略A作为延迟双删的标准实现。
2026-06-12 15:02:29
264
原创 分布式锁 5 种实现
本文介绍了分布式锁的几种实现方案及对比。主要内容包括：1）MySQL分布式锁通过唯一索引实现，简单但性能差；2）Redis基础方案使用SETNX+EX，存在误删锁等问题；3）Redisson提供完整解决方案，支持可重入、自动续期、读写锁等特性；4）ZK实现强一致但性能较差；5）RedLock红锁适合金融等高一致性场景。综合比较，Redisson在性能、功能和易用性上表现最佳，是多数场景的首选方案，而MySQL方案适合小流量场景，ZK和RedLock适用于特定强一致需求。
2026-06-12 14:53:38
368
VisualStudio_Community安装，Microsoft Visual C++ 14.0 is required问题解决方案
2020-12-16
win10、7下安装hadoop，解决依赖性问题文件，直接合并bin文件
2019-04-29
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人