★ FEATURED ARTICLE 简介这份文档面向具备一定IT基础的工程师与架构师聚焦大型网站高性能、高并发、高可用架构设计帮助读者理解分层、分割、分布式、集群、缓存、异步等核心模式并掌握前端、浏览器、应用层、代码与存储各层级的优化策略。内容还覆盖高可用冗余备份与失效转移、CAP理论、可伸缩与可扩展架构、安全体系建设以及电商网站七层逻辑架构的演变实例适合中小型互联网企业扩展或成熟企业应对高流量挑战时参考。资源包为1个docx文档约3.19MB结构完整、条理清晰便于按章节系统学习与查阅。目前已有1124人学习下载读者可从中获得从架构目标到落地实践的完整知识框架理解系统成长轨迹与关键技术选型思路。1. 高性能、高并发、高可用三个词经常被混着说但落地时是三件事很多团队在评审会上把「三高」当成一个词用结果方案写完发现压测 QPS 上去了机器一挂全站雪崩或者做了双机房容灾单机吞吐却卡在数据库连接池上。高性能、高并发、高可用其实是三条正交的约束线——高性能关心单次请求的延迟和单机吞吐高并发关心系统在瞬时流量洪峰下的稳定性高可用关心部分节点故障时整体是否还能对外服务。三者会互相拉扯为了高可用做的同步复制会拖慢写入延迟为了高性能上的本地缓存又可能让多节点数据不一致。这篇笔记面向的是正在做网站架构升级或从零搭建后端系统的工程师尤其是那些已经踩过「单机跑得好好的一上集群就出问题」这个坑的人。我会按「先立住概念和选型逻辑再落到 Nginx、缓存、数据库、容器编排的具体配置和参数」的顺序展开中间穿插一份避坑清单最后给一套可以自己动手验证的压测与故障演练方法。读完你应该能判断自己当前的业务量级该上哪一层哪些组件是现在就该加的哪些是过早优化。2. 从单机到集群分层拆解与 Nginx 接入层的性能账2.1 为什么第一刀要切在接入层绝大多数网站的性能瓶颈不是出在业务代码而是出在请求还没到业务代码就被堵住了。单机时代一个 Tomcat 扛几百并发就到头问题往往不是 CPU 打满而是连接数、线程池、文件描述符这些「看不见的天花板」。接入层独立出来的价值在于把 TLS 握手、静态资源、连接复用、限流这些和业务无关的活儿从应用进程里剥离让应用只处理动态逻辑。Nginx 之所以成为默认选择核心是它的 epoll 事件驱动模型 多 worker 进程架构。每个 worker 是单线程的靠事件循环处理成千上万个连接避免了线程上下文切换的开销。这跟传统「一个连接一个线程」的模型是本质区别。配置上要盯住三个数worker_processes一般设成 CPU 核数worker_connections决定单 worker 能扛多少连接worker_rlimit_nofile要大于前两者的乘积否则会撞上系统的文件描述符上限。# /etc/nginx/nginx.conf 关键片段 worker_processes auto; # 跟随 CPU 核数别手写死数字 worker_rlimit_nofile 65535; # 必须 worker_processes * worker_connections events { worker_connections 10240; # 单 worker 连接上限 use epoll; # Linux 下显式指定避免编译期选错 multi_accept on; # 一次事件循环接受多个新连接 } http { keepalive_timeout 65; # 长连接保持时间太短会频繁握手 keepalive_requests 1000; # 单连接最多复用多少次 client_header_timeout 10s; # 防止慢速攻击占住连接 client_body_timeout 10s; upstream backend { least_conn; # 按最少连接数分发比轮询更抗长尾 server 10.0.0.11:8080 max_fails3 fail_timeout10s; server 10.0.0.12:8080 max_fails3 fail_timeout10s; keepalive 64; # 到后端的连接池减少三次握手 } }这段配置里least_conn和keepalive是两个容易被忽略的点。轮询在请求耗时均匀时没问题但一旦有慢接口轮询会把新请求继续往已经堆积的节点上送least_conn能缓解这个问题。keepalive 64是 Nginx 到上游服务器的连接池大小不配的话每个请求都要重新建 TCP 连接在高并发下 TIME_WAIT 会迅速堆满。2.2 静态资源与动态请求的分流策略接入层配好之后下一步是把流量分类。静态资源图片、JS、CSS、字体走本地磁盘或对象存储动态请求才转发给应用。判断依据是 location 匹配规则但这里有个常见误区很多人用正则匹配后缀性能不如前缀匹配。Nginx 的 location 匹配优先级是精确 ^~前缀 正则 普通前缀能用^~就别用正则。server { listen 443 ssl http2; server_name example.com; # 静态资源强缓存 前缀匹配避免正则开销 location ^~ /static/ { root /data/www; expires 30d; add_header Cache-Control public, immutable; access_log off; # 静态资源不打日志省 IO } # 动态请求转发到 upstream带上真实客户端 IP location /api/ { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 3s; # 连不上后端快速失败别让客户端干等 proxy_read_timeout 30s; proxy_next_upstream error timeout http_502; # 后端挂了自动换一台 } }proxy_next_upstream这行是高可用的第一道保险当某台后端返回 502 或超时Nginx 会自动把请求转给下一台客户端无感知。但要注意它只对幂等请求安全POST 请求重试可能导致重复下单所以更稳妥的做法是在应用层做幂等而不是完全依赖 Nginx 重试。2.3 压测验证别用 ab用 wrk 看长尾配置写完必须验证。ab的问题是它单线程、不支持长连接复用测出来的数字偏乐观。wrk支持多线程和 keepalive更接近真实流量。下面这条命令用 4 线程、200 个连接压 30 秒重点看 Latency 分布的 P99 而不是平均值。# 安装后执行-t 线程数 -c 连接数 -d 持续时间 wrk -t4 -c200 -d30s --latency http://example.com/api/health # 输出里重点看这两行 # Latency Distribution # 99% 45.21ms - P99 超过 200ms 就要查慢查询或锁竞争 # Requests/sec: 18500.32如果 P99 远高于平均值说明有长尾请求通常是数据库慢查询、锁等待或 GC 停顿。这时候不要急着加机器先用pt-query-digest分析慢日志或者用arthas看应用线程栈。加机器只能摊薄平均负载解决不了单点长尾。3. 高并发下的缓存与数据库读写分离、连接池与热点 key3.1 缓存层级的选型本地缓存还是分布式缓存高并发的核心矛盾是「读多写少」场景下数据库扛不住。缓存是第一道防线但本地缓存Caffeine、Guava和分布式缓存Redis解决的是不同问题。本地缓存纳秒级访问但多节点之间不一致适合存配置、字典这类几乎不变的数据Redis 毫秒级访问全局一致适合存会话、热点商品。常见做法是两级缓存本地缓存挡第一层Redis 挡第二层数据库兜底。// Caffeine 本地缓存配置示例 CacheString, Object localCache Caffeine.newBuilder() .maximumSize(10_000) // 超过就按 LRU 淘汰防止 OOM .expireAfterWrite(5, TimeUnit.MINUTES) // 写入 5 分钟后过期 .recordStats() // 开启命中率统计方便调参 .build(); // 读取逻辑本地 - Redis - DB逐级回填 Object get(String key) { Object val localCache.getIfPresent(key); if (val ! null) return val; val redis.get(key); if (val ! null) { localCache.put(key, val); // 回填本地下次更快 return val; } val db.query(key); if (val ! null) { redis.setex(key, 300, val); // Redis 过期时间要短于本地避免脏读太久 localCache.put(key, val); } return val; }这里的关键参数是过期时间的层级关系本地缓存过期时间必须短于 Redis否则 Redis 更新了本地还在用旧值。maximumSize要结合堆内存算一般不超过堆的 10%否则 GC 压力会抵消缓存收益。3.2 缓存击穿、穿透、雪崩的三个具体解法这三个词被讲烂了但落到代码上很多人还是写错。缓存击穿是某个热点 key 过期瞬间大量请求打到数据库解法是加互斥锁或逻辑过期缓存穿透是查一个数据库里也不存在的 key解法是布隆过滤器或缓存空值缓存雪崩是大量 key 同时过期解法是过期时间加随机抖动。import redis, random, time r redis.Redis() def get_with_mutex(key): val r.get(key) if val is not None: return val # 互斥锁只让一个请求去查库其余等待 lock_key flock:{key} if r.set(lock_key, 1, nxTrue, ex10): # ex10 防止死锁 try: val db_query(key) if val is None: r.setex(key, 60, ) # 空值也缓存防穿透 else: # 过期时间加 0~300 秒随机防雪崩 r.setex(key, 600 random.randint(0, 300), val) return val finally: r.delete(lock_key) else: time.sleep(0.05) # 等锁释放后重试 return get_with_mutex(key)nxTrue保证只有一个请求能拿到锁ex10是防止持锁进程崩溃导致死锁。空值缓存是防穿透最省事的办法但要注意空值的过期时间要短否则数据补上了缓存还是空的。3.3 数据库连接池与读写分离的边界应用连数据库必须走连接池直连的话每个请求建连接数据库光握手就累死了。HikariCP 是目前默认选择核心参数是maximumPoolSize。这个值不是越大越好经验公式是CPU核数 * 2 磁盘数但实际要压测确定。设太大反而会因为线程争抢导致响应变慢。# HikariCP 配置 spring: datasource: hikari: maximum-pool-size: 20 # 从 10 开始压测逐步加 minimum-idle: 5 # 保持最小空闲连接避免冷启动慢 connection-timeout: 3000 # 拿不到连接 3 秒就失败别无限等 max-lifetime: 1800000 # 30 分钟短于数据库 wait_timeout leak-detection-threshold: 60000 # 连接泄漏检测60 秒没归还就告警读写分离要注意主从延迟。写主库、读从库在秒杀场景下会出现「刚下单查不到订单」的问题。解法是写后短时间内的读走主库或者用 GTID 判断从库是否追上。这个边界不处理高并发下用户投诉会集中爆发。4. 高可用落地容器编排、健康检查与故障演练4.1 用 Kubernetes 做多副本与自愈高可用的本质是「冗余 自动故障转移」。Kubernetes 的 Deployment 保证副本数Pod 挂了自动重建Service 做负载均衡探针做健康检查。这三个机制配合起来才能实现节点级故障时业务不中断。下面是一个典型的 Deployment 配置重点看探针和资源限制。apiVersion: apps/v1 kind: Deployment metadata: name: web-api spec: replicas: 3 # 至少 3 副本容忍一个节点故障 strategy: rollingUpdate: maxUnavailable: 1 # 滚动更新时最多挂 1 个保证可用 maxSurge: 1 template: spec: containers: - name: api image: registry/web-api:v1.2.0 resources: requests: cpu: 500m # 调度依据设太小会被挤爆 memory: 512Mi limits: cpu: 2000m # 硬上限防止单 Pod 吃满节点 memory: 1Gi livenessProbe: # 存活探针失败就重启 Pod httpGet: path: /health/live port: 8080 initialDelaySeconds: 30 # 给应用启动留时间太短会反复重启 periodSeconds: 10 readinessProbe: # 就绪探针失败就从 Service 摘除 httpGet: path: /health/ready port: 8080 initialDelaySeconds: 10 periodSeconds: 5livenessProbe和readinessProbe的区别是血泪经验存活探针失败会重启容器就绪探针失败只是不转发流量。如果把耗时的依赖检查放在存活探针里数据库一抖动所有 Pod 集体重启反而放大故障。正确做法是存活探针只检查进程本身就绪探针才检查依赖。4.2 健康检查接口该检查什么健康检查接口不是随便返回 200 就行。它要能反映「这个实例现在能不能正常服务」。我一般分两个端点/health/live只返回进程状态永远快速返回/health/ready检查数据库连接、Redis 连接、关键下游任何一个不通就返回 503。// Go 实现的就绪检查 func readyHandler(w http.ResponseWriter, r *http.Request) { ctx, cancel : context.WithTimeout(r.Context(), 2*time.Second) defer cancel() if err : db.PingContext(ctx); err ! nil { http.Error(w, db unreachable, http.StatusServiceUnavailable) return } if err : redisClient.Ping(ctx).Err(); err ! nil { http.Error(w, redis unreachable, http.StatusServiceUnavailable) return } w.WriteHeader(http.StatusOK) }超时设 2 秒很关键。如果检查本身卡住Kubernetes 会认为探针超时效果和失败一样。检查逻辑要轻量别在里面做复杂查询。4.3 故障演练主动杀 Pod 看系统反应高可用不能只靠配置必须演练。最简单的办法是随机删 Pod观察服务是否中断。kubectl delete pod删一个看监控里的错误率曲线。如果错误率有明显尖峰说明就绪探针或连接排空没配好。# 持续删除 Pod模拟节点故障 while true; do kubectl delete pod -l appweb-api --field-selectorstatus.phaseRunning | head -1 sleep 30 done # 同时用 wrk 持续压测观察错误率 wrk -t2 -c50 -d300s --latency http://example.com/api/health演练时重点看两个指标请求错误率和 P99 延迟。理想情况下删 Pod 期间错误率应该接近 0因为流量会被摘除的 Pod 不再接收新请求已有请求靠preStop钩子优雅退出。如果错误率飙升检查是否配了terminationGracePeriodSeconds和preStop。5. 避坑与排查五个真实踩过的坑5.1 现象压测 QPS 上不去CPU 却不高原因通常是连接数或文件描述符撞了上限。检查ulimit -n、Nginx 的worker_rlimit_nofile、以及net.core.somaxconn。另一个常见原因是 TIME_WAIT 堆积net.ipv4.tcp_tw_reuse可以缓解但根本解法是开启长连接。解决逐层检查连接上限用ss -s看连接状态分布。5.2 现象加了缓存后数据库压力反而更大原因是缓存雪崩或缓存击穿。大量 key 同时过期请求全打到数据库。解决过期时间加随机抖动热点 key 用互斥锁重建。另外检查是不是缓存命中率太低用redis-cli info stats看 keyspace_hits 和 keyspace_misses 的比例低于 80% 说明缓存策略有问题。5.3 现象滚动更新时出现 502原因是 Pod 被删时还有请求在处理但 Service 已经把它摘除了。解决配preStop钩子让应用先 sleep 几秒再退出同时terminationGracePeriodSeconds要大于应用处理最长请求的时间。Nginx 侧的proxy_next_upstream也能兜底。5.4 现象主从延迟导致读到旧数据原因是写主读从从库同步有延迟。解决对一致性要求高的读走主库或者用WAIT命令等从库确认。业务上可以接受最终一致的场景前端做「提交中」状态过渡避免用户立刻查询。5.5 现象容器内存超限被 OOMKilled原因是limits设得比实际用量低或者应用有内存泄漏。解决先用kubectl top pod观察实际用量limits设为峰值的 1.5 倍。JVM 应用要配-XX:MaxRAMPercentage让堆感知容器限制否则 JVM 会按宿主机内存算堆大小直接超限。6. 进阶验证用混沌工程给架构做一次体检配置和演练都做完之后怎么判断这套架构真的扛得住我的习惯是引入混沌工程做主动注入。不是等故障发生而是自己制造故障看系统能不能自愈。工具上 Chaos Mesh 和 Litmus 都能在 Kubernetes 里注入网络延迟、Pod 故障、CPU 压力。具体做法是定义一个实验给某个服务的 Pod 注入 200ms 网络延迟持续 5 分钟同时跑压测。观察三个指标——错误率是否超过 1%、P99 是否超过 SLA、熔断器是否触发。如果错误率飙升但熔断没触发说明熔断阈值配错了如果 P99 涨了但没触发扩容说明 HPA 的指标选得不对。# Chaos Mesh 网络延迟实验 apiVersion: chaos-mesh.org/v1alpha1 kind: NetworkChaos metadata: name: delay-test spec: action: delay mode: one # 只影响一个 Pod模拟单点故障 selector: labelSelectors: app: web-api delay: latency: 200ms jitter: 50ms # 加抖动更接近真实网络 duration: 5m scheduler: cron: every 30m # 每 30 分钟自动跑一次持续体检这个实验的价值在于把「高可用」从配置变成了可度量的指标。每跑一次你就知道当前架构的故障容忍边界在哪。我一般会把实验结果记下来和上次对比看架构演进有没有带来实际提升。一个我坚持了很久的习惯每次上线新服务先不接流量用混沌实验打一遍确认探针、熔断、重试都按预期工作再放真实流量进来。这个习惯帮我省掉了至少三次半夜被叫起来处理故障。架构设计不是画完图就结束它得在故障里被验证过才算数。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
)
