小工匠

核心通信架构： “动态代理 + 全异步 + 同步语义包装”的设计。 通信架构需要解决分布式系统中最核心的问题：> **如何在保证高性能（异步非阻塞）的同时，提供简单易用的同步调用接口？**- **调度器端**：通过动态代理 + Future 阻塞，让 `executorBiz.run()` 看起来像本地同步调用。- **执行器端**：通过 Netty + 阻塞队列 + 独立消费线程，实现全异步处理。- **通信层**：基于 `HTTP + requestId` 匹配

本文系统介绍了高并发系统架构设计的方法论与关键技术方案。高并发系统面临资源需求与供给的核心矛盾，解决方案包括垂直伸缩（提升单机性能）和水平伸缩（分布式集群扩展）。水平伸缩凭借其无限扩展性、成本效益和弹性优势成为主流方法。文章重点阐述了三种关键技术：分布式应用（通过负载均衡分散请求）、分布式缓存（内存存储热点数据）和分布式消息队列（缓冲突发写操作）。通过典型案例（如电商大促、微博热点）展示了这些技术如何在实际场景中解决高并发挑战，确保系统稳定高效运行。

本文探讨了线上服务稳定性监控的关键指标体系，分为服务器监控和系统运行指标（JVM监控）两大类。通过Java代码示例展示了如何获取CPU、内存、磁盘等服务器指标，并详细介绍了JVM线程监控和GC监控的实现方法。文章强调了监控对预防系统故障的重要性，提供了实用的阈值配置建议，帮助开发者构建更健壮的监控体系，确保系统稳定运行和业务连续性。

摘要：本文探讨了高并发系统中的服务降级与熔断机制。降级是在资源紧张时放弃非核心功能以保障核心业务，适用于电商大促等场景，通过Sentinel等工具实现动态开关控制。熔断则是对下游服务异常的保护，通过状态机（关闭/开启/半开）自动切断异常调用，防止系统雪崩。两者区别在于：降级关注系统整体负载，熔断针对服务间调用链。文章提供了基于Sentinel的代码实现示例，包括配置规则和业务逻辑，并对比了主流框架特性，为构建高可用分布式系统提供了实用方案。

本文介绍了分布式系统中常见的限流算法及其实现。首先阐述了限流的重要性，它能保护核心服务、防止资源耗尽、维持系统稳定性。然后详细讲解了两种主流限流算法：计数器法（固定窗口算法）通过统计单位时间内的请求数量实现限流控制，但存在临界问题；令牌桶算法则允许一定流量突发，更适合实际业务场景。文章提供了完整的Java代码实现，包括线程安全的计数器限流器和基于Guava的令牌桶实现，并附有使用示例和注意事项。这些限流技术可有效应对突发流量或恶意攻击，保障系统高可用性。

高并发场景下的库存超卖问题及其解决方案 在高并发场景下，库存超卖是典型的技术挑战，表现为实际下单量远超库存量。其根本原因是并发控制缺失导致的竞态条件问题。本文提出了两种解决方案： 数据库悲观锁：通过SELECT FOR UPDATE加锁，实现简单但性能较差，容易造成连接池耗尽。 Redis分布式锁：利用SETNX命令实现应用层锁，性能更优但需注意死锁问题。改进版采用Lua脚本保证锁操作的原子性，避免业务执行超时导致的并发问题。 两种方案各有优缺点，实际应用中需根据业务场景和性能需求进行选择。

本文探讨了高并发系统中缓存面临的三大核心问题及解决方案。针对缓存雪崩问题，提出了随机过期时间和二级缓存策略；对于缓存穿透问题，介绍了空值缓存和布隆过滤器两种防范方法；关于缓存一致性问题，分析了双写模式和删除策略的优劣。文章通过具体代码示例，展示了如何在实际开发中应用这些解决方案，为构建高性能、高可用的缓存系统提供了实用指导。

Redis缓存高可用方案解析 本文探讨了Redis高可用的三种主流实现方案。首先分析了缓存高可用的必要性，指出单点故障会导致数据库压力剧增和系统崩溃风险。随后详细介绍了三种解决方案： 主从复制方案：通过"一主多从"架构实现数据备份和读写分离，但需要手动故障转移 Sentinel方案：官方推荐的自动故障转移方案，具备监控、通知和自动主从切换能力 集群方案：通过数据分片实现水平扩展，同时支持自动故障转移 文章重点阐述了主从复制的实现原理、配置步骤和Java读写分离实现代码，并比较了各方案的适

