搞完这套东西的那天晚上压测同事 P 哥在小群里丢过来一张 JMeter 聚合报告截图我在工位上盯着看了快五分钟没说话。倒不是数据有多漂亮而是屏幕里那套高并发环境两周前还只活在我的笔记本上单节点 K8s、一个改过不少代码的若依微服务全家桶、连个像样的监控面板都没有。现在它被整体搬到了云上 ECS前端入口切换的时候直播间没有停服数据库一条记录都没丢压测一上来 TPS 直接拉到了预期值。直播业务是这样的天然跟高并发绑在一起一场主播开播几万观众涌进同一个房间弹幕刷得屏幕都看不清礼物排行榜每分钟都在变。对这些后端接口来说瞬时流量就像一场集中暴雨。我作为后端开发平时写业务代码没问题但真正要对这套环境做一次从零搭建、迁移、压测验证心里还是有点打鼓。这篇笔记就是想给同类处境的人一点参考没专职运维、没有高可用集群、预算有限靠一台机器也能把直播后台的高并发环境跑起来还能跑得比较稳。这篇文章里我会把整体设计思路、本地环境搭建、云上迁移过程、JMeter 压测方案、Redis 缓存优化以及我们踩过的那些坑一次性讲清楚。适合正在搞前后端分离项目、准备把若依微服务容器化部署或者刚接触压测想搞明白 TPS、响应时间这些指标到底怎么看的后端同学。我不是什么运维大佬这篇笔记也可能没有那些大厂文章的排场但每一条都来自真实操作照着做至少能少走几公里弯路。1. 项目整体设计与思路拆解1.1 直播业务对后台的真正要求直播的高并发和普通高并发不完全一样。普通高并发更多是高并发的读比如秒杀页面、新闻热点大家看的是同一份数据靠缓存就能扛掉大部分压力。直播场景里的并发是读 写 实时互动同时存在观众要刷直播间列表、要拉直播间的详情和在线人数同时还要发送弹幕、送礼、点赞这些写操作实时性强而且集中爆发在同一个房间里。这意味着后台不能只做静态缓存还得考虑消息通道、去重、排行榜合并、数据库写放量这些问题。拿弹幕来说一万个人同时发一条弹幕如果每条都直接写 MySQL数据库连接数瞬间就会被吃满。所以做直播后台的高并发环境第一件事是重新梳理业务的读写路径哪些数据可以走 Redis哪些必须落库哪些能异步就异步。我们这次用的若依微服务版本本质上是一个典型的 Spring Cloud Alibaba 微服务架构接口通过 Gateway 网关统一入口认证走独立的 Auth 服务业务拆成系统服务、文件服务、定时任务等。这套骨架解决的是工程结构问题但不能帮你解决直播间扛不扛得动的问题。真正决定并发上限的是网关之后的每个服务能不能把压力分散掉以及 Redis、数据库这些底层组件有没有配置到位。所以我在项目启动时给自己定了三个目标第一把整套微服务跑进 K8s镜像化部署为后续扩容留后路第二做一次完整的线上迁移演练从本地环境搬到云上 ECS而且要尽可能不停服、不丢数据第三用 JMeter 做一轮贴近真实直播场景的高并发压测拿到可量化的指标而不是凭感觉说应该能扛住。1.2 技术栈选型为什么是若依微服务 单节点 K8s选择若依微服务版坦白说不是因为它高并发能力有多强而是因为它把微服务的基础设施都铺好了Nacos 做注册中心和配置中心Gateway 做统一网关Sentinel 可以接流量控制还有现成的认证中心、后台管理界面。对一个后端小白来说这套东西能帮我省掉大量从零搭微服务的重复劳动我可以把精力放在直播高并发这个真实问题上而不是去纠结服务发现怎么写。K8s 单节点听起来不够高级但它是我当时唯一现实的选择。我们没有预算去搞三节点起步的集群而且业务量也还没到非要多节点不可的程度。单节点 K8s 的好处是可以完整体验容器编排、滚动更新、副本调度这些核心机制后续如果流量涨起来了多节点无非是再加 worker 节点应用部署方式不用改变。说白了K8s 的核心价值不是我有很多机器而是我的应用定义与机器无关单节点就是这个价值的最小可行验证。直播高并发的压力点通常在网关上所有请求都要经过 Gateway 转发如果网关的性能不行后面服务再强也白搭。所以在选型和调优上我们颇为关注 Gateway 这一层的线程配置和超时设置。另外直播业务里 Nacos 和 Redis 一旦挂了整个微服务会因为服务发现失败、缓存崩塌而雪崩所以本地环境验证时我会先把这两类中间件压一遍确保它们不成为瓶颈。1.3 迁移方案的整体思路先摸清家底再平滑搬家很多人一想到迁移第一反应就是拿一个新环境把服务全部重新部署一遍然后把流量切过去。这个思路本身没错但落地过程中最容易翻车的是细节数据库里的用户数据、直播间配置、聊天记录哪个文件落下了都会出问题。而且直播业务的特点是持续写停服五分钟都会有一大批数据产生你没有备份的话就永久丢了。我们的迁移思路分四步走。第一步盘点当前环境里到底有哪些持久化数据MySQL 里的用户、房间、订单Redis 里的弹幕窗口、排行榜、Token 缓存还有文件服务里存的主播封面、直播回放第二步做全量备份记录当时的 binlog 位点为增量同步做准备第三步在云上把整套环境搭起来先把全量备份恢复进去再用 binlog 把增量数据追平第四步找一个低峰期切换流量同时保留原环境一段时间做回滚兜底。这样做的核心逻辑是先让新环境的数据无限接近旧环境再切换流量数据一致性才有保障。这个过程里不停服并不是指全程一秒都不停而是指用户侧的直播观看和弹幕发送不中断后台服务滚动更新时可能有几百毫秒的抖动但不会出现服务直接下线的硬停机。2. 本地环境验证先把地基打牢2.1 开发环境清单与版本对照磨刀不误砍柴工迁移到云上之前必须在本地先把整套微服务跑起来验证一遍。如果你连镜像都没有到云上一旦出错排查起来会非常痛苦因为你分不清是云环境的问题还是应用本身的问题。我本地的环境大概是这样的一台 16G 内存的笔记本装了 Docker Desktop开了 K8s 单节点模式操作系统 Windows 11但这不关键Linux 上操作完全一样。版本对照我建议固定下来避免后面莫名奇妙的兼容性问题。我这边用的是 JDK 8 Maven 3.6.3 编译后端前端用 Node.js 16 构建 Vue 项目MySQL 8.0Redis 6.2Nacos 2.2.0K8s 用的是 Docker Desktop 自带的 1.24 版本。这里有个经验软件版本尽量跟项目原先保持一致尤其是 MySQL 和 Redis主从同步和数据结构都有兼容性问题跨大版本迁移容易出现隐藏坑。在本地验证阶段我强烈建议把整个服务端分成三条链路来测认证链路前台登录、获取 Token、业务链路直播列表、房间详情、发送弹幕、管理链路后台管理、数据统计。每条链路能从浏览器或者接口工具上跑通才算环境合格。我当时用 Apifox 跑接口把所有模块的接口都过了一遍然后把端口映射、跨域配置、Nacos 注册状态这些细节全部记录下来后面到云上有对比的基准。2.2 容器化重构把前端和后端分别打成镜像若依微服务项目默认给你的是源码和 Dockerfile但直接拿默认的 Dockerfile 去打包会遇到很多问题。第一个是基础镜像太大若依后端默认用的 Java 镜像动不动就 500M 起步传到云上慢还不说启动也慢。我后来把基础镜像换成了 eclipse-temurin:8-jre 这种精简 JRE 镜像体积能减不少前端则换成了 nginx:alpine配合多阶段构建把 node 编译阶段和 nginx 运行阶段分开。多阶段构建对前端项目特别香。以前的方案是在宿主机装 Node 环境、把代码编译成静态文件再把静态文件复制进 nginx 镜像一旦环境不一致就会出现二进制差异。用了多阶段构建之后一个 Dockerfile 就能完成编译 打包两个步骤镜像里只保留 nginx 和编译产物构建过程可复现到云上不会出现我本地能跑环境里不能跑的诡异问题。后端镜像构建相对简单但有几个点要特别注意配置文件的注入方式。我建议把 application.yml 中容易变化的内容用环境变量代替比如 Nacos 地址、数据库地址、Redis 地址这样同一个镜像可以在本地和云上共用只要在 K8s 部署时传不同的环境变量就行。这个设计在迁移到云上时帮了大忙因为我们不用为云环境单独重新 build 一套镜像。2.3 单节点 K8s 上的部署清单K8s 部署我们不追求一次写对而是先把最小可用集跑起来再逐步补。RuoYi-Cloud 涉及的微服务大概有nacos、gateway、auth、system、file、job、monitor加上前端 ruoyi-ui还有 MySQL 和 Redis。我建了一个叫 live-prod 的命名空间把所有和直播环境相关的服务都放进去这样后续清理和监控都方便。每个服务我都会写一个 deployment.yaml 文件里面至少包含 replicas 数量、镜像地址、容器端口、环境变量、资源和健康检查。健康检查我强烈建议加liveness 探针和 readiness 探针分别管容器要不要重启和流量要不要打进来直播这类对可用性要求高的业务没有健康检查的话服务挂了你都不知道。一个典型的后端 deployment 片段大概是这样的apiVersion: apps/v1 kind: Deployment metadata: name: ruoyi-system namespace: live-prod spec: replicas: 2 selector: matchLabels: app: ruoyi-system template: metadata: labels: app: ruoyi-system spec: containers: - name: ruoyi-system image: registry.cn-hangzhou.aliyuncs.com/live-demo/ruoyi-system:latest ports: - containerPort: 8080 env: - name: SPRING_PROFILES_ACTIVE value: prod - name: NACOS_ADDR value: nacos.live-prod.svc.cluster.local:8848 resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1 memory: 1Gi readinessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 30 periodSeconds: 10PostgreSQL、Redis 这些中间件同样建议以 Deployment Service 的方式跑在 K8s 里。本地环境数据量不大直接用 emptyDir 或者 hostPath 存数据就行但到了云上迁移阶段数据存储必须用云盘或者至少是独立的数据目录否则 Pod 一重建数据就没了这属于基础中的基础。2.4 本地先跑一轮冒烟验证把全部服务部署起来之后最怕的是每个服务自己看起来都是 running但放在一起根本不工作。我记得第一次把全套服务起在 K8s 里Gateway 一直报找不到实例折腾了半天才发现是 Nacos 里注册的 IP 是容器内网 IP而 Gateway 在另一个网络环境下去访问这个 IP 根本不通。这种问题在裸机上跑不会遇到到了容器环境必须重新理解网络模型。冒烟验证我一般按这个顺序执行先看 Nacos 控制台确认所有微服务都注册上来然后直接访问 Gateway 的地址测试认证接口能否正常返回 Token再用一个带 Token 的请求去调业务接口比如获取直播列表最后打开前端页面走一遍登录和直播间的操作。只要这几个核心链路通了环境就算基本可用。值得注意的是本地验证阶段不要急着做大并发压测因为 Docker Desktop 自带的 K8s 在 macOS 或 Windows 上跑性能损耗不小压出来的数据没有任何参考价值。本地验证的核心目的是把部署流程跑通把所有配置摸清云上压测的数据才是有意义的。3. 云上迁移实战不停服、不丢数据3.1 迁移前的数据备份与位点记录迁移第一步永远是数据备份这一点在直播业务里尤其重要。我们的数据主要分三块MySQL 里的业务数据Redis 里的缓存数据以及文件系统里的静态资源。MySQL 我用的方法是先用 mysqldump 做全量逻辑备份然后在备份的同时记录 SHOW MASTER STATUS 里的 binlog 文件名和 Position这个位点就是增量同步的起点。这里有个容易踩的坑直接对运行中的 MySQL 做 mysqldump备份的数据可能是不一致的因为直播期间一直在写。所以备份时尽量加上 --single-transaction --set-gtid-purgedOFF 参数用 InnoDB 事务保证一致性快照。Redis 相对简单直播场景下 Redis 里大部分是缓存数据丢了也能重新生成只有少量比如弹幕最近消息、排行榜中间值需要保留直接用 BGSAVE 导出 RDB 文件就行。文件服务这块经常被忽略。若依的文件服务默认把上传文件存本地磁盘里面可能有主播的头像、直播间的封面图、直播回放视频。迁移前要把这个目录完整打包用 rsync 或 tar 传输到云上对应目录同时确认文件服务在代码里读取的是哪个路径别等用户反映图片挂了才发现路径对不上。3.2 镜像与配置的云端初始化数据备份完之后开始搭云端的运行环境。我们没有用很复杂的方案就一台阿里云 ECS8 核 16G系统盘 40G再加一块数据盘。系统盘只放操作系统和 Docker数据盘单独挂载给 MySQL、Redis 和文件服务。这样设计的考虑是如果系统出问题要重装数据盘不受影响数据安全多一层保障。云端初始化我是这么做的先装 Docker 和 K8s 相关的运行时我图省事直接用了阿里云 ACK 的托管版不题目说单节点自建所以还是自己在 ECS 上装 Kubeadm 初始化单节点集群。第一次初始化确实踩了不少坑主要是 kubelet 需要关 swap、需要配置 CRI 驱动等这些归属于 K8s 部署的基础常识我在这里就不展开说重点是后面的迁移动作。镜像的搬运方式要根据网络环境来定。如果云上能拉 Docker Hub 或私有仓库那最理想的做法是把镜像推到统一的镜像仓库里比如阿里云 ACR然后云上节点直接拉取。如果网络条件差也可以 docker save 打成 tar 包再 docker load但镜像一多时这个过程会很痛苦。我们当时直接用 ACR把本地打好的镜像全部 push 上去再在 ECS 上 pull速度快还省心。配置方面我强烈建议把所有可变配置收敛到 Nacos 配置中心而不是散落在各个服务的 application.yml 里。迁移时只需要修改 Nacos 里的配置把数据库地址、Redis 地址、文件路径指到云端的新资源然后各服务从 Nacos 拉取最新配置。这样能避免改了几十个配置文件、漏改一个导致线上出问题的低级事故。3.3 无感切换从增量追平到灰度放量云端环境起好之后我们面临一个关键问题怎么把线上流量从旧环境切到新环境同时尽量不影响正在进行的直播。我们的做法是先做全量数据恢复再启动增量同步等两个环境的数据差缩小到几秒内才在低峰期做切换。增量同步这一块我们用了 MySQL 的 binlog 同步思路在源库开启 binlog用一个轻量的同步脚本持续解析 binlog 里的变更事件把新的 SQL 操作转发到云端的 MySQL。这种方案不依赖第三方工具理解起来简单逻辑也很透明。同步过程中要持续对比两个库的关键表行数比如直播间表、用户表、订单表确认数据量基本一致。切换动作我设计成两步走。第一步让前端管理后台和用户端的一部分请求先打到云端环境比如先切 10% 的流量过去观察接口报错率和日志如果没问题再逐步放大比例。第二步全面切换域名解析或网关地址让所有流量都走云上环境。整个切换过程用户几乎没有感知。对直播后台来说最怕的是正在看直播的用户忽然断流所以切换前我特意确认了文件服务和直播流相关的接口在云端已经就绪避免出现后台能进去但视频拉不出来的尴尬。3.4 迁移之后的健康检查清单切换完成不等于迁移结束后面至少还有两三天的高频观察期。我给自己列了一个健康检查清单每天定时执行一遍第一所有微服务在 Nacos 里的注册状态是否正常有没有服务掉线第二MySQL 的连接数、慢查询数量和主从延迟是否在正常范围第三Redis 的内存使用率和命中率有没有异常的大 key第四文件服务的磁盘空间是否充足回放文件有没有正常写入第五通过前端页面走一遍完整的直播流程从用户登录、进直播间、发弹幕、看回放确保端到端没问题。还有一个容易忽略的细节是日志。云端的日志尤其是 Gateway 和认证服务的日志要确认能正常输出并且检查是否有大量 401、500 错误。这些错误在迁移初期很常见通常是 Token 加密密钥不一致、跨域配置遗漏等问题多看看日志能快速定位。我们在迁移后的第一天就发现 Auth 服务刷了比较多 401 日志排查后才知道是 Nacos 配置中心的 JWT 密钥跟旧的默认值不一致改回来就恢复正常了。4. JMeter 高并发压测拿数据说话4.1 压测场景设计从登录到直播互动压测之前我专门找直播业务的同事聊了一下到底哪些接口最怕高并发。他说得挺直白最怕的是开播瞬间大量观众涌入进入直播间和发弹幕这两个接口会瞬间飙到极限其次是直播间列表和礼物排行榜属于高频刷新类接口。所以我们把压测场景定为四个登录获取 Token、拉取直播列表、进入直播间获取详情、发送弹幕。场景设计是压测里最影响结果真实性的一环。我当时给 P 哥提的要求是并发模型要模拟真实用户行为不能所有线程都打同一个接口这样出来的数据没有参考意义。于是我们设计了四个线程组分别对应四类用户操作通过 JMeter 的 CSV Data Set 参数化模拟不同用户 ID、不同房间 ID。压测比例上登录占 20%直播列表占 30%进入直播间占 30%发送弹幕占 20%整体更贴近一个直播间的真实流量构成。同时要设置一个压测目标没有目标的压测只是乱打。我们定的目标是支持 3000 并发用户同时在线操作核心接口 P95 响应时间低于 800ms接口错误率低于 0.5%系统不出现 Crash 或 OOM。这样后期看报告的时候每一个数字都有明确的判定标准而不是好像还行。4.2 JMeter 脚本关键配置线程组与参数化JMeter 脚本的编写不算复杂但有几个参数特别值得重视。线程组里我一般用线程数表示并发用户数Ramp-Up Period表示线程启动时间。这里有个常见的错误认知线程数设成 5000Ramp-Up 设成 1 秒这等于让 5000 个请求同时打进来对于真实场景而言过于残酷。真实用户是陆续进来的所以 Ramp-Up 一般按总并发数 / 每秒钟启动 100 个左右来设比如 3000 并发Ramp-Up 设为 30 秒更符合开播瞬间用户涌入的节奏。参数化是另一个关键点。我们给登录接口配置了 CSV Data Set里面准备了 3000 个测试账号每个线程从 CSV 里取一个账号来登录避免所有线程共用一个账号导致数据错乱。直播列表和弹幕接口则需要参数化房间 ID否则所有请求都打向同一个房间那不是在压测系统性能是在考验单房间的性能极限。JMeter 的断言和监听器也要提前配好。断言方面登录接口一般断言返回的 Token 字段不为空弹幕接口断言返回码为 200监听器方面聚合报告和查看结果树是基础配置但我们还接了一个 Backend Listener把压测指标实时推到 Grafana 上一边压测一边看曲线这样比压完再看报告直观得多。压力机这里还有一个大坑单台 JMeter 机器的最大端口数有限默认只有 28232 个可用端口压到几千并发时经常报 No buffer space available 这种错解决办法是用多台压力机做分布式压测或者调大本机临时端口范围。4.3 怎么读压测报告TPS 与响应时间的判定逻辑压测结束之后P 哥把聚合报告发到群里上面有 Samples、Average、Min、Max、Std. Dev.、Error%、Throughput、Received KB/sec 这些列。里面最关键的三个指标是 Error%错误率、Throughput吞吐量也就是 TPS和响应时间分布。只看 Average 是不够的因为平均值会被少数超长请求拉高我的习惯是重点看 90% 或 95% 响应时间聚合报告里可以直接加一个 90% Line 和 95% Line 列。举一个实际结果3000 并发下登录接口 TPS 有 380/sP95 响应时间 420ms错误率 0%直播列表接口 TPS 到 1200/sP95 是 260ms这是因为我们加了 Redis 缓存把大部分请求挡在了数据库前面发送弹幕接口 TPS 只有 160/sP95 到了 3s这一下就暴露了问题。如果不看分位值只看平均响应时间 1.5s会以为只是有点慢但 P95 到 3s说明大部分用户体感已经卡顿了这种场景必须优先优化。压测报告不是只看数字就完事要对照着看后端监控。当时弹幕接口 P95 升高我们同时发现 MySQL 的 CPU 使用率飙到了 90%慢查询日志里出现大量 INSERT 语句排队这说明是写库路径有问题而不是网络或带宽问题。这就是压测 监控双管齐下的意义数据告诉你现象监控告诉你原因。4.4 压测中发现的瓶颈与优化调整第一轮压测下来我们发现了三个明显瓶颈按严重程度排序弹幕发送接口写库太慢、直播间详情接口没有缓存导致查询压力大、Gateway 默认线程池在高并发下出现排队。这三个问题在普通业务里可能感知不强但直播间场景一放大就特别明显。弹幕接口优化的思路是异步化 合并写。我们不再让每次发送弹幕都同步写 MySQL而是先把弹幕写到 Redis 的 List 里由定时任务每隔几秒批量同步到数据库。这样用户的发送请求只跟 Redis 打交道Redis 的写性能比 MySQL 高一个量级P95 从 3s 降到了 350ms。为了不丢弹幕Redis 持久化开启了 AOF每秒钟 fsync 一次确保宕机最多丢一秒的弹幕数据能接受。直播间详情接口优化就简单了按房间 ID 做 Redis 缓存TTL 设成 30 秒 随机 10 秒的偏移避免同一时间大量缓存过期导致数据库压力瞬间飙升。Gateway 的优化则是调整了 Tomcat 线程池参数把 max-threads 从默认 200 调到 400同时把连接超时和读超时调得更合理。第二轮压测时整体 TPS 从原来不到 1500 拉到了接近 4000P95 基本控制在 600ms 以内才达到我们预期的上线标准。5. Redis 缓存设计与高并发优化5.1 直播场景的缓存热点分析直播后台做高并发的核心本质上就是把热点数据尽量拦截在 Redis 这一层。直播场景里的热点非常集中主要集中在三类数据直播间列表、直播间详情标题、封面、在线人数、主播信息、互动数据弹幕、礼物排行榜。这三类数据的共同特点是读操作超高、写操作相对少非常适合用缓存来扛。互联网上有很多现成的缓存方案但直播场景有自己的特殊性热点会瞬间转移。比如某个大主播突然开播这个房间的详情和在线人数会成为超级热点如果所有请求都穿透到数据库数据库很快就会被击穿。所以我们针对直播间详情做了一个本地缓存 Redis 缓存两级缓存本地缓存用 Caffeine设置 5 秒过期Redis 设置 30 秒过期数据更新时主动失效。这样即使某个房间热度极高大部分请求也只会打到 Caffeine 上Redis 和数据库压力非常小。弹幕是另一个典型场景。弹幕的时效性极强超过 20 秒的弹幕基本没人会往回看。所以我们的弹幕缓存策略是用 Redis 的 List 保存最近 1000 条弹幕配合 LTRIM 命令只保留最新的用户进入直播间时直接读取这个 List 返回根本不会去查数据库。发送弹幕时直接 LPUSH 到 List再通过消息机制广播给在线用户数据库的写入全部异步执行这样就实现了读不穿透、写不阻塞。5.2 缓存穿透、击穿、雪崩的应对方案这三个名词听起来唬人但在直播场景里都是真实会遇到的。缓存穿透指的是恶意用户疯狂请求一个不存在的房间 ID缓存里没有数据库里也没有所有请求直接打到数据库。我们在进行直播回放文件播放的鉴权接口时遇到过这种情况。解决办法是对空结果也做缓存比如房间 ID 不存在时Redis 里缓存一个空值过期时间短一点30 秒同时用布隆过滤器对所有合法的房间 ID 做一个过滤请求进来先查布隆过滤器不存在的 ID 直接拒绝不进入数据库。缓存击穿是在缓存过期的一瞬间大量请求同时打到一个热点 key 上导致数据库瞬间压力暴涨。这个在直播间详情接口特别常见因为直播间热度高大家同时刷新页面。我们的方案是用互斥锁也就是 Redis 的 SETNX当缓存失效时只有一个请求能拿到锁去查数据库其他请求先等一小段时间再重新查缓存而不是全部打在数据库上。这样 DB 压力就从瞬间蜂拥变成了单点加载。缓存雪崩是大量 key 在同一时间段内集体过期整体缓存失效导致数据库扛不住。这个问题的常规解法是过期时间加随机值我们把过期时间都设成基础 TTL 随机 0~60 秒避免所有 key 同时过期。另外我们的缓存服务本身加了高可用配置避免 Redis 单点故障导致整体缓存不可用。当然没有一劳永逸的银弹这些方案组合起来至少能保证直播间高并发场景下数据库不会因为缓存问题被压垮。5.3 结合若依项目落地缓存改造若依框架本身已经有比较完整的缓存工具类基于 Spring 的 RedisTemplate 封装了 get、set、expire 等方法基础够用。但直播高并发场景下我建议在业务层再做一层相对独立的缓存服务把直播数据的缓存逻辑统一收敛不要散落在各个 Controller 里。我当时建了一个LiveCacheService专门负责直播间列表、详情、排行榜、弹幕窗口的读写和过期管理。这里分享一个结合若依实际业务改造的案例。原生的若依代码里用户 Token 是存在 Redis 里的key 格式大概是 login_tokens这个逻辑保持不变但要确保 Redis 的内存足够并且有淘汰策略。我们的 Redis 设置了 allkeys-lru 淘汰策略这样即使 Token 数量暴增Redis 也会优先淘汰不活跃的 key不会因为内存满而崩溃。弹幕列表和排行榜这些 key 则设置了合理的 TTL并且监控大 key避免某个直播间的弹幕 List 无限增长拖慢 Redis。改造完之后我们做了一次缓存命中率的验证从压测报告看直播列表接口的数据库 QPS 只有 50 左右而接口请求量是 1200/s也就是说超过 95% 的请求都被缓存拦截数据库基本无压力。这是一个非常健康的状态也是直播高并发后台应该达到的效果不要用数据库去硬扛流量把 Redis 的价值用足。6. 常见问题与排查技巧实录整个搭建和迁移过程里踩过的坑比预想中多不少这里挑几个最有代表性的记录下来给后来人当排查手册用。第一个问题是服务都部署了但 Gateway 转发到服务时报 503。排查思路从服务注册状态开始先看 Nacos 控制台如果发现服务列表为空说明服务注册失败大概率是 Nacos 地址没配对或者服务启动时没有连上配置中心。如果服务已经注册但 503就要检查 Gateway 所在容器能否访问到服务 Pod 的 IP可以通过 kubectl exec 进网关容器用 curl 访问服务的 Service 名加端口能通就说明网络正常就要查 Nacos 里注册的 IP 是不是容器外网不可达的 IP。第二个问题是压测时 MySQL 连接数被打满。当时所有服务的数据库连接池默认值都是 20四个服务叠起来也就 80 个连接但压测一上来每个请求都占着一个连接排队越来越严重。排查时我们用 SHOW PROCESSLIST 看到大量 Sleep 状态的连接最后做了两件事把连接池最小值调低、最大值调到 50同时给 MySQL 设置了 max_connections 为 500并在压测前提前建立连接预热。这里的关键经验是连接池大小不是越大越好过大的连接池反而会让数据库调度变慢。第三个问题是前端页面在云上访问时出现跨域报错接口能通但浏览器拦截。若依前后端分离项目跨域问题很常见我们排查时先看后端 Gateway 的跨域配置再看 nginx 的反向代理配置是否正确。最终发现是因为配置文件里的 allowedOrigins 还停留在本地 localhost没有把云上域名加进去。建议在 Nacos 里把跨域配置做成可配置项用环境变量区分不同环境的域名避免每次迁移都要改代码重新打包。第四个问题是文件服务存到了旧环境路径导致迁移后图片和回放全部 404。这个属于低概率但危害极大的问题起因是文件服务的 application.yml 里写死了本地磁盘路径没有用环境变量。迁移中最稳妥的做法是在代码里把文件存储路径抽象成配置项并在部署时通过环境变量注入。这样不管是本地、测试还是云端同一套镜像都能正确指向不同的存储位置。我把这些问题整理成一张速查表方便对照排查问题现象可能原因排查命令/方法解决思路Gateway 503服务未注册到 Nacos或注册 IP 网络不通查看 Nacos 服务列表进入网关容器 curl 服务地址修正 Nacos 地址调整网络配置检查跨命名空间访问MySQL 连接数满连接池配置过大或慢查询占用连接SHOW PROCESSLIST查看慢查询日志调优连接池参数优化 SQL 和索引限制单服务连接数前端跨域报错Gateway 或 nginx 的跨域配置不全查看浏览器控制台检查网关配置将跨域域名改成环境变量在不同环境注入不同取值图片/回放 404文件服务存储路径配置错误检查文件服务的日志和磁盘目录抽象存储路径为配置项按环境注入接口 P95 飙高缓存未生效或数据库慢查询查看 Redis 命中率抓取数据库慢查询补充热点缓存异步化写请求调整 index弹幕延迟高同步写库导致阻塞查看 MySQL 写入耗时Redis 延迟弹幕写入改走 Redis异步批量落库还有一个小技巧值得单独拿出来说调整 JVM 参数。若依微服务默认的 JVM 堆内存可能只有几百兆在高并发压测时很容易出现 Full GC表现为接口突然卡顿几十秒然后恢复。我们在压测后统一把每个服务的 JVM 初始堆和最大堆设置为 1G 到 2G同时在 Kubernetes 的 Deployment 里通过 JAVA_OPTS 环境变量注入这些参数不同于改代码这样运维成本非常低。个人体会是单节点 K8s 环境下排查网络问题最容易绕弯。容器和容器、容器和宿主机之间的通信方式跟裸机不一样出问题时先用 kubectl describe pod 和 kubectl logs 看当前资源状态和日志再结合 Nacos 里的注册 IP、Service 名解析是否正常来判断。很多时候看似程序 bug的问题实质上是部署层面的网络配置或资源限制问题。最后再分享一个经验不要等到全链路压测才去关注性能。直播高并发环境下任何一个细小的设计问题都会被流量放到几十倍。比如一个接口本来只查一次 MySQL你觉得无所谓但 1000 并发时这个多出来的查询就会成为压倒数据库的最后一根稻草。做这套直播高并发环境的整个过程给我最大的感受是后端开发的成就感不只在把功能写完更在于想办法让你的系统在压力面前还站得住。数据不丢、服务不挂、用户不卡这些比任何技术名词都更有说服力。