小工匠

缓存是提升数据访问速度的关键技术，分为狭义和广义两类。狭义缓存主要指CPU内部的SRAM，用于加速主存数据交换；广义缓存则包括操作系统页缓存和应用层中间件如Redis、Memcached等。缓存的核心思想基于时间局限性原理、空间换时间和性能—成本权衡，旨在通过高速存储热点数据提升访问效率。缓存的优势在于显著提升访问性能、降低网络拥堵、减轻后端负载和增强系统可扩展性。然而，缓存也带来系统复杂度上升、硬件/运维成本增加以及数据一致性挑战等问题。实例对比显示，缓存（如Memcached/Redis）在读写QPS、

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

- **加载优化** - **减少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原理和基础架构设计原则仍将是指导我们进行技术选型和架构设计的基石。

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

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

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

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

TCC（Try-Confirm-Cancel）的核心思想是对于每个资源的原子操作，应用程序都需要注册一个与此操作对应的确认操作和补偿（撤销）操作。随着大流量、高并发业务场景的出现，对系统可用性的要求变得越来越高，这时 CAP 理论和 BASE 理论逐渐进入人们的视野，柔性事务成为分布式事务的主要实现方式，TCC 作为补偿事务也位列其中.：协调者（通常是事务管理器）向所有参与者发送“准备提交”请求，要求参与者执行事务操作并保留结果，但不提交数据，参与者需要返回“准备好”或“无法提交”的响应。

特性阶段数量2个阶段：Prepare（准备阶段）和Commit/Abort（提交/回滚阶段）3个阶段：CanCommit（询问阶段）、PreCommit（预提交阶段）、DoCommit（提交阶段）协议设计基于两阶段协议，协议简单但容易导致阻塞问题基于三阶段协议，增加了预提交阶段，减少了阻塞问题阻塞问题存在阻塞问题，特别是当协调者或参与者崩溃时，系统可能无法继续通过引入PreCommit阶段，减少了崩溃时的阻塞问题，避免了长时间停滞协调者崩溃的处理协调者崩溃后，参与者不确定事务是提交还是回滚，导致阻塞。

在分布式系统中，由于多个节点（进程）并发执行，可能会访问共享的临界资源。为了保证资源的正确性和一致性，必须保证同一时刻只有一个节点能够访问该资源，这就是分布式互斥的需求。没有这种互斥机制时，多个节点可能会同时修改共享数据，导致数据不一致或不正确。例如，在高并发的秒杀系统中，多个订单服务节点可能会同时扣减库存，如果没有互斥控制，可能导致库存超卖的问题。通常来讲，在消费者下订单时也会对库存进行扣减，此时订单服务会更新库存变量，其实就是将其值减 1。

分布式系统的核心特点是多个应用服务部署在不同的机器或网络环境中，这些服务需要相互通信与协作。然而，当多个服务同时访问共享资源时，会产生互斥问题。例如，当多个服务尝试修改同一数据时，就会发生数据竞争，导致数据不一致。为了避免这种冲突，需要通过互斥算法来控制对共享资源的访问，确保同一时间内只有一个服务可以操作该资源。互斥算法是理论基础，在实际工作中我们会利用分布式锁来解决互斥问题；当多个应用服务共同完成一个任务时会出现分布式事务问题，会使用分布式事务的原则和解决方案；

无论 API 网关，还是服务注册和发现，都在探讨服务与服务如何发现对方、如何选择正确路径进行调用，描述的是服务之间的关系。厘清关系后，我们再来谈谈服务之间的调用是如何完成的。在分布式系统中，应用或者服务会被部署到不同的服务器和网络环境中，特别是在有微服务的情况下，应用被拆分为很多个服务，每个服务都有可能依赖其他服务。

从业务层面讲，客户端完成某个业务需要同时调用多个微服务。客户端发起下单请求后需要调用商品查询、扣减库存以及订单更新服务如果这些服务需要客户端分别调用才能完成，必然会增加请求的复杂度，同时带来网络调用性能的损耗。因此，针对微服务应用场景推出了 API 网关的调用。在客户端与微服务系统之间加入下单 API 网关，客户端直接给这个 API 网关下达命令，由其完成对其他三个微服务的调用并且返回结果给客户端。从系统层面讲，任何一个应用系统要想被其他系统调用，都需要暴露 API，这些 API 代表功能点。

以客户端请求应用服务器为例客户端会将请求的 URL 发送给 DNS 服务器，DNS 服务器根据用户所处的网络区域选择最近机房为其提供服务，这个选择过程就是 DNS 负载均衡。每个网络区域都会存在一个或者多个服务器集群，这里会通过硬件负载均衡器（例如 F5）将请求负载均衡到具体的服务器集群，这个过程就是硬件负载均衡。最后，在集群内通过 Nginx 这样的软件负载均衡器将请求分配到对应的应用服务器，就完成了整个负载均衡的过程。

为了完成上面的订单业务流程，将分布式系统分为了四层数据分片：通过 MyCat 等中间件，将大表数据分散到不同数据库，提高了查询效率，降低了单表的访问压力。读写分离：将读请求分流到只读节点，从而降低主节点的负载，提升系统的读性能。主从同步：通过主从复制机制，保证读写数据的一致性，并支持故障转移，提高了系统的可用性和容错性。这种存储设计确保了电商系统在高并发场景下的稳定性和性能，使系统能够快速响应用户请求，同时保证数据的完整性和一致性。

