小工匠

高并发秒杀场景下缓存体系的设计与实践。核心思路是通过分层缓存架构（CDN、本地缓存、Redis）拦截无效请求，减轻数据库压力。重点内容包括：库存原子操作（Lua脚本实现预减防超卖）、缓存预热策略、防刷限流机制（布隆过滤器、令牌桶）、异步消息队列实现最终一致性，以及监控指标设计。文章强调缓存与业务逻辑深度结合，通过"上游过滤+缓存优先+异步落地"的整体方案保障系统高可用。

ZooKeeper作为分布式系统的核心组件，其高可用性依赖于Zab原子广播协议。Zab协议通过Leader-Follower架构实现数据一致性，核心流程包括消息广播、崩溃恢复和数据同步三阶段。Zxid作为64位事务编号（高32位epoch+低32位计数器）保证事务全局有序。与Paxos相比，Zab针对主备架构优化，支持快速选举和日志同步。典型案例展示了当Leader故障时，集群通过比较Zxid和ServerID进行新Leader选举的过程，确保服务持续可用。Zab协议的设计有效解决了分布式环境中的数据一致性

摘要： Paxos是分布式系统实现一致性的核心算法，通过Quorum机制在可用性与一致性间取得平衡。其核心角色包括Proposer（提案者）、Acceptor（批准者）和Learner（学习者）。Paxos采用两阶段流程： 准备阶段：Proposer发送递增的ProposalID，Acceptor承诺不接收更小ID的提案； 选举阶段：Proposer根据多数Acceptor回复决定提交value，成功后广播结果。 Paxos能容忍半数以内节点故障，通过唯一递增的ProposalID避免阻塞。优化方案如Fas

本文探讨分布式系统中的数据一致性理论演进与实践应用。首先分析BASE理论三要素（基本可用、软状态、最终一致性），对比其与ACID原则的差异。其次解析分布式环境中的时钟同步问题，提出逻辑时钟的替代方案。随后深入剖析五种一致性模型（强一致性、弱一致性、最终一致性、因果一致性、会话一致性）及其适用场景。最后阐明CAP理论与BASE理论的关系，指出大多数分布式系统通过牺牲强一致性来保障可用性和分区容错性。文章系统性地呈现了分布式架构中一致性权衡的理论框架与实践路径。

摘要 分布式系统设计中的CAP理论揭示了在一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）之间的根本性权衡。文章详细解析了CAP三要素的定义与相互关系，通过反证法证明三者不可兼得。实践中，系统需在CP（强一致）与AP（高可用）架构间选择，如ZooKeeper采用CP保证一致性，Eureka选择AP确保可用性。设计时需根据业务需求灵活运用多副本、读写分离等策略，在分区恢复时通过补偿机制修复数据。CAP理论为分布式系统架构提供了关键指导原

本文系统探讨分布式缓存架构设计中的CAP理论与实践演进。首先指出传统CAP三选二模型的局限性，阐述Brewer对CAP的修正观点，强调分区容忍的动态性。随后从分区感知、BASE理论、数据一致性方案三个维度展开，详细分析2PC/3PC、Paxos/Raft等分布式事务算法，以及主从复制、消息总线等多活实现方案。最后以多区域缓存更新为例，展示兼顾高可用与最终一致性的典型架构设计，为分布式系统开发提供实践参考。全文覆盖理论演进、算法比较和工程实现，形成完整的分布式缓存设计知识体系。

本文系统阐述了分布式系统设计的核心理论CAP定理。首先介绍了CAP的历史发展，从1998年Brewer提出猜想，到2002年MIT学者完成理论证明。随后详细解析了CAP三要素：一致性要求所有节点数据同步，可用性强调请求总能响应，分区容错性则关注网络故障时的系统韧性。通过双节点场景证明，在网络分区时只能保证CP或AP。文章分析了三种权衡方案及典型应用场景，并指出实践中应避免绝对化理解，建议根据业务特点动态调整策略。最后强调在实际系统设计中，需结合业务需求灵活运用CAP理论，通过技术手段优化可用性与一致性的平衡

