小工匠

但是如果出现网络抖动、服务超负荷或者数据库超负荷等情况，整个处理链条有可能在步骤二失败，这时数据就会变成 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 的实现方案很少有实际的场景，但还是要掌握它的实现原理和存在的问题。最后，在实际工作中，并不是所有的业务对事务一致性的要求都那么高。因为更高的要求意味着更多的成本，这也是很多架构复杂度来源之一，所以要尽可能地站在业务实际场景的立足点来回答分布式事务问题。

分片选择：主用Range分片按类目划分，辅以一致性Hash处理非热点数据。热点处理：元数据服务动态路由，热点类目拆分为多个分片，结合缓存抗读压力。数据一致性：主从复制+Raft协议，确保强一致性；异地容灾采用异步复制+Gossip。元数据管理：ETCD集群存储分片信息，客户端缓存元数据减少延迟。此方案平衡了扩展性、一致性与可用性，灵活应对海量数据与业务热点，符合高并发场景需求。

CAP 理论指的是什么？C（Consistency）是数据一致性、A（Availability）是服务可用性、P（Partition tolerance）是分区容错性。C、A、P 只能同时满足两个目标，而由于在分布式系统中，P 是必须要保留的，所以要在 C 和 A 间进行取舍。假如要保证服务的可用性，就选择 AP 模型，而要保证一致性的话，就选择 CP 模型。

架构师思维的本质全局视角：在空间维度关注系统边界，在时间维度预见业务发展。问题驱动：技术方案必须解决主要矛盾（如案例中的高可用）。权衡思维：没有完美方案，只有最适合当前场景的决策。

那么应该怎么做呢？针对这样的问题，我们需要对原有系统进行合理的系统边界拆分，让研发人员有能力提速，来快速响应需求变化，这就要求架构师对业务领域和团队人员有足够的了解。在 20 世纪 60 年代，《人月神话》的作者就分析，软件复杂性来源于两点：本质复杂度和偶然复杂度。开发工具、开发框架、开发模式，以及高性能和高可用这些仅是偶然复杂性，

软件建模与设计文档是架构师的核心工具，通过UML图系统化表达设计意图，确保多方协作一致性。明确需求：用用例图、活动图梳理功能。规划架构：通过部署图、组件图定义技术方案。细化实现：类图、时序图指导开发。持续迭代：结合反馈优化模型与文档。

- **加载优化** - **减少HTTP请求**：合并文件（CSS/JS/图片雪碧图） - **资源缓存** - 强缓存：`Expires`（绝对时间）、`Cache-Control`（相对时间） - 协商缓存：`Last-Modified`/`If-Modified-Since`、`ETag` - **代码压缩**：JS/CSS压缩工具、Gzip传输 - **按需加载**：懒加载、滚动加载、Media Query - **图片压缩**：工具

一个高性能系统的架构需要在客户端请求、网络静态缓存（如CDN）、网络接入、业务逻辑、数据缓存以及数据存储方面进行优化。接下来我们主要从这些方面来介绍如何实现一个高性能的架构。不过在进入具体的优化内容之前，我们需要先了解一下系统的高性能指标。

ANSI/IEEE标准认为，架构是描述系统中各组件之间组合、交互和继承关系的抽象模型。维基百科则将架构定义为建筑物或物理结构规划设计的过程。虽然两个定义在具体表述上有所不同，但共同点在于都强调了“设计”与“整体布局”。这种抽象性虽然使得架构看起来概念模糊，但正是这种抽象为系统设计提供了足够的灵活性和前瞻性。

互联网应用架构的演化：从简单的单一系统架构到复杂的微服务架构和分布式数据库设计，架构的变化反映了业务的成长和技术的不断创新。分布式存储系统设计：通过合理的分区算法和高可用设计，Doris 展示了如何构建一个既高效又易于扩展的分布式存储系统。反应式编程框架设计：Flower 提供了一个易于使用的反应式编程框架，帮助开发者构建非阻塞、高吞吐量的系统。这三个案例从不同角度展现了架构设计的复杂性与灵活性，同时也为架构师提供了多样的架构设计思路。

