Microservice

高并发系统稳定性设计 本文适用于 Web 应用、API 服务、微服务、分布式系统等高并发场景，重点介绍现代企业级系统如何通过限流、熔断、降级、重试、超时、隔离和缓存等技术保障系统的稳定运行。 一、什么是高并发 1.1 高并发的定义 高并发（High Concurrency）是指系统在单位时间内需要同时处理大量用户请求的能力。 例如： 电商平台双十一抢购 秒杀活动 支付系统 社交平台热点事件 游戏服务器 视频直播 AI 大模型接口 假设一个用户访问商品详情页面，请求流程如下： Client │ ▼ Nginx │ ▼ PHP │ ├── Redis ├── MySQL └── Elasticsearch 一个用户访问几乎不会产生压力。 但是如果同时有10000个用户->10000 HTTP Requests->Application 系统就需要在极短时间内完成： HTTP 请求解析 身份认证 参数校验 Redis 查询 数据库访问 JSON 序列化 网络返回 如果系统设计不合理，就可能出现响应变慢、超时甚至崩溃。 1.2 高并发 ≠ 高性能 高性能（Performance） 高性能关注的是 单个请求处理速度。 例如： 接口耗时：50 ms 优化 SQL 后：20 ms 这属于性能优化。 常见优化包括： SQL 优化 Redis 缓存 JVM / PHP Runtime 优化 协程 对象池 连接池 高并发（Concurrency） 高并发关注的是： 系统能够同时处理多少请求。...

高并发系统设计-服务降级 一、概述 1.1 什么是服务降级 服务降级（Fallback）指的是： 当系统压力过大或依赖服务不可用时，主动返回一个“可接受的替代结果”，而不是让请求失败。 例如： 正常： → 查询实时商品详情 降级： → 返回缓存商品详情 / 静态数据 1.2 降级和熔断的区别 项目 熔断 降级 目的 防止故障扩散 保证可用性 触发 服务异常 系统压力 / 异常 行为 阻断调用 返回替代结果 是否对外可用 否 是 熔断 = 不调用 降级 = 换一种方式返回 1.3 为什么需要服务降级 在高并发系统中： 资源永远是有限的。 例如： 数据库：1000 QPS, 实际请求：10000 QPS 如果不做降级：请求全部打到数据库-》系统崩溃 1.4 企业典型应用场景 场景1：商品详情页 正常： → 实时库存 + 价格 + 推荐 降级： → 缓存商品 + 默认库存 场景2：推荐系统 推荐服务挂了 → 返回热门商品 场景3：搜索系统 ES不可用...

高并发系统设计-熔断 一、概述 1.1 什么是熔断 熔断（Circuit Breaker）的核心思想来自电路保险丝： 当电流过大时，保险丝会断开，保护整个电路。 在分布式系统中： 服务A → 服务B → 服务C → 数据库 如果服务C异常： 超时 报错 响应缓慢 那么如果不做控制： A 等 BB 等 CC 卡住→ 线程全部阻塞→ 请求堆积→ 系统雪崩 熔断的作用就是： 当下游服务异常时，直接停止调用它，快速失败。 1.2 为什么需要熔断 在高并发系统中，最危险的问题不是“服务失败”，而是： 失败被放大并传播 例如： 数据库慢查询 ↓ 所有请求阻塞 ↓ 连接池耗尽 ↓ Redis压力上升 ↓ Gateway超时 ↓ 全链路崩溃 这就是： 级联故障（Cascade Failure） 1.3 熔断解决的问题 熔断解决三类问题： 1. 防止线程阻塞 避免请求一直等待下游： 请求 → 卡住 → 不释放资源 2.防止错误放大 错误不会扩散到上游系统： 错误服务 → 不再调用 1.4 企业典型场景 场景1：支付服务异常 订单服务 → 支付服务（异常） 不熔断： → 一直等待 → 订单线程堆积 熔断后： → 直接返回“支付处理中” 场景2：库存服务不可用 库存服务挂了 熔断： → 不再调用库存 → 返回“库存未知” 场景3：第三方接口超时 例如：...

高并发系统设计-缓存保护 一、概述 1.1 什么是缓存保护 缓存保护（Cache Protection）是指： 通过一系列缓存设计策略，避免缓存异常导致数据库被大量请求直接访问，从而保证系统稳定性。 典型架构： Client │ ▼ Gateway │ ▼ Application │ ┌─────────┴─────────┐ │ │ ▼ ▼ Local Cache Redis Cache │ Cache Miss？ │ ▼ MySQL 1.2 为什么需要缓存保护 Redis 可以承受几十万甚至百万级 QPS，而 MySQL 通常只能支撑几千 QPS。 例如： Redis 100000 QPS ↓ MySQL 3000 QPS 如果 Redis 出现问题： 100000 请求 ↓ 全部进入 MySQL ↓ 数据库连接耗尽 ↓ 整个系统崩溃 缓存的首要目标是保护数据库，其次才是提升访问性能。 1.3 企业缓存架构 企业通常采用： Client │ ▼ Application │ ▼ Local Cache(Caffeine) │ ▼ Redis Cluster │ ▼ MySQL 同时配合：...

