小工匠

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

本文深入探讨了“热点扣减”场景下的流量削峰与架构优化策略，特别是在秒杀场景中的应用。首先，文章对比了热点扣减与热点查询的本质区别，指出热点扣减必须处理写请求，且需保证数据一致性和避免超卖。接着，文章详细介绍了多层次的流量削峰策略，包括恶意用户拦截、单机与集中式限流、权重等级调度、固定比例过滤、兜底降级和无货前置拦截等。此外，文章还提出了水平扩展架构升级方案，通过库存分片与轮询路由来分散压力。最后，文章总结了前端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 需额外考虑热点路由压力；主从复制简单易行但资源浪费；应用内前置缓存从四大维度（容量、刷新、逃逸、发现）精细打磨；限流降级是最后的安全阀；前端与接入层也可层层加固。

延迟——链路中的每一跳都要监控与优化；格式——row/mixed 模式下解析最简单可靠；消费——利用 MQ 分区或锁机制保证“高吞吐+强有序”；结构——Hash 优于 KV，可局部更新、同分片；一致性——数据对比与主动写入互补兜底。

全量缓存即在缓存中保留数据库中所有需要高性能读取的数据，并不设置过期。其架构示意如下：读流程：所有读请求只访问缓存，零数据库依赖 → 毛刺消失；写流程：写入数据库后，需确保同样更新至缓存；这实现了平均延迟可控在 100 ms 内的目标，但对缓存更新一致性提出了更高要求，也带来了新的技术挑战。全量缓存彻底消除毛刺，依赖 Binlog 保证数据最终一致；同时需在系统复杂度与资源成本之间做平衡，并可结合压缩、筛选与异步校准等措施优化；进阶可进一步利用机房热备和并行化提升性能与可用性。

两大原则：架构不分层、代码简单。懒加载四大问题：穿透、雪崩、实时性、毛刺。

* **前台 vs. 后台**：前台（iOS/Android/M 页/PC）负责与用户交互，展示内容；后台负责真正存储、处理和返回数据。* **不含数据中台与算法中台**：数据中台（BI、大数据）不直接对外部请求提供服务；算法研究仅负责模型调优，并由后台系统调用。

软件工程是一门关于“大规模、持续变化的软件系统如何高效、可控地构建与演进”的学科。它不仅关注单次项目的交付，更注重整个系统生命周期内的迭代、质量与成本管理。在高度复杂与不确定的环境中，建立和优化流程、方法与工具；在满足用户需求的前提下，实现按时、按质、可维护的交付；持续管控成本、风险与质量，并在系统全周期中不断迭代改进。

方案描述一致性推荐度1️⃣ 先更新缓存，再更新DB易回滚问题❌ 差❌ 不推荐2️⃣ 先删缓存，再更新DB旧数据问题❌ 差❌ 不推荐3️⃣ 先更新DB，再更新缓存并发问题⚠️ 一般❌ 不推荐4️⃣ 先更新DB，再删缓存较可靠✅ 较好⭐ 推荐5️⃣延迟双删最可靠✅ 最佳⭐⭐⭐最佳高可用核心：分片扩展写、冗余保障读、自动Failover。监控关键点：命中率、内存、慢查询、延迟。工具选型快速上手：RedisLive。

但是如果出现网络抖动、服务超负荷或者数据库超负荷等情况，整个处理链条有可能在步骤二失败，这时数据就会变成 a2、b1、c1，当然也有可能在步骤三失败，最终数据就会变成 a2、b2、c1，这样数据就对不上了，即数据不一致。图 3 中绿色代表成功的调用路径，如果中间出错，就会先调用相关服务的回退方法，再进行手工回退。因为一些服务出现错误，导致图 1 的步骤三失败，此时处理完请求后，数据就变成了 a2、 b2、c1，不过不要紧，我们只需保证最终数据是 a2、b2、 c2 就行。

场景是这样的：库存中只有 100 个商品，如果我们想把 TPS 控制在每秒 100 笔，将滑动时间窗口设置为 1 秒就行，即被分成 10 个区间，每个区间 100 毫秒，此时就会出现在第 1 个 100ms 请求已经超出了 100 个的情况，也就是说商品已经被秒光。，且主要在网关层做限流操作。再结合上方在 1 秒内控制 100 个请求的例子，如果使用令牌桶算法，我们需要先把令牌的产生速率设置为 100/s，等待令牌的排队队列设为 0，这样就能够满足我们的秒杀限流的诉求了。

熔断机制是微服务架构的安全气囊快速失败：防止局部故障扩散优雅降级：保障核心链路可用性自适应恢复：动态探测依赖服务状态实践建议渐进式配置：先保守设置阈值，根据监控逐步调整降级兜底：所有远程调用必须定义 fallback 方法熔断分层：结合网关级熔断与服务级熔断通过深入理解 Hystrix 的设计原理与实际场景中的陷阱，开发者能够构建出真正健壮的微服务系统。尽管Hystrix已停止更新，其思想仍被等新一代框架继承，持续为分布式系统保驾护航。