网络安全不仅仅是技术的挑战，它需要从架构设计、开发实践到运维的全方位保障。采用先进的安全防护措施，能够显著提升系统的抗攻击能力，保护用户和企业的数据安全。

系统的高可用性不仅仅是技术架构的设计问题，还包括运维、测试和发布等多个环节。通过精心设计的架构策略，如负载均衡、数据库复制、消息队列隔离、限流降级以及异地多活架构，可以有效应对高并发和硬件故障等挑战。而通过自动化测试、自动化监控、预发布和灰度发布等运维手段，能够保障系统在变更和压力下始终保持高可用性。实现高可用系统是一个持续优化的过程，不仅需要技术的支撑，还需要团队的协作与实践。随着技术的不断发展，我们可以期待更高效、更智能的高可用架构和运维方案，提升用户体验，推动互联网应用的健康发展。

性能优化的前提和基础是性能测试，通过性能测试，了解系统的性能特性才能进行优化，而性能测试主要就是要测试出来系统的性能曲线，通过对性能曲线进行分析，了解系统的瓶颈点和系统资源消耗，再进行性能优化。性能优化的时候需要建立一个整体的思维，要从整体系统的层面去思考优化，而不只是仅仅关注自己的代码，或者是自己设计的架构。最上层的优化是硬件优化，包括骨干网络、数据中心服务器硬件这样的优化；然后是基础组件的性能优化，包括操作系统、虚拟机、应用中间件这几个方面；这之后才是架构的优化，包括核心的三板斧，缓存、异步和集群；

微服务架构通过将一个庞大的单体应用拆分成多个小型的独立服务来解决单体系统的问题。每个服务都可以独立开发、部署和扩展，系统的模块化程度和可复用性大大提高。微服务架构不仅提高了开发效率，还能降低系统耦合度，方便团队协作，降低发布和更新的复杂性。微服务架构通过将单体系统拆分为多个小型、独立的服务，解决了单体架构中的编译、部署、维护等问题。无论是Dubbo还是Spring Cloud，微服务框架都提供了强大的服务治理功能，简化了分布式系统的设计和实现。

分布式数据存储系统的设计需要在一致性、可用性和扩展性之间寻找最佳平衡点。通过合理运用复制技术、分片策略，结合NoSQL数据库的特性，可以构建出适应不同业务场景的高效存储架构。随着云原生技术的发展，未来分布式存储将更加智能化，但核心的CAP原理和基础架构设计原则仍将是指导我们进行技术选型和架构设计的基石。

消息队列不仅是技术组件，更是架构思维的体现。在微服务、云原生大行其道的今天，合理运用消息队列能够帮助架构师在系统弹性、可维护性和性能之间找到最佳平衡点。正如Martin Fowler所言：“分布式系统的复杂性不在于发送消息，而在于如何管理消息带来的不确定性。” 掌握消息队列的深层原理，方能设计出真正经得起考验的分布式系统。

缓存是系统性能优化中不可或缺的部分，它可以显著提高数据访问速度，减轻数据库负担，提升系统整体吞吐量。然而，缓存的合理使用需要考虑多个因素，如数据的一致性、频繁修改的数据以及热点数据的设计。在分布式环境中，通过一致性哈希和虚拟节点优化，可以有效解决缓存路由问题和扩容难题，保证系统的稳定性和高效性。缓存的设计和实现不仅仅是一个简单的技术问题，更是架构师需要精心规划和调整的一个重要方面。合理的缓存策略能够帮助系统在高并发、大数据量的场景下保持高效与稳定，成为架构优化的关键手段。

缓存作为一种优化手段，能够显著提高系统的性能，减少数据库负载，降低 IO 压力。然而，缓存的使用也面临一定的挑战，如数据一致性问题、缓存雪崩等。理解不同类型的缓存及其应用场景、合理设计缓存系统的架构和管理缓存数据的生命周期，是提升系统性能的关键。在分布式系统中，分布式缓存和一致性哈希算法为大规模数据提供了高效存储和访问方案，使得缓存技术可以在复杂的环境中有效运行。通过合理优化缓存，开发人员可以大幅度提升系统的响应速度和吞吐量，为用户提供更快、更稳定的服务。