高并发系统设计-重试 一、概述 1.1 什么是重试 重试（Retry）是指： 当一次请求失败后，在满足条件的情况下再次发起请求，以提高成功率。 例如： 请求 → 失败 → 再请求 → 成功 1.2 为什么需要重试 在分布式系统中，失败是常态： 网络抖动 RPC短暂超时 Redis瞬时不可用 MySQL连接波动 依赖服务重启 例如： 请求支付服务 → 超时 但实际服务是正常的 如果不重试：用户支付失败 但如果允许重试： 第一次失败 第二次成功 1.3 重试解决的问题 重试主要解决： 1. 短暂故障 如： 网络抖动 服务瞬断 连接超时 2.依赖服务不稳定 如： 第三方支付 / 短信 / API 3.提高成功率 1.4 重试的误区 错误做法 ： 失败 → 立即重试 → 再失败 → 无限循环 正确做法是：可控重试 + 退避策略 + 最大次数限制 二、原理 2.1 重试的核心思想 重试本质是： 用时间换成功率 但前提是：...

高并发系统设计-限流 一、什么是限流 限流（Rate Limiting）是指限制单位时间内允许进入系统的请求数量。 简单来说，就是： 控制流量进入系统的速度，而不是等系统崩溃之后再处理。 例如： 某接口限制：1000 Request / Second 如果一秒钟来了：1500 Request 那么：1000正常处理，500拒绝访问 通常返回：HTTP 429 Too Many Requests 限流的本质就是： 宁可拒绝一部分请求，也不要让整个系统崩溃。 二、为什么需要限流 因为系统资源是有限的。 例如： 服务器配置： CPU：8 Core Memory：16GB MySQL连接池：100 Redis连接池：200 这些资源都存在上限。 假设数据库最大只能处理： 5000 QPS 如果突然来了：30000 QPS 没有限流：30000全部访问MySQL->连接池耗尽->CPU100%->慢SQL->超时->…->系统崩溃 有了限流：30000->Gateway->允许5000->25000直接拒绝->系统稳定 虽然部分用户会收到"系统繁忙"的提示，但系统整体仍然保持可用。 这正是限流存在的意义 三、典型应用场景 限流几乎存在于所有互联网系统中。 1、登录接口 例如：POST /login 限制：每个IP 5次/分钟 防止： 暴力破解密码 恶意攻击 短时间大量登录 2、短信验证码 3、支付接口 4、秒杀系统 5、开放API 四、限流的位置 限流通常不是只有一层。 一般有四层。 第一层：CDN 例如： Cloudflare->限制恶意流量 主要抵御： CC攻击 DDoS Bot 第二层：Nginx / Gateway 例如： Client->Gateway->Application...

高并发系统设计-隔离 一、概述 1.1 什么是隔离 隔离（Bulkhead）源自船舶结构设计： 船体被分割成多个“水密舱”，即使某一舱进水，也不会导致整船沉没。 在分布式系统中对应为： 将不同业务流量或依赖资源隔离开，避免相互影响。 例如： 订单服务 支付服务 库存服务 推荐服务 如果没有隔离： 推荐服务慢查询 → 占满线程池 → 订单无法处理 → 系统崩溃 1.2 为什么需要隔离 在高并发系统中，最危险的不是“单点失败”，而是： 资源被某一个模块耗尽 典型问题： 1. 线程池被占满 慢接口占用所有 worker → 新请求无法处理 2. 连接池被耗尽 某服务频繁调用DB → 连接池100个全部占满 3.某服务拖垮整个系统 推荐服务异常 → 影响订单服务 → 影响支付服务 → 全系统不可用 1.3 隔离的核心目标 隔离的本质是： 限制资源共享范围，防止“一个坏点影响全局” 目标： 防止资源争抢 防止链式崩溃 提高系统稳定性 控制故障范围 1.4 典型场景 场景1：电商系统 订单 / 支付 / 推荐 / 搜索 要求： 推荐挂了不能影响下单 搜索挂了不能影响支付 场景2：微服务调用 Service A → B → C → D 如果 D 崩溃：...