摘要： 一致性哈希算法解决了分布式缓存系统中节点动态增减导致的大规模数据迁移问题。相比传统哈希取模方式，它通过哈希环模型（0~2^32-1）将节点和数据均匀分布，仅需重新映射少量数据（约1/n）。核心实现包括虚拟节点（解决数据倾斜）和顺时针查找机制（TreeMap.tailMap()高效定位）。Java代码示例展示了虚拟节点管理及数据路由逻辑，显著提升了系统伸缩性。典型场景下，节点宕机仅影响相邻区间数据迁移（如D节点数据迁移至A），而其他节点数据保持稳定。

本文深入探讨了缓存失效策略及其实现方案。首先介绍了三大核心策略体系：页面置换算法（FIFO、LRU、LFU）、Redis内存淘汰策略（如allkeys-lru）和过期策略（定时/惰性/定期）。随后重点讲解了LRU缓存的两种实现方式：基于LinkedHashMap的简化方案和基于双向链表+HashMap的完整实现。后者通过维护访问顺序的双向链表和快速查找的哈希表，达到了O(1)时间复杂度的读写操作。文章提供了详细的Java代码示例，包括节点结构设计、容量管理和访问顺序维护等关键实现细节，为构建高性能缓存系统提

高并发系统中的缓存三大问题及解决方案 缓存穿透、击穿和雪崩是影响高并发系统稳定性的三大关键问题。缓存穿透指恶意请求绕过缓存直接访问数据库，可通过布隆过滤器或缓存空对象解决；缓存击穿是热点数据失效导致大量请求直达数据库，可采用互斥锁或永不过期策略；缓存雪崩是大量缓存同时失效引发的数据库压力，可通过随机过期时间或多级缓存缓解。针对不同场景，需要结合具体业务特点选择合适的技术方案，如布隆过滤器适合判断数据不存在，而互斥锁适合保护热点数据重建过程。

本文系统梳理了分布式系统中的四大缓存层级，包括前端缓存、网络传输缓存、服务端缓存和数据库缓存。前端缓存通过浏览器存储和本地存储加速用户访问；网络传输层利用CDN和Nginx缓存静态资源；服务端缓存分为本地缓存（如Guava Cache）和分布式缓存（如Redis），适用于高频访问数据；数据库缓存（如MyBatis二级缓存）因一致性问题需谨慎使用。最佳实践建议根据场景选择合适的缓存技术，注意缓存更新策略和数据一致性。缓存设计需权衡性能与一致性，避免缓存穿透、雪崩等风险。

摘要： 本文围绕技术管理中的核心问题展开，从团队协作、事故处理到成员成长等维度提出方法论。 引导而非解答：资深工程师应通过提问引导新人自主解决问题，避免成为团队瓶颈，同时提升成员能力。 事故责任文化：追责应聚焦系统性改进（如“5 Why”分析），而非惩罚个人，以建立信任与学习型团队。 A/B测试原则：数据驱动决策，需注意样本公平性、多维度分析及结果收敛性，避免直觉误导。 成员成长策略：管理者需摆脱“静态思维”，通过授权与反馈帮助成员突破现有职级能力。 意见反馈技巧：提意见需注重时机、场合与方式，以“观察-影

摘要：本文探讨高并发系统中缓存一致性难题，重点分析四种主流方案：先更新数据库再更新缓存（存在缓存失败风险）、先删缓存再更新数据库（并发时可能缓存旧数据）、Cache Aside Pattern（推荐方案，先更新DB再删缓存）以及延迟双删策略（高一致性场景）。通过Java代码示例展示了每种方案的实现，指出Cache Aside Pattern因其轻量化、惰性加载和易失败处理的优势成为最佳实践，而延迟双删适用于对一致性要求极高的场景。文章强调缓存与数据库双系统间的原子性缺失是核心问题根源。

本文介绍了如何用Java实现一个生产级的Redis分布式锁，从基础实现到高级优化。首先分析了分布式锁必须满足的五大特性：互斥性、超时释放、可重入性、高性能高可用和安全性。然后逐步优化实现方案：从存在缺陷的SETNX基础版，到原子化SET命令改进版，最终通过Lua脚本实现安全的“谁加锁谁解锁”机制。最后针对Redis集群环境，提出RedLock算法解决异步复制导致的锁失效问题。文章提供了完整的Java代码示例，涵盖UUID生成、原子操作和Lua脚本等关键实现细节。