随着互联网业务规模的快速扩展，现代 IT 系统中数据存储的重要性日益凸显。数据量不断增加、并发访问频繁、存储需求升级，使得单一的存储设备难以满足现代系统的需求。分布式存储正是为了解决这些问题而诞生的一种存储架构。接下来我们详细介绍分布式存储的核心问题、技术实现以及 RAID 技术对其的启发，并探讨分布式存储在实际应用中的优势和实现策略。

分布式缓存系统是为了解决高并发场景中数据访问的速度瓶颈，将频繁访问的数据存储在内存中，以便迅速响应应用程序的查询请求。缓存类型：分布式缓存分为进程内缓存和进程外缓存。进程内缓存：在应用程序的JVM内，缓存大小受限于单机的内存，不适合超大规模数据的存储。进程外缓存：独立于应用程序的JVM，以单独服务的形式存在，可在多台缓存服务器上进行水平扩展，适合分布式应用场景。分布式缓存的特点独立性：分布式缓存系统作为一个独立服务，不依赖于应用实例，与应用相分离。共享性：可以被多个应用访问，实现缓存数据的共享。

分布式缓存系统是为了解决高并发场景中数据访问的速度瓶颈，将频繁访问的数据存储在内存中，以便迅速响应应用程序的查询请求。缓存类型：分布式缓存分为进程内缓存和进程外缓存。进程内缓存：在应用程序的JVM内，缓存大小受限于单机的内存，不适合超大规模数据的存储。进程外缓存：独立于应用程序的JVM，以单独服务的形式存在，可在多台缓存服务器上进行水平扩展，适合分布式应用场景。分布式缓存的特点独立性：分布式缓存系统作为一个独立服务，不依赖于应用实例，与应用相分离。共享性：可以被多个应用访问，实现缓存数据的共享。

在Keepalived集群中，其实并没有严格意义上的主、备节点，虽然可以在Keepalived配置文件中设置“state”选项为“MASTER”状态，但是这并不意味着此节点一直就是Master角色。控制节点角色的选项是Keepalived配置文件中的“priority”值，但并它并不控制所有节点的角色。另一个能改变节点角色的选项是在模块中设置的“weight”值。这两个选项对应的都是一个整数值，其中“weight”值可以是个负整数，一个节点在集群中的角色就是通过这两个值的大小决定的。

如果没指定信号名，则发送SIGTERM。从这个过程可以看到，vrrp_script模块其实并不关注监控脚本或监控命令是如何实现的，它仅仅通过监控脚本的返回状态码来识别集群服务是否正常，如果返回的状态码为0，那么就认为服务正常，如果返回的状态码为1，则认为服务故障。”方式显示了上个命令返回的状态码，mysql服务运行正常，因此返回的状态码为0，此时check_mysqld模块将返回服务检测正常的提示。由于mysql服务被关闭，因此返回的状态码为1，此时check_mysqld模块将返回服务检测失败的提示。

作为一个高可用集群软件，Keepalived提供了等多个功能模块，通过这些模块也可以实现对集群资源的托管以及集群服务的监控。

也就是说，用户在操作动态页面时，如果在50秒内没有执行任何操作，那么接下来的操作会被分发到另外的节点，但是如果用户一直在操作动态页面，则不受50秒的时间限制。同步组是相对于多个VRRP实例而言的，在多个VRRP实例的环境中，每个VRRP实例所对应的网络环境会有所不同，假设一个实例处于网段A，另一个实例处于网段B，而如果VRRPD只配置了A网段的检测，那么当B网段主机出现故障时，VRRPD会认为自身仍处于正常状态，进而不会进行主备节点的切换，这样问题就出现了。用于设置抢占的延时时间，单位是秒。

Keepalived的安装非常简单，下面通过源码编译的方式介绍Keepalived的安装过程。首先打开Keepalived的官方网址http://www.keepalived.org，从中可以下载到各种版本的Keepalived

Keepalived的运行方式也更加全面化和复杂化，用户可以通过自定义Keepalived的工作方式，例如用户可以通过编写程序来运行Keepalived，而Keepalived将根据用户的设定监测各种程序或服务是否允许正常，如果Keepalived的监测结果与用户设定不一致时，Keepalived将把对应的服务从服务器中移除。它的工作原理是针对被监控的目标设置一个计数器和一个阈值，WatchDog会自己增加此计数值，然后等待被监控的目标周期性地重置该计数值。这是IPVS功能的一个实现。

Heartbeat是一个专业的、功能完善的高可用软件，它提供了HA软件所需的基本功能，比如心跳检测和资源接管，监测集群中的系统服务，在群集节点间转移共享IP地址的所有者等，Heartbeat功能强大，但是部署和使用相对比较麻烦。在现实的网络环境中，主机之间的通信都是通过配置静态路由器（默认网关）完成的，而主机之间的路由器一旦出现故障，通信就会失败，因此，在这种通信模式中，一般情况下MASTER由选举算法产生，它拥有对外服务的虚拟IP，提供各种网络功能，如ARP请求【地址解析协议。，这台物理路由器称为。

集群是一组协同工作的服务集合，用来提供比单一服务更稳定、更高效、更具扩展性的服务平台。在集群的内部，有两个或两个以上的服务实体在协调、配合完成一系列复杂的工作。集群一般由两个或两个以上的服务器组建而成。每个服务器称为一个集群节点，集群节点之间可以相互通信。集群应该具有节点间服务状态监控功能，同时还必须具有服务实体的扩展功能，可以灵活地增加和剔除某个服务实体。集群应该具有故障自动切换功能： 在集群中，同样的服务可以由多个服务实体提供。