分布式锁详解 在高并发和分布式系统中，为保证资源的一致性和互斥访问，分布式锁是必不可少的技术手段。本文将系统地讲解分布式锁的概念、场景、实现原理、使用方式，并附 PHP 示例。 1. 什么是分布式锁 定义： 分布式锁（Distributed Lock）是用于在 多台机器或多个服务实例中控制共享资源访问的机制。它保证在同一时间，只有一个客户端可以操作某个资源，从而避免并发冲突。 特点： 互斥性：同一时间只有一个客户端持有锁。 可重入性（可选）：同一客户端可以重复获取锁。 可靠性：锁过期或客户端异常可自动释放，避免死锁。 可扩展性：适用于分布式系统和微服务架构。 2. 分布式锁的应用场景 分布式锁在企业场景非常常见，典型使用场景包括： 库存扣减 秒杀或抢购场景，防止库存超卖。 订单号生成 保证全局唯一订单号。 任务调度 多实例系统中，保证任务只被单实例执行。 缓存更新 防止缓存击穿时，多实例同时重建缓存。 支付或转账操作 防止重复扣款或资金异常。 3. 分布式锁的实现原理 3.1 数据库锁 原理： 利用数据库唯一索引或事务机制创建锁记录。 示例： INSERT INTO locks(name, create_time) VALUES('order_123', NOW()); -- 成功表示获得锁，失败表示锁已被占用 优缺点： 优点：简单易用，直接使用现有数据库。 缺点：高并发性能较差，数据库可能成为瓶颈。 3.2 Redis 锁 原理： 利用 Redis 的 SETNX 或 SET key value NX PX 原子操作。 设置锁过期时间，防止死锁。 (RedLock红锁可以解决在 Redis ​主从复制或哨兵模式下，使用单实例 Redis 锁可能遇到的锁失效问题。) 释放锁： 需要验证当前客户端持有锁，防止误删他人锁。 优点：...

高并发技术体系概要 主要为基础理论知识 第一部分：高并发保护机制 限流 熔断 降级 重试 隔离 缓存保护 超时 第二部分：并发模型 线程模型 协程模型 事件驱动模型 Reactor模型 第三部分：资源池化 连接池 线程池 协程池 对象池 第四部分：异步架构 MQ 事件驱动 削峰填谷 异步任务 第五部分：微服务治理 注册中心 服务发现 配置中心 负载均衡 服务调用 API Gateway 链路追踪 服务监控 日志系统

关于分布式 一、什么是分布式？ 一个系统，各组件分别部署在不同服务器。彼此通过网络通信和协调的系统。 可以指多个不同组件分布在网络上互相协作 也可以一个组件的多个副本组成集群，互相协作如同一个组件，比如数据存储服务中心为了数据不丢失而采取的多个服务备份冗余 分布式最早出现的目的首先是解决单点问题，避免单点故障，然后解决了性能问题 二、分布式和微服务的区别？ 微服务并不一定是分布式系统（微服务中多个服务不一定部署在不同服务器，单机部署情况则不算是分布式） 分布式一定不是微服务 （分布式祖耀侧重服务的部署方式，微服务则是针对应用的一种服务拆分的架构） 三、分布式CAP原则 在设计一个分布式项目的时候会遇到三个特性： 一致性（Consistency）：所有节点数据实时同步，读取始终返回最新值 可用性（Availability）：每个请求必须得到响应（无论数据是否最新），高可用 分区容错（Partition Tolerance）：分布式最基本也是必需要有的特性，系统在遇到某个节点或网络分区故障时，仍然能够对外提供服务 三者无法同时满足，最多只能实现其中两个，网络分区发生时，必须牺牲C或A ‌CP（牺牲可用性）‌：如ZooKeeper，确保数据强一致性但可能拒绝请求 ‌AP（牺牲一致性）‌：如Eureka，保证服务可用但允许数据短暂不一致 三、 BASE理论 BASE理论是分布式系统设计原则，BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。 基本可用（Basically Available）：分布式系统，在出现故障的时候，允许损失部分可用性。类似服务降级 软状态（Soft State）：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。 最终一致性（Eventual Consistency）：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。 四、分布式事务及解决方案 分布式事务 本地事务依赖数据库本身提供的事务特性来实现， 但是在分布式环境下，可能会出现需要远程调用，比如： begin transaction； //1.本地数据库操作：张三减少金额 //2.远程调用：让李四增加金额 commit transation; 张三和李四的账户不在一个数据库中甚至不在一个应用系统里，实现转账事务需要通过远程调用，由于网络问题就会导致分布式事务问题。 分布式事务解决方案 2PC 2PC 即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2 是指两个阶段，P 是指准备阶段，C 是指提交阶段。偏向数据库 TCC TCC 是 Try、Confirm、Cancel 三个词语的缩写，TCC 要求每个分支事务实现三个操作：预处理 Try、确认 Confirm、撤销 Cancel。Try 操作做业务检查及资源预留，Confirm 做业务确认操作，Cancel 实现一个与 Try 相反的操作即回滚操作。TM 首先发起所有的分支事务的 Try 操作，任何一个分支事务的Try操作执行失败，TM 将会发起所有分支事务的 Cancel 操作，若 Try 操作全部成功，TM 将会发起所有分支事务的 Confirm 操作，其中 Confirm/Cancel 操作若执行失败，TM 会进行重试。偏向代码