分布式锁技术对比分析 分布式锁是解决多服务实例并发访问共享资源的关键技术。主要实现方式包括： 数据库方案：利用唯一约束实现，实现简单但性能低，存在单点故障风险 Redis方案：基于SETNX命令，性能优异但需处理锁续约和过期问题 Zookeeper方案：通过临时顺序节点实现，可靠性高但性能相对较低 核心应用场景为电商秒杀等高并发业务，解决超卖问题。选择方案时需要权衡性能、可靠性和实现复杂度，Redis方案在大多数场景下是较优选择。

TCC（Try-Confirm-Cancel）是一种分布式事务模型，通过业务层面的两阶段提交解决微服务架构下的数据一致性问题。其核心分为Try阶段（资源预留）、Confirm阶段（提交操作）和Cancel阶段（回滚操作），需保证后两者的幂等性。相比传统2PC/XA，TCC具有更高性能（无长事务阻塞）和更细粒度控制（业务层面），但侵入性强，需改造业务代码。典型应用场景如电商支付流程（订单、库存、积分等操作）。开源框架如Tcc-transaction和Seata提供了TCC实现支持。TCC适合高并发场景，通过最

MySQL中的XA规范是两阶段提交（2PC）协议的重要实现，分为内部XA和外部XA两种形式。内部XA用于保障Binlog与Redo Log的一致性，通过XID关联事务状态，确保崩溃恢复时数据一致（以Binlog为准）。外部XA支持跨数据库实例的分布式事务，由应用层作为协调者，通过XA接口协调多个资源管理器。内部XA对开发者透明，而外部XA需要显式调用XA接口实现跨库事务管理，两者共同确保MySQL在分布式场景下的数据一致性。

摘要： 两阶段提交（2PC）和三阶段提交（3PC）是分布式系统中保证数据一致性的核心协议。2PC通过协调者分两阶段（准备与提交）管理事务，但存在同步阻塞、单点故障和数据不一致风险。3PC在2PC基础上引入超时机制，将准备阶段拆分为CanCommit和PreCommit阶段，减少阻塞并提升容错性。文章通过Java代码示例展示了2PC的实现逻辑，并对比分析了两种协议的优缺点，为理解分布式事务提供了实践参考。

本文介绍了分布式事务在微服务架构中的重要性，并以电商下单场景为例，详细讲解了基于本地消息表的最终一致性解决方案。文章首先通过伪代码展示了典型分布式事务问题，然后对比了主流分布式事务方案，重点实现了基于本地消息表+消息队列的技术方案。该方案通过本地事务保证原子性，利用消息队列和补偿机制确保最终一致性，包含完整的Java代码示例、数据库表设计和系统时序图，具有高可用、高性能的特点，是电商等分布式系统的理想选择。

文章摘要：限流是保障高并发系统稳定的核心手段。本文深入解析四大主流限流算法：计数器算法简单直接但存在临界问题；滑动窗口算法通过细分时间窗口解决临界问题；漏桶和令牌桶算法提供更精细的流量控制。重点剖析了计数器算法的实现代码及缺陷，并对比了固定窗口与滑动窗口的特性差异。这些算法各有适用场景，合理选择能有效应对突发流量，防止系统过载，是构建高可用架构的关键技术。

摘要：频繁FullGC问题本质是架构缺陷在内存层面的表现，而非单纯的JVM参数问题。本文提出架构师应建立四层思维模型：业务层关注流量与数据规模、架构层优化组件设计、JVM层合理配置、代码层规范内存使用。通过缓存架构优化（分片+字段裁剪）、数据流改造（游标/分页处理）等架构级方案，从根源预防FullGC。强调建立数据驱动的监控体系，通过业务指标、JVM指标、资源指标的三维联动，实现精准根因定位与优化效果验证。优秀架构师的价值在于通过系统化设计避免FullGC发生，

文章探讨了生产环境中系统在高并发、高负载及故障场景下的稳定性、性能与可用性等非功能需求。重点分析了“三高”指标（高可用性、高并发能力、高性能）及其计算方法。通过内部因素（技术栈、硬件配置、机房环境等）和外部因素（用户规模、访问模式、业务特点等）的综合评估，确保系统在极端场景下的韧性。文章还提供了具体的指标计算示例和优化手段，强调在设计中合理定义目标并预留余量，通过压测验证系统性能，平衡成本与可用性。