Overridetry {通过SkyWalking的落地，我们实现了：✅ 请求全链路可视化追踪✅ 端到端性能分析✅ 异常请求快速定位与Service Mesh集成，实现更细粒度控制结合AIOps实现异常预测构建统一的观测平台（Metrics/Logs/Traces融合）微服务可观测性建设永无止境，选择适合当前阶段的工具，同时保持架构的开放性，才能在技术迭代中立于不败之地。

在面对海量实时数据处理挑战时，架构设计需要像搭积木一样精心选择每个组件。本方案通过本地日志+Kafka+Flink的三级架构，在数据可靠性、处理实时性和系统扩展性之间找到了最佳平衡点。随着业务发展，我们仍需持续优化窗口机制、完善监控体系，让数据真正成为驱动业务增长的核心引擎。

写缓存架构通过“缓冲削峰+异步落库”的设计，巧妙化解了瞬时高并发写入的难题。其核心在于权衡一致性、性能与成本，适用于营销活动、秒杀等短时高峰场景。后续我们将探讨如何结合消息队列（如Kafka）进一步优化异步处理流程，实现更高吞吐量的写场景支持。

缓存层设计是提升系统性能的关键手段，Redis凭借其数据结构、持久化与集群能力成为首选。通过合理的缓存策略、更新机制与高可用设计，可显著降低数据库压力。然而，架构没有银弹，需结合业务特点权衡一致性与性能，持续优化方能应对流量洪峰。

此时解决方案为主数据每次更新时，都更新上次更新时间 last_update_time，然后每个线程更新查询数据后，检查当前订单 A 的 last_update_time 是否跟线程刚开始获得的时间一样，且 NeedUpdateQueryData 是否等于 false，如果都满足的话，我们就将 NeedUpdateQueryData 改为 true，然后再做一次搬运。我们应该使用什么技术存储查询数据呢？MQ 的消费者获取信号后，先批量查询待更新的主数据，然后批量更新查询数据，更新完后查询数据的主数据标识。

冷库：存放不再修改的“终态数据”（如已完结的订单）。热库：存储仍需频繁操作的“活跃数据”（如待付款、待发货的订单）。通过将数据按生命周期分离，热库仅保留近期高频访问的数据，从而显著降低单库压力。

优秀的索引设计需要平衡查询效率与写入性能。优先考虑最常用查询模式单表索引不超过5个联合索引字段数不超过3个定期审查索引使用情况通过理解B+Tree的底层原理，结合执行计划分析与实际业务场景，开发者可以构建出高效的数据访问方案。记住：没有最好的索引，只有最适合业务场景的索引设计。

假设有 A 和 B 两个事务，在并发情况下，事务 A 先开始读取商品数据表中的数据，然后再执行更新操作，如果此时事务 A 还没有提交更新操作，但恰好事务 B 开始，然后也需要读取商品数据，此时事务 B 查询得到的是刚才事务 A 更新后的数据。换句话说，事务 A 操作数据库时，事务 B 只能排队等待，因此性能也最低。循环等待：可以靠按序申请资源来预防，也就是所谓的资源有序分配原则，让资源的申请和使用有线性顺序，申请的时候可以先申请资源序号小的，再申请资源序号大的，这样的线性化操作就自然就不存在循环了。

如果客户端将要执行的命令发送给集群中的一台服务器，那么这台服务器就会以日志的方式记录这条命令，然后将命令发送给集群内其他的服务，并记录在其他服务器的日志文件中，注意，只要保证各个服务器上的日志是相同的，并且各服务器都能以相同的顺序执行相同的命令的话，那么集群中的每个节点的执行结果也都会是一样的。，介于两者之间，事务线程不用等待所有的从库复制成功响应，只要一部分复制成功响应回来就行，比如一主二从的集群，只要数据成功复制到任意一个从库上，主库的事务线程就可以返回给客户端。所以这种方式不是 MySQL 特有的。

但它依然不能解决某一个业务的数据大量膨胀的问题，一旦系统中的某一个业务库的数据量剧增，比如商品系统接入了一个大客户的供应链，对于商品数据的存储需求量暴增，在这个时候，就要把数据拆分到多个数据库和数据表中，也就是对数据做水平拆分。单机性能总是有极限的，互联网分布式架构设计高并发终极解决方案还是水平扩展，所以结合业务的特性，就需要在 Range 的基础上引入“分片元数据”的概念：分片的规则记录在一张表里面，每次执行查询的时候，先去表里查一下要找的数据在哪个分片中。垂直拆分是根据数据的业务相关性进行拆分。

在等待抢购阶段，流量突增，因为在抢购商品之前（尤其是临近开始抢购之前的一分钟内），大部分用户会频繁刷新商品详情页，商品详情页面的读请求量剧增， 如果商品详情页面没有做好流量控制，就容易成为整个预约抢购系统中的性能瓶颈点。在商品抢购阶段，用户会点击提交订单，这时，抢购系统会先校验库存，当库存足够时，系统会先扣减库存，然后再生成订单。商品抢购：商品抢购倒计时结束，用户提交抢购订单，排队等待抢购结果，抢购成功后，扣减系统库存，生成抢购订单。订单支付：等待用户支付成功后，系统更新订单状态，通知用户购买成功。

分布式锁的选择需要综合业务场景、性能需求与运维能力。理解不同方案的实现原理和限制条件，才能设计出既保证数据一致性，又具备高可用的分布式系统。

基于 MQ 的可靠消息投递的可落地性，要抓住“双向确认”的核心原则，只要能实现生产端和消费端的双向确认，这个方案就是可落地了，又因为基于 MQ 来实现，所以天生具有业务解耦合流量削峰的优势。基于 2PC 的实现方案很少有实际的场景，但还是要掌握它的实现原理和存在的问题。最后，在实际工作中，并不是所有的业务对事务一致性的要求都那么高。因为更高的要求意味着更多的成本，这也是很多架构复杂度来源之一，所以要尽可能地站在业务实际场景的立足点来回答分布式事务问题。