一、系统性能核心指标
在构建高并发、高可用的分布式系统时，首先需要掌握几个关键性能指标：
| 指标 | 全称 | 含义 | 公式/说明 |
|---|---|---|---|
| RT | 响应时间（Response Time） | 系统对请求做出响应所需的时间 | RT越短，用户体验越好 |
| QPS | 每秒查询率（Queries Per Second） | 系统每秒能处理的查询数量 | 单线程QPS = 1000ms / RT |
| TPS | 每秒事务数（Transactions Per Second） | 系统每秒能处理的事务数量 | 一个事务可能包含多个查询，TPS ≥ QPS |
| 并发数 | 同时处理的请求数量 | 系统能同时承载的用户请求数 | 类比“高速公路的车道数” |
✅ 提示：系统的最佳线程数 =
((线程等待时间 + 线程CPU时间) / 线程CPU时间) × CPU数量。超过最佳线程数可能导致资源竞争，QPS下降。
二、网站的基本结构
一个完整的网站由以下几个核心部分构成：
- IP地址
- 网络设备的唯一标识，如同“门牌号”。
- 服务器必须有IP地址才能被访问。
- 服务器（主机）
- 存放网站文件、运行程序的远程计算机。
- Hosting（主机）常用于小商家租用，Server（服务器）多指整机租用。
- 域名
- 用户访问网站的网址，如
example.com。 - 是网站在互联网上的“名字”和“入口”。
- 用户访问网站的网址，如
- DNS解析
- 将域名转换为服务器IP地址的过程。
- 用户输入域名 → DNS解析 → 获取IP → 连接服务器。
- 网站与数据库
- 前台：用户可见的页面内容（文字、图片、视频等）。
- 后台：数据库（存储数据）和管理功能（如CMS后台）。
- 动态网站需调用数据库数据，静态网站（如纯HTML）通常无数据库。
三、建站方式
| 方式 | 特点 | 代表平台 |
|---|---|---|
| SaaS平台 | 无需管理服务器，操作简单，适合新手 | Shopify、Wix |
| CMS系统 | 功能灵活，需配置服务器和域名 | WordPress、Joomla |
| 代码开发 | 完全自定义，需专业编程能力 | HTML/CSS/JS、React |
✅ 全托管主机：如
wordpress.com、nexcess，用户只需关注建站与运营，服务器运维由平台负责。
四、负载均衡（Load Balance）
1. 概念与目标
- 定义：将网络请求分发到多个后端服务器，优化资源利用，避免单点过载。
- 目标：
- 提升吞吐量（高并发）
- 保障服务不中断（高可用）
- 支持灵活扩展（扩展性）
- 防御异常流量（安全性）
2. 分层架构
| 层级 | 技术实现 | 特点 |
|---|---|---|
| 三层（L3） | IP地址轮询（如LVS） | 基于IP转发，性能高，无法识别应用层内容 |
| 四层（L4） | TCP/UDP协议分流（如F5） | 基于IP+端口，适合高并发 |
| 七层（L7） | HTTP/HTTPS路由（如Nginx） | 基于URL、Header等，灵活性高，性能略低 |
3. 常见负载均衡算法
| 算法 | 原理 | 适用场景 |
|---|---|---|
| 轮询（Round Robin） | 请求依次轮流分配 | 均匀分布请求，无状态服务 |
| 加权轮询 | 按服务器性能分配权重 | 服务器性能差异大 |
| 源IP哈希 | 对客户端IP哈希，固定访问同一节点 | 需要会话保持（如购物车） |
| 最少连接数 | 请求发给当前连接最少的节点 | 长连接场景（如WebSocket） |
| 随机算法 | 随机选择后端节点 | 简单测试场景 |
五、高可用（High Availability, HA）
1. 核心思想
- 冗余：部署多台服务器，避免单点故障。
- 自动故障转移：当主节点宕机时，备用节点自动接管服务。
2. 实现方式
- 多台服务器 + 负载均衡（如Nginx + Keepalived）
- 数据库主从复制 + 哨兵（Redis Sentinel）
- 使用CDN缓存静态资源，减轻源站压力
- Kubernetes自动扩缩容（Auto Scaling）
3. 可用性衡量
- “几个九”表示系统可用性：
- 99%：每年宕机约3.65天
- 99.9%：每年宕机约8.76小时
- 99.99%：每年宕机约52.6分钟
- 多台服务器组成的集群，整体可用性远高于单台。
六、集群技术实现
1. Kubernetes（K8s）
- Service：为一组Pod提供稳定访问入口（ClusterIP）。
- Ingress Controller：管理外部访问路由，实现七层负载均衡。
- Kube-proxy：维护节点网络规则，通过
iptables或IPVS模式实现Service到Pod的负载均衡。 - Endpoints Controller：监听Service和Pod变化，维护Endpoints（Pod地址列表）。
- 自动扩缩容：根据负载动态增减Pod数量。
2. Redis 高可用
- 主从模式：主节点负责读写，从节点同步数据并提供读服务。
- 哨兵（Sentinel）：监控主节点状态，主节点宕机时自动选举新主节点。
- Cluster模式：数据分片（16384个槽），多主节点分担写压力，每个主节点有从节点做高可用。
3. ZooKeeper（ZK）
- Leader：处理所有写请求，保证事务顺序性。
- Follower：处理读请求，参与投票和Leader选举。
- 高可用机制：Leader宕机后，Follower通过ZAB协议选举新Leader，实现自动故障转移。
4. 数据库高可用
- 主从复制：主库写，从库读，数据同步。
- 读写分离：使用MyCAT等中间件实现，提升数据库吞吐量。
- 分库分表：应对海量数据存储需求。
七、高并发场景与解决方案
1. 高并发诱因
- 电商平台秒杀、抢红包活动
- 用户因页面加载慢而频繁刷新
- DDOS攻击（分布式拒绝服务攻击）
2. 常见问题
- 接口响应慢 → 连接被占满 → 请求堆积 → 系统拥堵
- 单点故障导致服务中断
3. 应对策略
| 措施 | 作用 |
|---|---|
| Nginx反向代理 | 流量分发、限流、熔断、鉴权 |
| CDN加速 | 缓存静态资源，加快访问速度，抵御DDOS |
| Redis缓存 | 缓存热点数据，减少数据库查询压力 |
| 异步化处理 | 使用Kafka/MQ削峰，提升系统响应能力 |
| 微服务架构 | 拆分系统，独立部署与扩展 |
| 无状态设计 | 便于Kubernetes弹性伸缩 |
八、总结口诀
IP域名建网站，DNS解析是关键。
前台后台数据库，SaaS建站最简单。
轮询哈希做负载，四层七层要分清。
冗余备份是高可用，故障转移保运行。
K8s集群自动扩，Redis主从加哨兵。
秒杀并发压力大，CDN缓存来救人。
发表评论