本文深入探讨了“热点扣减”场景下的流量削峰与架构优化策略，特别是在秒杀场景中的应用。首先，文章对比了热点扣减与热点查询的本质区别，指出热点扣减必须处理写请求，且需保证数据一致性和避免超卖。接着，文章详细介绍了多层次的流量削峰策略，包括恶意用户拦截、单机与集中式限流、权重等级调度、固定比例过滤、兜底降级和无货前置拦截等。此外，文章还提出了水平扩展架构升级方案，通过库存分片与轮询路由来分散压力。最后，文章总结了前端CDN加速、业务隔离和部署隔离等其他应对手段，为构建高并发、高可用的秒杀系统提供了全面的解决方案。

本文探讨了如何设计高可用的异步任务架构，以解决无状态存储集群数据同步中的任务积压和单点故障问题。首先，文章分析了简单实现中的扩展性差和单点风险，随后提出了分布式无主架构的解决方案。该架构通过多实例并发、自助协调分区、Watch机制和一致性Hash环分区，实现了任务的高效执行和动态扩缩容。此外，文章还详细介绍了扣减中的返还实现原则，包括扣减完成才能返还、一次扣减可以多次返还以及返还总数量要小于等于原始扣减数量。通过这些设计和原则，可以有效提升系统的性能和可靠性。

文章探讨了系统重构的时机与实施策略，重点分析了从纯代码重构到中台化演进的各个阶段。首先，判断重构时机的关键在于系统性能瓶颈、维护成本增加及监控缺失等问题。纯代码重构适用于日志序列化、监控缺失等场景，强调拆分超长类/方法、遵循SOLID原则及引入监控工具。当系统需承载更高流量时，可通过数据库到缓存或ElasticSearch的存储重构来优化性能。烟囱式架构向平台化演进的核心在于模块融合与兼容设计，最终形成可复用的平台模块，降低运维成本。平台化进一步发展为中台化，通过业务可视化和配置化实现业务复用，满足快速上线

微服务升级重构是解决历史遗留问题、提升系统性能的重要手段。重构形式主要分为纯代码式升级和含存储式升级。纯代码式升级仅修复业务代码问题，流程简单；含存储式升级则涉及存储层的改造，如读写分离或表结构优化。切换策略包括全量替换和灰度发布，后者通过逐步放量降低风险。含存储重构的架构设计强调不停服切换，通过数据同步模块实现历史与实时数据的迁移，并通过自动化工具进行数据对比验证。用户灰度切换策略则依据用户特征和功能使用度分批上线，确保系统稳定性。整体方案展现了技术方案的体系化和互联性，旨在实现用户无感知、低Bug的升级

在后台架构中，压测是发现性能瓶颈和评估流量极限的必备手段。但很多团队的压测往往因**模拟参数不真实**或**场景与线上不一致**而产生失真，导致拿不到可信的容量指标。接下来我们将介绍 **如何构建贴合生产流量的高保真压测**，并基于结果做出准确的容量规划与限流策略。

我们以“防备上游、做好自己、怀疑下游”的准则，分别从系统设计、部署和代码层面，介绍了如何构建高可用后台系统。但再完善的防护也难保万无一失，真正的挑战在于在用户感知之前，第一时间发现问题。接下来我们将从**监控**的角度出发，教你如何设计微服务监控，帮助快速、自动地暴露故障，保障系统稳定运行。

围绕“怀疑下游”原则，介绍了针对 RPC 服务、数据库和消息中间件的治理要点；并通过“本地任务表＋异步补偿”方案，演示了无需框架的分布式事务落地路径。 希望能提供一些帮助和思路。

我们以“CPU 被打满”故障为例，展示了高效的定位方法，并从部署层面（双机房、单元化、隔离）与代码层面（日志、循环、缓存）提出多种防护策略。通过这些“做好自己”的手段，可以大幅降低微服务线上故障发生概率。，并深入探讨了“防备上游”的必要性及具体手段。接下来将聚焦“做好自己”，即如何从自身设计和编码层面，预防和减少服务故障发生的概率。线上环境中，“CPU 飙升”是最常见的性能异常面试高频题。结合配置中心，实现线上动态调节日志级别，无需重启。

