三年前我还是个只会写增删改查的后端小白结果产品经理甩来一句话“直播间要做高并发你负责搭环境。”当时我连“高并发”三个字背后意味着什么都说不清楚更别说一套直播推拉流、弹幕、礼物系统的完整链路。硬着头皮从零开始前后折腾了大半个月把服务器、缓存、队列、直播流服务、压测工具全部过了一遍最终用 8 核 16G 的云服务器扛住了模拟直播场景下的数千并发请求。今天把这段经历整理出来给同样从后端起步、想搞懂直播高并发环境搭建的同学一个完整参考。这篇文章会围绕“直播高并发环境”这个核心串起我从需求分析、技术选型、环境搭建、缓存与异步设计再到 jmeter 压测验证的完整过程。既有配置细节也有踩坑实录还会讲清楚每个环节“为什么这么做”。适合刚接触后端、想独立做一个小型直播系统或者在准备后端相关面试时需要实战谈资的同学。1. 项目整体设计与方案选型1.1 先搞清楚直播系统到底有哪几条链路我一开始犯的最大错误是以为“直播高并发”就是把服务器带宽拉满然后拼命堆 Nginx 转发。真正动手后才发现直播系统至少分三条完全不同的链路每条链路的压力模型都不一样。第一条链路是视频流链路从主播推流到转码、分发、观众拉流这本质上是超高带宽和低延迟问题对服务器 CPU 和网卡的要求远高于普通业务接口。第二条链路是业务接口链路包括用户登录、进入直播间、发送弹幕、送礼、点赞、关注等操作这才是后端同学最需要关心的“高并发”主战场。第三条链路是数据与状态同步链路比如在线人数统计、弹幕广播、礼物排行榜它既要有实时性又要保证最终一致性。传统“一个 Web 容器裸跑业务”的做法在这三条链路同时压过来时必定崩。所以方案设计的核心思路是视频流量走独立代理层业务流量走负载均衡热点数据全部打散到缓存写操作全部异步化。把这三件事想清楚整套架构的骨架就出来了。1.2 技术选型思路不追新只追稳做技术选型时我给自己定了一条规矩所有组件必须是文档多、社区活跃、踩坑经验丰富的方案。作为一个后端小白我没有能力也没必要去啃冷门技术能快速跑通、遇到问题能搜到答案才是第一位的。最终敲定的组件列表是这样的层次选型理由业务开发Spring Boot 2.7 JDK 8生态成熟资料多小白友好数据库MySQL 8.0直播回放、用户信息、订单记录缓存Redis 6.2扛热点读、计数、排行榜、分布式锁队列RabbitMQ 3.12弹幕异步落库、礼物订单削峰反向代理Nginx 1.24静态资源分发、反向代理、简单限流直播流服务SRS 5.0先试过 nginx-rtmpRTMP 推流、HLS/HTTP-FLV 拉流、低延迟压测工具Apache JMeter 5.x免费、支持高并发脚本、结果可视化这里需要单独说说直播流服务的选型。我最初图省事用 nginx-rtmp 模块但它是单进程模型并发拉流一上来CPU 就冲到 90%后来切到 SRS 才真正解决问题。SRS 是国人开源的高性能流媒体服务器支持 RTMP、HLS、HTTP-FLV 等多种协议配置简单对中小直播场景非常友好实测在相同机器上承载的拉流并发数比 nginx-rtmp 高好几倍。选型的时候还有个心法不要因为某个组件“高级”就用它。比如当时有人建议我用 Kubernetes但只有两三台服务器上 K8s 反而徒增复杂度。先把单机压榨到极致再考虑分布式扩展这才是小团队最务实的路径。1.3 高并发架构的整体轮廓所有组件确定后我画了一张架构草图虽然画得难看但起到了关键作用主播端通过 RTMP 协议推流到 SRSSRS 负责将视频流转成 HTTP-FLV 和 HLS 输出Nginx 对拉流请求做负载均衡和缓存业务请求则统一走 Nginx转发给后端的 Spring Boot 服务集群Redis 放在业务层和数据库中间挡住绝大多数热点读请求写流量通过 RabbitMQ 削峰数据库只处理最终落盘。这张图让我想明白了一个重要问题高并发不是靠某一个组件而是靠每一层分工。Nginx 挡流量SRS 处理流Redis 挡热点MQ 削峰数据库只干自己的活各层之间用清晰的协议衔接。后面所有开发和调优都是围绕让每一层“专注”展开的。2. 服务器初始化与基础组件搭建2.1 云服务器的基础初始化要点我用的是一台 8 核 16G 的云服务器 ECS系统盘 40G数据盘 100G带宽按量付费跑到 100Mbps。说实话这个配置不算高但用来验证高并发思路完全够用。系统我选了 CentOS 7.9虽然官方已经停止维护但网上资料最多遇到问题搜起来最方便。拿到一台裸机后初始化顺序很重要我的操作流程是更新系统源并安装基础工具yum update -y yum install -y wget vim net-tools telnet lrzsz创建专用的部署用户我用的deploy拒绝 root 直接跑服务降低误操作风险修改 SSH 配置关闭 root 密码登录改用密钥登录配置防火墙只放行 22、80、443、1935RTMP、8080 等必要端口挂载数据盘到/data目录把 MySQL、Redis 的数据目录都指向这里避免系统盘写满这里有个特别容易忽略的坑云服务商的安全组和服务器内部的 firewalld/iptables 是两层概念必须同时放行端口才有效。我第一次部署完发现 1935 端口不通排查半天才发现是安全组没放行而不是防火墙的问题。2.2 JDK、MySQL、Redis 的安装与基础调优JDK 没太多可说的解压、配环境变量、java -version验证即可。我统一用 JDK 8因为它和 Spring Boot 2.7 配合最稳定。MySQL 8.0 的安装我用的是官方 yum 源但有几个参数必须调整否则高并发下数据库很容易成为瓶颈。核心配置我改成了这些[mysqld] max_connections 1000 innodb_buffer_pool_size 4G innodb_flush_log_at_trx_commit 2 innodb_log_file_size 512M sync_binlog 0 character-set-server utf8mb4这里解释一下innodb_buffer_pool_size一般设置为物理内存的 50%-70%4G 对于 16G 内存的机器是合理的innodb_flush_log_at_trx_commit 2表示每秒刷一次磁盘牺牲极少的持久性换取大幅性能提升直播场景下的非关键数据完全可以接受sync_binlog 0同理适合对一致性要求不是最高的写入场景。Redis 的安装更简单源码编译或 yum 安装都行。但配置里我强制开启了appendonly yes避免重启丢数据。另外设置了maxmemory 4gb和maxmemory-policy allkeys-lru防止缓存数据无限增长把内存撑爆。2.3 Nginx 安装与反向代理配置Nginx 我直接用官方源安装版本 1.24。配置层面的重点有两块一是作为业务接口的反向代理二是作为拉流入口的流量分发。业务接口的 Nginx 配置核心大概长这样upstream live_backend { server 127.0.0.1:8080 max_fails3 fail_timeout30s; keepalive 64; } server { listen 80; server_name api.example.com; location /api/ { proxy_pass http://live_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 5s; proxy_read_timeout 10s; } }这里有个经验之谈keepalive 64能让 Nginx 和后端服务之间维持长连接避免每次请求都重新建立 TCP 连接。我在压测时对比过开启 keepalive 后接口的吞吐量提升了将近 40%。2.4 直播流服务从 nginx-rtmp 到 SRS视频链路是我花时间最多的地方。一开始我用 nginx-rtmp 模块配置确实简单加上几行就能实现 RTMP 推流和 HLS 播放rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; hls on; hls_path /data/hls; hls_fragment 2s; hls_playlist_length 6s; } } }跑通推拉流之后我用 jmeter 过了压力测试发现 nginx-rtmp 的并发拉流能力非常弱CPU 单核直接打满延迟还不断飙升。查资料才发现 nginx-rtmp 是单进程模型对多核服务器利用率极差。切到 SRS 之后配置文件看起来更“宏大”但逻辑很清晰# srs.conf listen 1935; max_connections 10000; srs_log_tank file; srs_log_file /data/logs/srs.log; http_api { enabled on; listen 1985; } vhost __defaultVhost__ { http_remux { enabled on; mount [vhost]/[app]/[stream].flv; hstrs on; } hls { enabled on; hls_path /data/hls; hls_fragment 2; hls_window 6; } }SRS 的多进程模型确实能充分利用多核 CPU同样配置下拉流并发从几百涨到了几千。另外一个好处是 SRS 自带 HTTP API可以直接查询在线流数、连接数做监控非常方便。3. 高并发核心缓存设计与异步化改造3.1 Redis 到底在扛什么数据环境搭好了业务接口也上线了但压测一跑立刻发现所有请求直接打到 MySQL数据库连接瞬间耗尽接口大量超时。这个阶段的教训非常深刻没有缓存的架构在高并发场景下形同虚设。在直播场景下我用 Redis 缓存了三类核心数据。第一类是直播间的元数据包括房间名称、主播信息、封面图、公告等这些数据读多写少非常适合缓存。我用的是room:{roomId}这样的 key过期时间设置成 30 分钟主播修改信息时主动删除缓存业务接口读取时先查缓存再查库。第二类是实时计数数据包括在线人数、点赞数、观看次数。这类数据更新极其频繁直接写 MySQL 的话数据库完全扛不住。我把计数操作全部放在 Redis 里用INCR和HINCRBY完成然后每 5 秒由异步任务批量把计数结果刷到数据库中。第三类是弹幕和评论的时间线用一个 Redis List 存最近 1000 条弹幕新弹幕从左边 push超过长度从右边 trim。观众进入直播间时直接从这个 list 里取最近几十条弹幕做回放避免回放弹幕直接查询 MySQL。3.2 缓存穿透、击穿、雪崩的应对方案缓存用上了之后新的问题接踵而来。压测过程中我遇到了几个教科书级别的场景幸好提前做了预案。缓存穿透是查询一个不存在的 key比如用户访问一个压根不存在的直播间请求会直接漏到数据库。我的思路是先用布隆过滤器拦截明显不存在的 key再对查询结果为空的 key 做短暂的NULL缓存比如 2 分钟避免恶意请求绕开缓存打垮数据库。缓存击穿是某个热点 key 在过期的一瞬间大量请求同时涌入数据库。我用的方案是互斥锁只有第一个请求能拿到锁并去数据库查询其余请求短暂等待后直接读新缓存。代码大概长这样public String getRoomInfo(String roomId) { String value redisTemplate.opsForValue().get(room: roomId); if (value ! null) { return value; } // 加锁防止缓存击穿 String lockKey lock:room: roomId; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 3, TimeUnit.SECONDS); if (locked) { try { value queryRoomFromDatabase(roomId); redisTemplate.opsForValue().set(room: roomId, value, 30, TimeUnit.MINUTES); } finally { redisTemplate.delete(lockKey); } } else { // 短暂睡眠后重试 Thread.sleep(50); return getRoomInfo(roomId); } return value; }缓存雪崩是大量 key 在同一时间过期导致数据库瞬时压力剧增。我的做法很简单过期时间加一个随机值让各个 key 的过期时间错开。比如基础过期时间 5 分钟再随机加 1 到 60 秒这样同一时刻失效的 key 大大减少。3.3 RabbitMQ 如何平衡瞬时写入洪峰弹幕、点赞、送礼这些写操作如果每一条都直接写数据库数据库必然扛不住。我引入 RabbitMQ 之后整个写入链路变成了“前端请求 → 直接写 Redis → 投递消息到 MQ → 消费者异步批量落库”。弹幕、点赞这类高频低价值数据我用直连交换机消费者每 2 秒拉取一批消息批量执行INSERT或UPDATE。礼物订单这类涉及资金的数据为了保证不丢失我用了生产者确认 手动 ACK消息持久化也全部打开。这里有个细节RabbitMQ 的prefetchCount参数必须设置默认是无限分发消费者处理不过来会导致消息积压。我把prefetchCount设成 100意思是一个消费者同一时刻最多有 100 条未被确认的消息处理完一批再拉下一批流量削峰效果才明显。消息队列还有个额外的好处如果直播突然涌入十倍流量MQ 可以像一个蓄水池一样把消息先存起来消费者按自己的处理能力慢慢消费保证系统不会瞬间崩溃。我在压测中用 5000 并发持续发送弹幕消息RabbitMQ 积压了十几万条消息但数据库的写入速率一直很平稳这就是削峰的作用。4. 压测实战用 JMeter 验证环境的承载能力4.1 压测脚本与场景设计环境全部就绪后压测同事用 JMeter 配合脚本做了一套完整的压测方案。这里我先说脚本设计思路因为压测不是“起 1000 个线程点一个接口”那么简单。我们按真实直播场景拆成了三个压测模型基础业务模型模拟用户进入直播间、退出直播间、发送弹幕、点赞比例大概是进入 10%、退出 10%、弹幕 60%、点赞 20%。这类请求 QPS 最高是压测的重点。查询模型模拟用户频繁刷新直播间详情、加载弹幕历史、查看礼物排行榜对缓存层和数据层的读压力最大。拉流模型模拟并发拉取 HTTP-FLV 视频流主要看 SRS 和带宽的承载能力。JMeter 脚本中我用的是Thread GroupConstant Throughput Timer来控制目标吞吐量。设置虚拟用户数 500 到 5000 递增压测持续 15 分钟观察系统在长时间高压下的表现而不是只看前几分钟的瞬时数据。压测开始前我清理了服务器上的所有辅助进程保证测试结果尽量准确。同时用nmon监控 CPU、内存、磁盘 IO、网络流量用redis-cli --stat观察 Redis 的实时命令数用rabbitmqctl list_queues观察队列积压情况一次性把系统全景抓在手上。4.2 压测结果分析与性能瓶颈定位第一轮压测的结果非常难看TPS 只有 600错误率高达 5.6%。从监控数据看MySQL 的 CPU 使用率到了 80%慢查询日志里全是对弹幕表和计数表的查询说明缓存没有完全生效大量请求穿透到了数据库。优化后再测TPS 提到了 1800但继续加压到 4000 虚拟用户时错误率又开始上升。这次看监控发现 Redis 的 CPU 使用率到了 90%原因是我在弹幕列表查询时用了一个比较耗时的 Lua 脚本把 Redis 拖慢了。优化脚本逻辑后TPS 稳定在了 2300 左右错误率降到了 0.1% 以下。压测过程中最有价值的结论是系统的瓶颈永远是动态的。一开始瓶颈在数据库优化后瓶颈转移到 Redis再优化后瓶颈回到了 Nginx 的 worker_connections。所以每轮压测都要重新检查所有环节而不是只盯着自己最熟悉的那个组件。4.3 拉流场景的结果和带宽测算拉流压测和数据不太一样受带宽影响最大。我们当时用 100Mbps 带宽一路 1Mbps 码率的直播流极限大约同时支撑 80-100 路流畅拉流超过这个数量就会出现卡顿和花屏。如果要支持更高并发要么升级带宽要么上 CDN。CDN 在这个场景下的核心价值是把重复的拉流请求分散到边缘节点源站相当于只承担上行推流和少量源站回源压力。对小型直播系统来说正确顺序是先压测自测容量再根据业务规模决定接入 CDN。提示压测拉流并发时要特别注意 SRS 的max_connections和系统文件描述符限制。默认的ulimit -n是 1024我改成 65535 之后拉流并发立刻上了一个台阶。5. 踩坑记录与优化复盘5.1 我踩过的五个典型坑第一个坑是安全组与防火墙双重拦截。服务器内部端口全放行了云服务商安全组没放行一样不通。排查思路是先telnet 127.0.0.1 端口确认服务正常再telnet 公网IP 端口确认外部连通性能精准定位是哪一层出问题。第二个坑是 MySQL 连接池配置过小。Spring Boot 默认的 HikariCP 最大连接数是 10压测一到 200 并发连接池就耗尽请求全部排队超时。后来调整到maximum-pool-size: 200问题迎刃而解。第三个坑是 Redis 没有设置合理的淘汰策略。直播间元数据一旦膨胀内存直接被占满Redis 开始频繁淘汰 key缓存命中率大幅下降。后来明确区分了永久 key 和临时 key临时 key 全部设置过期时间并开启allkeys-lru策略。第四个坑是线程池参数没有隔离。刚开始所有异步任务共用一个线程池弹幕消费任务把线程占满后礼物订单推送任务全部阻塞。后来按照业务类型拆分了多个独立线程池核心线程数、队列容量都按业务量单独设置互相不干扰。第五个坑是日志拖慢了高并发接口。压测时发现同样的接口开了 debug 日志后 TPS 下降 20% 以上。高并发环境下日志异步化非常关键我用的是 Logback 的AsyncAppender把磁盘 IO 从请求链路中剥离出去性能提升立竿见影。5.2 优化后的整体能力画像压测全部优化完成后这套单机环境的最终表现是业务接口稳定承接约 2300 TPS错误率低于 0.1%RTMP 推流稳定支持一路高清直播HTTP-FLV 拉流并发约 80-100 路受百兆带宽限制RabbitMQ 在高峰时可缓冲数万条消息数据库写入保持平稳。这个数据放在大厂面前不值一提但对一个后端小白从零手搓出来的系统来说已经把单机性能压榨到了比较理想的水平。更重要的是通过这个过程我真正理解了高并发系统每一层的作用而不只是在面试题里记住“缓存击穿怎么解决”“消息队列怎么削峰”。5.3 给同路人的四点建议如果你也打算从零搭一套直播高并发环境我有几点经验要分享。先跑通再优化别憋大招。我第一次就想着把微服务、K8s、容器化全上结果一周过去了环境都没跑起来。正确的做法是先用最简单的单体应用把直播推流和业务接口跑通再逐步加缓存、加队列、加代理层每一步都有明确收益。压测是从零开始最该拥有的能力。不压测你永远不知道系统到底能扛多少流量。JMeter 虽然写起来有些繁琐但学一次能用很久值得投入时间。每个中间件都要看官方文档。一开始我为了解决某个 RabbitMQ 报错在博客里找了一圈答案越看越乱最后是官方文档的几句话点醒了我。开源项目的官方文档通常是最准确、最系统的遇到问题先查文档。留足复盘时间。每轮压测后我都记录下系统表现、瓶颈点、优化措施形成一个小的压测报告。这些记录不仅帮我理清思路也在后来的面试中成为非常直观的实战案例。这套直播高并发环境的搭建过程说起来只是一个项目但对我而言最有价值的收获是建立了一种“系统思维”做后端不能只盯着接口和数据库要把网络链路、缓存生命周期、异步消息、流媒体服务这些看似不相关的东西串起来看。如果你也在从后端向更高并发方向摸索建议直接动手搭一套自己的环境用压测数据倒逼自己进步。踩坑不可怕每次定位问题的过程都是你能力的增量。
三年前我还是个只会写增删改查的后端小白结果产品经理甩来一句话“直播间要做高并发你负责搭环境。”当时我连“高并发”三个字背后意味着什么都说不清楚更别说一套直播推拉流、弹幕、礼物系统的完整链路。硬着头皮从零开始前后折腾了大半个月把服务器、缓存、队列、直播流服务、压测工具全部过了一遍最终用 8 核 16G 的云服务器扛住了模拟直播场景下的数千并发请求。今天把这段经历整理出来给同样从后端起步、想搞懂直播高并发环境搭建的同学一个完整参考。这篇文章会围绕“直播高并发环境”这个核心串起我从需求分析、技术选型、环境搭建、缓存与异步设计再到 jmeter 压测验证的完整过程。既有配置细节也有踩坑实录还会讲清楚每个环节“为什么这么做”。适合刚接触后端、想独立做一个小型直播系统或者在准备后端相关面试时需要实战谈资的同学。1. 项目整体设计与方案选型1.1 先搞清楚直播系统到底有哪几条链路我一开始犯的最大错误是以为“直播高并发”就是把服务器带宽拉满然后拼命堆 Nginx 转发。真正动手后才发现直播系统至少分三条完全不同的链路每条链路的压力模型都不一样。第一条链路是视频流链路从主播推流到转码、分发、观众拉流这本质上是超高带宽和低延迟问题对服务器 CPU 和网卡的要求远高于普通业务接口。第二条链路是业务接口链路包括用户登录、进入直播间、发送弹幕、送礼、点赞、关注等操作这才是后端同学最需要关心的“高并发”主战场。第三条链路是数据与状态同步链路比如在线人数统计、弹幕广播、礼物排行榜它既要有实时性又要保证最终一致性。传统“一个 Web 容器裸跑业务”的做法在这三条链路同时压过来时必定崩。所以方案设计的核心思路是视频流量走独立代理层业务流量走负载均衡热点数据全部打散到缓存写操作全部异步化。把这三件事想清楚整套架构的骨架就出来了。1.2 技术选型思路不追新只追稳做技术选型时我给自己定了一条规矩所有组件必须是文档多、社区活跃、踩坑经验丰富的方案。作为一个后端小白我没有能力也没必要去啃冷门技术能快速跑通、遇到问题能搜到答案才是第一位的。最终敲定的组件列表是这样的层次选型理由业务开发Spring Boot 2.7 JDK 8生态成熟资料多小白友好数据库MySQL 8.0直播回放、用户信息、订单记录缓存Redis 6.2扛热点读、计数、排行榜、分布式锁队列RabbitMQ 3.12弹幕异步落库、礼物订单削峰反向代理Nginx 1.24静态资源分发、反向代理、简单限流直播流服务SRS 5.0先试过 nginx-rtmpRTMP 推流、HLS/HTTP-FLV 拉流、低延迟压测工具Apache JMeter 5.x免费、支持高并发脚本、结果可视化这里需要单独说说直播流服务的选型。我最初图省事用 nginx-rtmp 模块但它是单进程模型并发拉流一上来CPU 就冲到 90%后来切到 SRS 才真正解决问题。SRS 是国人开源的高性能流媒体服务器支持 RTMP、HLS、HTTP-FLV 等多种协议配置简单对中小直播场景非常友好实测在相同机器上承载的拉流并发数比 nginx-rtmp 高好几倍。选型的时候还有个心法不要因为某个组件“高级”就用它。比如当时有人建议我用 Kubernetes但只有两三台服务器上 K8s 反而徒增复杂度。先把单机压榨到极致再考虑分布式扩展这才是小团队最务实的路径。1.3 高并发架构的整体轮廓所有组件确定后我画了一张架构草图虽然画得难看但起到了关键作用主播端通过 RTMP 协议推流到 SRSSRS 负责将视频流转成 HTTP-FLV 和 HLS 输出Nginx 对拉流请求做负载均衡和缓存业务请求则统一走 Nginx转发给后端的 Spring Boot 服务集群Redis 放在业务层和数据库中间挡住绝大多数热点读请求写流量通过 RabbitMQ 削峰数据库只处理最终落盘。这张图让我想明白了一个重要问题高并发不是靠某一个组件而是靠每一层分工。Nginx 挡流量SRS 处理流Redis 挡热点MQ 削峰数据库只干自己的活各层之间用清晰的协议衔接。后面所有开发和调优都是围绕让每一层“专注”展开的。2. 服务器初始化与基础组件搭建2.1 云服务器的基础初始化要点我用的是一台 8 核 16G 的云服务器 ECS系统盘 40G数据盘 100G带宽按量付费跑到 100Mbps。说实话这个配置不算高但用来验证高并发思路完全够用。系统我选了 CentOS 7.9虽然官方已经停止维护但网上资料最多遇到问题搜起来最方便。拿到一台裸机后初始化顺序很重要我的操作流程是更新系统源并安装基础工具yum update -y yum install -y wget vim net-tools telnet lrzsz创建专用的部署用户我用的deploy拒绝 root 直接跑服务降低误操作风险修改 SSH 配置关闭 root 密码登录改用密钥登录配置防火墙只放行 22、80、443、1935RTMP、8080 等必要端口挂载数据盘到/data目录把 MySQL、Redis 的数据目录都指向这里避免系统盘写满这里有个特别容易忽略的坑云服务商的安全组和服务器内部的 firewalld/iptables 是两层概念必须同时放行端口才有效。我第一次部署完发现 1935 端口不通排查半天才发现是安全组没放行而不是防火墙的问题。2.2 JDK、MySQL、Redis 的安装与基础调优JDK 没太多可说的解压、配环境变量、java -version验证即可。我统一用 JDK 8因为它和 Spring Boot 2.7 配合最稳定。MySQL 8.0 的安装我用的是官方 yum 源但有几个参数必须调整否则高并发下数据库很容易成为瓶颈。核心配置我改成了这些[mysqld] max_connections 1000 innodb_buffer_pool_size 4G innodb_flush_log_at_trx_commit 2 innodb_log_file_size 512M sync_binlog 0 character-set-server utf8mb4这里解释一下innodb_buffer_pool_size一般设置为物理内存的 50%-70%4G 对于 16G 内存的机器是合理的innodb_flush_log_at_trx_commit 2表示每秒刷一次磁盘牺牲极少的持久性换取大幅性能提升直播场景下的非关键数据完全可以接受sync_binlog 0同理适合对一致性要求不是最高的写入场景。Redis 的安装更简单源码编译或 yum 安装都行。但配置里我强制开启了appendonly yes避免重启丢数据。另外设置了maxmemory 4gb和maxmemory-policy allkeys-lru防止缓存数据无限增长把内存撑爆。2.3 Nginx 安装与反向代理配置Nginx 我直接用官方源安装版本 1.24。配置层面的重点有两块一是作为业务接口的反向代理二是作为拉流入口的流量分发。业务接口的 Nginx 配置核心大概长这样upstream live_backend { server 127.0.0.1:8080 max_fails3 fail_timeout30s; keepalive 64; } server { listen 80; server_name api.example.com; location /api/ { proxy_pass http://live_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 5s; proxy_read_timeout 10s; } }这里有个经验之谈keepalive 64能让 Nginx 和后端服务之间维持长连接避免每次请求都重新建立 TCP 连接。我在压测时对比过开启 keepalive 后接口的吞吐量提升了将近 40%。2.4 直播流服务从 nginx-rtmp 到 SRS视频链路是我花时间最多的地方。一开始我用 nginx-rtmp 模块配置确实简单加上几行就能实现 RTMP 推流和 HLS 播放rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; hls on; hls_path /data/hls; hls_fragment 2s; hls_playlist_length 6s; } } }跑通推拉流之后我用 jmeter 过了压力测试发现 nginx-rtmp 的并发拉流能力非常弱CPU 单核直接打满延迟还不断飙升。查资料才发现 nginx-rtmp 是单进程模型对多核服务器利用率极差。切到 SRS 之后配置文件看起来更“宏大”但逻辑很清晰# srs.conf listen 1935; max_connections 10000; srs_log_tank file; srs_log_file /data/logs/srs.log; http_api { enabled on; listen 1985; } vhost __defaultVhost__ { http_remux { enabled on; mount [vhost]/[app]/[stream].flv; hstrs on; } hls { enabled on; hls_path /data/hls; hls_fragment 2; hls_window 6; } }SRS 的多进程模型确实能充分利用多核 CPU同样配置下拉流并发从几百涨到了几千。另外一个好处是 SRS 自带 HTTP API可以直接查询在线流数、连接数做监控非常方便。3. 高并发核心缓存设计与异步化改造3.1 Redis 到底在扛什么数据环境搭好了业务接口也上线了但压测一跑立刻发现所有请求直接打到 MySQL数据库连接瞬间耗尽接口大量超时。这个阶段的教训非常深刻没有缓存的架构在高并发场景下形同虚设。在直播场景下我用 Redis 缓存了三类核心数据。第一类是直播间的元数据包括房间名称、主播信息、封面图、公告等这些数据读多写少非常适合缓存。我用的是room:{roomId}这样的 key过期时间设置成 30 分钟主播修改信息时主动删除缓存业务接口读取时先查缓存再查库。第二类是实时计数数据包括在线人数、点赞数、观看次数。这类数据更新极其频繁直接写 MySQL 的话数据库完全扛不住。我把计数操作全部放在 Redis 里用INCR和HINCRBY完成然后每 5 秒由异步任务批量把计数结果刷到数据库中。第三类是弹幕和评论的时间线用一个 Redis List 存最近 1000 条弹幕新弹幕从左边 push超过长度从右边 trim。观众进入直播间时直接从这个 list 里取最近几十条弹幕做回放避免回放弹幕直接查询 MySQL。3.2 缓存穿透、击穿、雪崩的应对方案缓存用上了之后新的问题接踵而来。压测过程中我遇到了几个教科书级别的场景幸好提前做了预案。缓存穿透是查询一个不存在的 key比如用户访问一个压根不存在的直播间请求会直接漏到数据库。我的思路是先用布隆过滤器拦截明显不存在的 key再对查询结果为空的 key 做短暂的NULL缓存比如 2 分钟避免恶意请求绕开缓存打垮数据库。缓存击穿是某个热点 key 在过期的一瞬间大量请求同时涌入数据库。我用的方案是互斥锁只有第一个请求能拿到锁并去数据库查询其余请求短暂等待后直接读新缓存。代码大概长这样public String getRoomInfo(String roomId) { String value redisTemplate.opsForValue().get(room: roomId); if (value ! null) { return value; } // 加锁防止缓存击穿 String lockKey lock:room: roomId; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 3, TimeUnit.SECONDS); if (locked) { try { value queryRoomFromDatabase(roomId); redisTemplate.opsForValue().set(room: roomId, value, 30, TimeUnit.MINUTES); } finally { redisTemplate.delete(lockKey); } } else { // 短暂睡眠后重试 Thread.sleep(50); return getRoomInfo(roomId); } return value; }缓存雪崩是大量 key 在同一时间过期导致数据库瞬时压力剧增。我的做法很简单过期时间加一个随机值让各个 key 的过期时间错开。比如基础过期时间 5 分钟再随机加 1 到 60 秒这样同一时刻失效的 key 大大减少。3.3 RabbitMQ 如何平衡瞬时写入洪峰弹幕、点赞、送礼这些写操作如果每一条都直接写数据库数据库必然扛不住。我引入 RabbitMQ 之后整个写入链路变成了“前端请求 → 直接写 Redis → 投递消息到 MQ → 消费者异步批量落库”。弹幕、点赞这类高频低价值数据我用直连交换机消费者每 2 秒拉取一批消息批量执行INSERT或UPDATE。礼物订单这类涉及资金的数据为了保证不丢失我用了生产者确认 手动 ACK消息持久化也全部打开。这里有个细节RabbitMQ 的prefetchCount参数必须设置默认是无限分发消费者处理不过来会导致消息积压。我把prefetchCount设成 100意思是一个消费者同一时刻最多有 100 条未被确认的消息处理完一批再拉下一批流量削峰效果才明显。消息队列还有个额外的好处如果直播突然涌入十倍流量MQ 可以像一个蓄水池一样把消息先存起来消费者按自己的处理能力慢慢消费保证系统不会瞬间崩溃。我在压测中用 5000 并发持续发送弹幕消息RabbitMQ 积压了十几万条消息但数据库的写入速率一直很平稳这就是削峰的作用。4. 压测实战用 JMeter 验证环境的承载能力4.1 压测脚本与场景设计环境全部就绪后压测同事用 JMeter 配合脚本做了一套完整的压测方案。这里我先说脚本设计思路因为压测不是“起 1000 个线程点一个接口”那么简单。我们按真实直播场景拆成了三个压测模型基础业务模型模拟用户进入直播间、退出直播间、发送弹幕、点赞比例大概是进入 10%、退出 10%、弹幕 60%、点赞 20%。这类请求 QPS 最高是压测的重点。查询模型模拟用户频繁刷新直播间详情、加载弹幕历史、查看礼物排行榜对缓存层和数据层的读压力最大。拉流模型模拟并发拉取 HTTP-FLV 视频流主要看 SRS 和带宽的承载能力。JMeter 脚本中我用的是Thread GroupConstant Throughput Timer来控制目标吞吐量。设置虚拟用户数 500 到 5000 递增压测持续 15 分钟观察系统在长时间高压下的表现而不是只看前几分钟的瞬时数据。压测开始前我清理了服务器上的所有辅助进程保证测试结果尽量准确。同时用nmon监控 CPU、内存、磁盘 IO、网络流量用redis-cli --stat观察 Redis 的实时命令数用rabbitmqctl list_queues观察队列积压情况一次性把系统全景抓在手上。4.2 压测结果分析与性能瓶颈定位第一轮压测的结果非常难看TPS 只有 600错误率高达 5.6%。从监控数据看MySQL 的 CPU 使用率到了 80%慢查询日志里全是对弹幕表和计数表的查询说明缓存没有完全生效大量请求穿透到了数据库。优化后再测TPS 提到了 1800但继续加压到 4000 虚拟用户时错误率又开始上升。这次看监控发现 Redis 的 CPU 使用率到了 90%原因是我在弹幕列表查询时用了一个比较耗时的 Lua 脚本把 Redis 拖慢了。优化脚本逻辑后TPS 稳定在了 2300 左右错误率降到了 0.1% 以下。压测过程中最有价值的结论是系统的瓶颈永远是动态的。一开始瓶颈在数据库优化后瓶颈转移到 Redis再优化后瓶颈回到了 Nginx 的 worker_connections。所以每轮压测都要重新检查所有环节而不是只盯着自己最熟悉的那个组件。4.3 拉流场景的结果和带宽测算拉流压测和数据不太一样受带宽影响最大。我们当时用 100Mbps 带宽一路 1Mbps 码率的直播流极限大约同时支撑 80-100 路流畅拉流超过这个数量就会出现卡顿和花屏。如果要支持更高并发要么升级带宽要么上 CDN。CDN 在这个场景下的核心价值是把重复的拉流请求分散到边缘节点源站相当于只承担上行推流和少量源站回源压力。对小型直播系统来说正确顺序是先压测自测容量再根据业务规模决定接入 CDN。提示压测拉流并发时要特别注意 SRS 的max_connections和系统文件描述符限制。默认的ulimit -n是 1024我改成 65535 之后拉流并发立刻上了一个台阶。5. 踩坑记录与优化复盘5.1 我踩过的五个典型坑第一个坑是安全组与防火墙双重拦截。服务器内部端口全放行了云服务商安全组没放行一样不通。排查思路是先telnet 127.0.0.1 端口确认服务正常再telnet 公网IP 端口确认外部连通性能精准定位是哪一层出问题。第二个坑是 MySQL 连接池配置过小。Spring Boot 默认的 HikariCP 最大连接数是 10压测一到 200 并发连接池就耗尽请求全部排队超时。后来调整到maximum-pool-size: 200问题迎刃而解。第三个坑是 Redis 没有设置合理的淘汰策略。直播间元数据一旦膨胀内存直接被占满Redis 开始频繁淘汰 key缓存命中率大幅下降。后来明确区分了永久 key 和临时 key临时 key 全部设置过期时间并开启allkeys-lru策略。第四个坑是线程池参数没有隔离。刚开始所有异步任务共用一个线程池弹幕消费任务把线程占满后礼物订单推送任务全部阻塞。后来按照业务类型拆分了多个独立线程池核心线程数、队列容量都按业务量单独设置互相不干扰。第五个坑是日志拖慢了高并发接口。压测时发现同样的接口开了 debug 日志后 TPS 下降 20% 以上。高并发环境下日志异步化非常关键我用的是 Logback 的AsyncAppender把磁盘 IO 从请求链路中剥离出去性能提升立竿见影。5.2 优化后的整体能力画像压测全部优化完成后这套单机环境的最终表现是业务接口稳定承接约 2300 TPS错误率低于 0.1%RTMP 推流稳定支持一路高清直播HTTP-FLV 拉流并发约 80-100 路受百兆带宽限制RabbitMQ 在高峰时可缓冲数万条消息数据库写入保持平稳。这个数据放在大厂面前不值一提但对一个后端小白从零手搓出来的系统来说已经把单机性能压榨到了比较理想的水平。更重要的是通过这个过程我真正理解了高并发系统每一层的作用而不只是在面试题里记住“缓存击穿怎么解决”“消息队列怎么削峰”。5.3 给同路人的四点建议如果你也打算从零搭一套直播高并发环境我有几点经验要分享。先跑通再优化别憋大招。我第一次就想着把微服务、K8s、容器化全上结果一周过去了环境都没跑起来。正确的做法是先用最简单的单体应用把直播推流和业务接口跑通再逐步加缓存、加队列、加代理层每一步都有明确收益。压测是从零开始最该拥有的能力。不压测你永远不知道系统到底能扛多少流量。JMeter 虽然写起来有些繁琐但学一次能用很久值得投入时间。每个中间件都要看官方文档。一开始我为了解决某个 RabbitMQ 报错在博客里找了一圈答案越看越乱最后是官方文档的几句话点醒了我。开源项目的官方文档通常是最准确、最系统的遇到问题先查文档。留足复盘时间。每轮压测后我都记录下系统表现、瓶颈点、优化措施形成一个小的压测报告。这些记录不仅帮我理清思路也在后来的面试中成为非常直观的实战案例。这套直播高并发环境的搭建过程说起来只是一个项目但对我而言最有价值的收获是建立了一种“系统思维”做后端不能只盯着接口和数据库要把网络链路、缓存生命周期、异步消息、流媒体服务这些看似不相关的东西串起来看。如果你也在从后端向更高并发方向摸索建议直接动手搭一套自己的环境用压测数据倒逼自己进步。踩坑不可怕每次定位问题的过程都是你能力的增量。