大型互联网系统面临的挑战主要体现在高并发、大流量、海量数据存储、安全性要求和频繁发布等方面。为了解决这些问题，系统架构的演进从最初的单机系统到如今的分布式系统，经历了多个阶段。垂直伸缩和水平伸缩是提升系统处理能力的两种主要途径，其中水平伸缩被广泛应用于互联网行业。在架构演进过程中，重要的技术手段包括分布式缓存、负载均衡、分布式存储、微服务架构、消息队列、搜索引擎和NoSQL数据库等。这些技术不仅帮助互联网系统处理日益增长的用户请求和数据存储需求，还提高了系统的可扩展性、灵活性和容错能力。

/ 持久化对象// JSON字符串// 其他字段及getter/setter// 值对象：价格区间// 枚举：AUTO_APPROVE/MANUAL_REVIEW// 枚举：CNY/USD// 业务方法：校验价格是否在区间内// 聚合根：价格规则// 核心业务方法：校验报价单一职责原则领域对象：专注业务逻辑数据对象：专注存储结构DTO：专注数据传输开闭原则领域模型修改不影响存储层存储结构变化不影响业务逻辑显式语义原则通过。

服务接口定义（由框架提供）编程在很大程度上是一种“制定契约”。在软件领域，契约思维主要有软件规范和软件标准两方面的重要价值。一致性可以降低复杂度，我们可以在命名、异常处理、应用架构等方面在团队内制定规范。不管是前端标准化，还是JCP，都体现了规范和标准在软件中的重要作用。谁掌握了标准制定权，谁就掌握了主动权。从这个意义上来说，提供SPI要比调用他人的API更主动。

/ Spring框架定义的接口，用户需要实现它用户实现// 用户自定义监听器，监听容器初始化完成事件@Component@Override// 容器初始化完成后执行的定制逻辑System.out.println("Spring容器初始化完成！执行自定义初始化操作...");// 例如：加载缓存、启动定时任务等Logback 框架中定义的// Logback框架提供的抽象类，用户需要继承它// 基础方法（框架已实现）public void start() { /* 初始化资源 */ }

在软件开发领域，技术能力固然重要，但决定程序员能否高效解决问题的关键，往往在于其思维方式。《程序员的底层思维》一书系统地总结了程序员应具备的16种思维能力，并将其分为基础思维、专业思维和综合实践三部分。接下来我们将围绕这些思维能力展开，探讨如何通过构建思维框架来提升编程效率和解决问题的能力。程序员的底层思维是解决问题的关键。通过掌握抽象、逻辑、结构化等基础思维，以及解耦、模型、数据等专业思维，我们可以构建高效的思维框架，从而更好地应对复杂的编程挑战。

耦合带来了业务前台和业务中台高昂的协作和认知成本，抵消了复用节省的时间成本，总体上反而造成了研发效率的下降。由此可见，软件设计的一大目标就是“解耦”。模块之间的联系越少，耦合越小，系统就越灵活，可修改性越好。在一个设计良好的系统中，数据库代码和用户界面应该是正交的。这样我们可以改动界面，而不影响数据库；在更换数据库时，可以不用改动界面。在软件工程领域，我们一直在强调“高内聚，低耦合”，即希望通过降低模块之间的耦合性来提升模块的独立性、扩展性和重用性。

计算机中的任何问题，都可以通过加一层来解决”，这句话体现了中间层映射的设计理念。如图所示，当A对B有依赖时，A不要直接依赖B，而是抽象一个中间层，让A依赖中间层，再由中间层映射到B，这样当B改变时，不用修改A，只需调整中间层的映射关系.所以一种有效的解耦方式是通过引入中间层来进行模块之间的映射。中间层充当一个调度器的角色，它负责在不同模块之间传递请求和数据，从而避免了直接依赖的情况。