微服务是指通过语言无关协议（如 HTTP、ProtoBuf）向外提供业务服务的独立进程，具有小规模、异步通信、独立部署及自动化构建分发能力。

我们通过缓存和数据库结合的方式，实现了一个更加可靠的扣减方案。相比纯缓存方案，即使使用了无状态的分库存储，它的性能也会有一定的损耗。但此方案的好处在于数据更精准、更可靠。对于类似额度扣减、实物库存扣减等场景，此方案均适用。而对于一些虚拟的次数限制，同时业务上能够容忍在一定概率下数据不准确的场景，也可以选择纯缓存的扣减方案。优点利用顺序写插入优化性能；事务保证任务记录严谨，容灾可回滚；Redis 提供快速读写，最终一致性有保障。缺点系统整体更复杂；Worker 同步存在延迟。适用场景。

在批量扣减场景下，一条 SQL 对应一个 SKU，每次扣减都需要检查返回结果，一旦一个失败，就要整体回滚。而高并发下，多个用户争抢一个 SKU，又容易引发行级锁争用，甚至死锁，进一步导致性能雪崩。若将 Redis 换成 Cluster 模式，数据会根据 key 的哈希槽（0–16383）分布到多个节点上，单实例 Lua 脚本的“多 key 原子”假设将不再成立，需要进行方案演化。部分计算槽，这样所有本次扣减相关 key 均落在同一槽，单次 EVAL 能覆盖多个 SKU，实现原子批量扣减。

对于并发量级可达万级以上的场景，需要考虑分布式锁、Redis、消息队列、甚至专门的限流和秒杀架构，后续将详细阐述。（如库存、可用次数、账户金额等）进行。读写基于不同存储的架构图。读写分离的扣减架构图。

方案一：异构定制化 —— Binlog 同步到定制化存储；方案二：分库网关多库并发扫描；方案三：基于 ElasticSearch 的实时检索；深翻页与游标分页；各方案优缺点对比与适用场景；

依赖并行化：减少不必要的串行调用；依赖后置化：剥离非实时业务至异步 Worker；精细超时：基于 TP99/Max 定义超时，避免线程阻塞；重试策略：只对幂等读接口做一次重试；业务降级：结合缓存、标记与异步补偿，保障核心写链路可用。通过以上手段，无论外部依赖性能抖动或局部故障，写服务均能保持高可用与可观察性——这正是支撑海量写业务供应链的关键！

是否一定需要进行分表或者分库呢？不一定。虽然很多互联网公司的体量很大，用户非常多，但你千万不要被这些现象迷惑了。实际上，90% 以上的系统能够发展到上百万、上千万数据量已经很不错了。对于千万的数据量，开源的 MySQL 都可以很好地应对，更别说一些商业数据库了。另外，当数据增长到一定量级后，可以在业务层面做一些处理。比如根据业务特点，对无效数据、软删除数据，以及业务上不会再查询的数据进行统一归档，这也是一个成本低、效果明显的方式了。如果真的要，请遵循一下原则优先分表，容量不足再考虑分库；

然而，在这一过程中，容易被忽略的一环就是“测试回归”。接下来我们将从实际落地角度，系统性地介绍一种支持读服务快速升级、业务稳定推进的「自动化测试回归系统架构」方案，构建一套覆盖全量场景、支持自助回归的自动化测试体系。三大模块的组合，读服务的测试回归过程实现了自动化、精细化、可视化，彻底摆脱“人工全量测试回归”的低效流程，极大地提升了系统重构与业务迭代的安全性与效率。数据回放模块模拟用户请求，通过原始日志数据中的入参信息，重放请求以获得当前版本的响应数据。手动触发后，分别调用新旧版本，实时比较返回数据。

热点查询：对同一数据项发生极高频率的重复读取。社交媒体热点内容（某条微博、热搜话题）。电商秒杀商品详情持续刷新。网站排行榜页／直播间房间信息。这些场景下，同一个 Key 的请求会被路由到同一缓存分片或服务实例，导致“集中过载”。单一用户百万 QPS 需额外考虑热点路由压力；主从复制简单易行但资源浪费；应用内前置缓存从四大维度（容量、刷新、逃逸、发现）精细打磨；限流降级是最后的安全阀；前端与接入层也可层层加固。