分布式 on Leanku 的博客

高并发系统稳定性设计

Fri, 11 Jul 2025 20:46:01 +0800

高并发系统稳定性设计

本文适用于 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）

高并发关注的是： 系统能够同时处理多少请求。

关于分布式

Tue, 11 Jun 2024 20:46:01 +0800

关于分布式

一、什么是分布式？

一个系统，各组件分别部署在不同服务器。彼此通过网络通信和协调的系统。

可以指多个不同组件分布在网络上互相协作
也可以一个组件的多个副本组成集群，互相协作如同一个组件，比如数据存储服务中心为了数据不丢失而采取的多个服务备份冗余
分布式最早出现的目的首先是解决单点问题，避免单点故障，然后解决了性能问题

二、分布式和微服务的区别？

微服务并不一定是分布式系统（微服务中多个服务不一定部署在不同服务器，单机部署情况则不算是分布式）
分布式一定不是微服务（分布式祖耀侧重服务的部署方式，微服务则是针对应用的一种服务拆分的架构）

三、分布式CAP原则

在设计一个分布式项目的时候会遇到三个特性：

一致性（Consistency）：所有节点数据实时同步，读取始终返回最新值
可用性（Availability）：每个请求必须得到响应（无论数据是否最新），高可用
分区容错（Partition Tolerance）：分布式最基本也是必需要有的特性，系统在遇到某个节点或网络分区故障时，仍然能够对外提供服务

三者无法同时满足，最多只能实现其中两个，网络分区发生时，必须牺牲C或A

‌CP（牺牲可用性）‌：如ZooKeeper，确保数据强一致性但可能拒绝请求
‌AP（牺牲一致性）‌：如Eureka，保证服务可用但允许数据短暂不一致

三、 BASE理论

BASE理论是分布式系统设计原则，BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。

1. 基本可用（Basically Available）：分布式系统，在出现故障的时候，允许损失部分可用性。类似服务降级
1. 软状态（Soft State）：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。
1. 最终一致性（Eventual Consistency）：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

四、分布式事务及解决方案

分布式事务

本地事务依赖数据库本身提供的事务特性来实现，但是在分布式环境下，可能会出现需要远程调用，比如：

1begin transaction；
2 //1.本地数据库操作：张三减少金额
3 //2.远程调用：让李四增加金额
4commit transation;

张三和李四的账户不在一个数据库中甚至不在一个应用系统里，实现转账事务需要通过远程调用，由于网络问题就会导致分布式事务问题。

分布式事务解决方案

2PC

2PC 即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2 是指两个阶段，P 是指准备阶段，C 是指提交阶段。偏向数据库
TCC TCC 是 Try、Conﬁrm、Cancel 三个词语的缩写，TCC 要求每个分支事务实现三个操作：预处理 Try、确认 Conﬁrm、撤销 Cancel。Try 操作做业务检查及资源预留，Conﬁrm 做业务确认操作，Cancel 实现一个与 Try 相反的操作即回滚操作。TM 首先发起所有的分支事务的 Try 操作，任何一个分支事务的Try操作执行失败，TM 将会发起所有分支事务的 Cancel 操作，若 Try 操作全部成功，TM 将会发起所有分支事务的 Conﬁrm 操作，其中 Conﬁrm/Cancel 操作若执行失败，TM 会进行重试。偏向代码

Redis分布式

Tue, 12 Mar 2024 20:46:01 +0800

Redis分布式

一、 Redis分布式概述

1. 什么是Redis分布式

Redis分布式是指将Redis数据分布到多个Redis节点上，通过集群方式提供更高性能、更大容量和更好可用性的解决方案。

1.2 为什么需要Redis分布式

数据量增长：单机内存容量有限
高并发需求：单机性能瓶颈
高可用性：避免单点故障
可扩展性：支持业务动态扩容

1.3 Redis分布式方案对比

方案	优点	缺点	使用场景
主从复制	部署简单，读写分离	写操作单点，故障需手动切换	读多写少，数据备份
Redis Sentinel	自动故障转移，高可用	配置复杂，扩容不便	生产环境高可用
Redis Cluster	数据分片，自动故障转移	客户端兼容性要求，迁移复杂	大数据量，高并发

二、 Redis分布式方案搭建

2.1 主从复制搭建

配置文件示例

主节点 (master.conf):

1port 6379
2daemonize yes
3pidfile /var/run/redis_6379.pid
4logfile "/var/log/redis_6379.log"

从节点 (slave.conf):

port 6380
daemonize yes
pidfile /var/run/redis_6380.pid
logfile "/var/log/redis_6380.log"
slaveof 127.0.0.1 6379

启动命令

1# 启动主节点
2redis-server master.conf
3
4# 启动从节点
5redis-server slave.conf

2.2 Redis Sentinel搭建

Sentinel配置文件