摘要： Redis Cluster使用中常遇到跨槽查询（如ZSET、MGET）和多线程并发GET导致的性能问题。解决方案包括： 管道（Pipeline）替代多线程：按槽分组批量GET，减少网络往返和线程开销。 Hash Tag保证同槽：为相关Key添加相同标签（如{timeline}），支持MGET或Lua脚本跨Key操作。 Hash结构批量存储：将多条数据存入同一Hash，通过HMGET一次性获取，减少请求次数。 直接存储或RedisJSON：序列化内容存入ZSET或使用JSON模块批量查询。 综合方案可

Redis是一款高性能的内存数据库，支持丰富的数据类型和持久化策略。核心特性包括：多种数据结构（String、List、Set、ZSet、Hash等）、双重持久化（RDB快照和AOF日志）、读写分离、Lua脚本和事务支持，以及分布式集群能力。Redis采用单线程事件驱动模型，提供高QPS性能，同时通过后台线程优化持久化任务。其持久化策略推荐混合使用RDB和AOF，兼顾恢复速度和数据完整性。此外，Redis支持主从复制、故障转移和多种分片方案（客户端分片、Proxy层或原生Redis Cluster），适用于

本文探讨了分布式缓存系统中的两大核心问题：热键（Hot Key）和大键（Big Key）。热键指在短时间内被海量请求集中访问的缓存键，会导致单点资源过载，常见于突发新闻、秒杀活动等场景。解决方案包括键分片、多级缓存、动态扩容和客户端本地缓存。大键则指体积过大的缓存值，容易引发网络传输和内存分配问题，常见于长文本、大规模集合等数据。解决方法有阈值压缩、批量写入和键分拆策略。文章强调需结合业务特点，通过监控和多种技术组合来构建高可用缓存方案。

当一份数据同时存在于数据库和缓存中时，如果两者数据不同步，便会产生“数据不一致”问题。进一步地，若采用多缓存副本（例如多机房或多节点复制），各副本间的数据也可能因为更新不完全而出现差异。高并发场景下，若缓存正好 miss（例如过期、被淘汰），海量请求会同时打到数据库，导致数据库压力骤增，甚至雪崩。接下来将对缓存设计中的 7 大经典问题，

分布式缓存系统设计中的三大经典问题及其解决方案： 缓存失效：大量key同时过期导致DB压力骤增。解决方案：基础过期时间+随机值，分散淘汰窗口。 缓存穿透：恶意查询不存在数据导致持续穿透DB。解决方案：缓存空值+布隆过滤器双重防护。布隆过滤器通过位数组和哈希函数实现高效存在性判断，虽有一定误判率但能有效拦截非法请求。 缓存雪崩：缓存节点故障引发连锁反应。解决方案：多副本部署、读写降级开关、实时监控与自动故障转移，确保系统高可用。 这些防护措施需结合业务场景灵活运用，从而构建稳定高效的缓存体系。

本文系统介绍了缓存设计的全流程方案，从组件选型到架构部署。首先在开源组件与自研方案间权衡，建议优先选用成熟方案；其次根据业务特点设计合理的数据结构。重点探讨了分布式缓存的三种分布策略与路由方式，并详细解析了部署运维中的分层、多活、异构等关键考量。最后提出缓存设计的"四步走"方法论：组件选型、数据结构、分布策略、部署运维，强调需要结合业务特性与运维成本综合考量。文章配有缓存全景图与架构设计考量表，为构建高性能缓存体系提供系统指导。

本文系统介绍了三种常见的缓存读写模式：Cache Aside（旁路缓存）、Read/Write Through（读写穿透）和Write Behind Caching（异步缓存写入）。Cache Aside以数据库为准，通过懒加载回填缓存；Read/Write Through由缓存服务统一代理读写，简化业务逻辑；Write Behind Caching则通过异步批量写入实现最高写性能。文章分析了各种模式的优缺点和适用场景，并对比了不同缓存分类（本地/进程间/远程缓存）的特点。最后强调系统设计需要权衡性能与一致

缓存是提升数据访问速度的关键技术，分为狭义和广义两类。狭义缓存主要指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，以单独服务的形式存在，可在多台缓存服务器上进行水平扩展，适合分布式应用场景。分布式缓存的特点独立性：分布式缓存系统作为一个独立服务，不依赖于应用实例，与应用相分离。共享性：可以被多个应用访问，实现缓存数据的共享。