短剧系统这几年火得不是一星半点单条爆款视频一晚上能拉来几十万新用户流量峰值是常态不是意外。做过这类系统的朋友应该都有体会短剧不只是视频播放它背后是C端用户的注册登录、剧集列表、下单解锁、连续观看、评论弹幕、分销推广、活动运营、数据上报这些链路叠在一起如果还用单体应用一把梭流量稍微一冲就等着半夜被叫起来扩容吧。所以用Java技术栈做微服务拆分配合高并发和分布式存储方案基本是这类系统绕不开的架构路径。我自己从零搭过一版短剧系统技术选型是Sping Cloud Alibaba全家桶注册中心用Nacos网关用Spring Cloud Gateway缓存RedisMQ用RocketMQ存储层MySQL做业务数据MongoDB存播放记录和评论视频文件走MinIO加CDNES做搜索。整个过程踩了不少坑也沉淀了不少可直接复用的设计方案。这篇文章就把这套系统的拆解思路、高并发处理细节、分布式存储落地方案和几个线上真实问题一起整理出来给正在做或准备做短剧系统的朋友一个参考。1. 项目概述与整体技术选型思路1.1 短剧系统为什么必须上微服务先说结论短剧业务天然适合微服务甚至说单体架构很难撑住这个业务的增长节奏。短剧的流量模型和普通电商不一样。电商大促的峰值是可预测的双十一、618都知道哪天来提前扩容压测就行。短剧不一样一个剧集突然在短视频平台投放火了几十万流量可能在半小时内涌进来今天爆量不代表明天还有量明天没量也不代表后天不会再爆流量曲线非常陡峭。这种突发的、不可控的流量直接打到单体应用上后果就是数据库连接池被打满、接口超时、服务雪崩。另一个原因是业务模块天然独立。用户体系、剧集管理、订单支付、播放鉴权、评论互动、分销推广、运营后台这些模块的迭代频率完全不同。运营后台三天两头改逻辑如果和播放鉴权耦合在一个应用里每次改运营后台都得重新发布整个应用播放服务一起受影响这在线上是不可接受的。用微服务把业务拆开之后每个服务可以独立扩容、独立发布、独立降级。流量暴涨时只需要给最吃紧的播放鉴权和订单服务扩容运营后台该干嘛干嘛互不干扰。这就是微服务在这个场景下最大的价值。1.2 核心技术栈选型从单体到微服务的演进逻辑技术选型这件事我的原则是团队熟悉什么、生态成熟什么、出了问题能找到人问什么优先选什么。注册中心和配置中心我选了Nacos原因很简单它把注册发现和配置管理合在了一起少维护一套组件。和Eureka相比Nacos支持服务端主动感知下线不需要客户端轮询故障感知更快和Consul相比Nacos的中文文档和社区活跃度更好出了问题容易查。另一个现实因素是国内很多Java团队都用过Nacos招人也好招。网关这一层没有用Zuul直接上了Spring Cloud Gateway。Spring Cloud Gateway基于WebFlux是响应式编程模型吞吐量比Zuul 1.x高很多而且Spring Cloud官方明确Gateway是未来的方向Zuul 1.x基本处于维护状态。网关在这里承担路由转发、统一鉴权、限流、跨域处理、请求日志这些横切逻辑。服务间调用我用的是OpenFeign加Sentinel组合。OpenFeign负责声明式远程调用代码写起来非常简洁Sentinel负责流量控制和熔断降级。Sentinel相比Hystrix的优势是细粒度的流量控制和实时监控面板Hystrix已经停止维护了就不建议再用了。存储层面MySQL负责用户、剧集元数据、订单这些强一致性核心业务数据Redis做缓存、分布式锁、接口限流计数MongoDB存储播放记录、用户行为日志这种高吞吐写入的数据Elasticsearch做剧集名称和标签的搜索MinIO自建对象存储存储视频源文件和封面图前端通过CDN加速访问RocketMQ做订单超时关单、消息通知、数据异步同步等场景。消息队列用RocketMQ而不是Kafka是因为短剧系统需要事务消息和延迟消息。订单场景要保证本地事务和消息发送的原子性RocketMQ的事务消息机制天然支持订单超时未支付需要自动关单RocketMQ的延迟消息直接支持Kafka得自己实现一套延迟机制很麻烦。2. 高并发核心链路设计与关键细节2.1 热点数据与流量模型分析做高并发设计之前一定要先搞明白短剧系统的热点在哪里这决定了你优化什么。短剧系统的流量分为两类。一类是公域流量用户在抖音、快手、微信视频号刷到短剧推广短视频通过小程序或下载App进入系统。这类流量由外部渠道决定进来的时候是批量涌入的且目标非常集中。用户点进来看的是同一个剧集这个剧集就是热点数据。热点的具体表现是针对同一部剧的详情查询、试看播放、下单解锁、观看记录查询在几分钟内集中爆发。一类是私域流量已经注册的用户日常打开App浏览推荐位、追更已收藏的剧集。这类流量相对平稳但要注意的是每天晚上的8点到11点、周末全天是绝对的高峰期虽然不像投放爆量那么夸张但请求量是白天的3到5倍。有一个核心规律值得记住短剧系统里90%的请求流量都集中在10%的超热门剧集上。这意味着架构设计不需要对所有数据做同等级别的高性能处理只需要把热点数据缓存好、把热门剧集的访问路径优化到极致整个系统的表现就足够好了。2.2 缓存、限流、削峰、幂等高并发四大件缺一不可缓存是短剧系统高并发设计的基石但缓存不是简单的把数据塞进Redis就完了。对于剧集详情这类热点数据缓存策略是Cache Aside模式。请求先查Redis命中直接返回不命中查MySQL查到之后写回Redis并设置过期时间。这里有一个容易被忽视的细节缓存过期时间的设置不能是固定的同一个值。如果所有热门剧集的过期时间都是30分钟到期那一刻会同时穿透到MySQL造成缓存雪崩。我的做法是30分钟加上一个随机数比如30到40分钟之间随机让过期时间分散开。另一个细节是热点剧集的缓存预热。运营后台可以提前把今天要投放的新剧的详情写入Redis或者用一个定时任务扫描当天播放量Top N的剧集主动刷新它们的缓存。这样避免了用户第一次访问时的缓存穿透也保证了热点数据始终在缓存里。限流必须放在网关层做而且要支持不同维度的限流。网关上有全局限流比如整个系统每秒最多接受5万个请求这是系统资源的硬上限防止恶意刷量把后端打挂。还有接口级限流比如每个用户每秒最多请求10次播放鉴权接口。还有针对单一热点剧集的维度限流防止某个剧集被集中刷量。削峰用的是RocketMQ。短剧业务里有两个典型的削峰场景。一个是观看记录上报用户每播放几秒就上报一条播放进度峰值时间每秒上万条直接写数据库肯定扛不住而且这条数据实时性要求很低。做法是异步上报到RocketMQ消费端慢慢落库。一个是订单超时关单用户下单但未支付的订单不需要每秒扫描数据库下单时发送一条延迟消息10分钟后消费端收到消息去查订单状态如果还是未支付就关单。这样把高频的轮询变成了低频的事件驱动数据库压力小很多。幂等性设计容易被忽略但短剧系统里有两个场景必须做。第一个是支付回调。用户微信支付成功后微信服务端会回调系统接口回调可能因为网络超时被重发同一个支付结果可能被通知多次。如果回调处理逻辑里没有幂等就会出现同一笔订单被重复更新、重复解锁剧集的情况。处理方式是在订单表加一个状态字段支付成功回调处理前先查询订单状态如果已经是已支付就直接返回成功不重复处理同时用分布式锁保证同一笔订单的并发处理只有一个线程能进入。第二个是MQ消费。消息队列的消费可能因为消费端宕机、Rebalance等原因导致消息被重复投递。消费端在落库之前用业务唯一键查一下是否已经处理过处理过就跳过。2.3 分布式事务在实际业务中的取舍微服务拆分之后一个业务操作会跨多个服务分布式事务是绕不开的话题。但是我想说一句大实话能不用强分布式事务就不要用强一致性是性能的大敌。短剧系统里订单支付成功这个操作涉及订单服务改订单状态、用户服务加会员权益或解锁记录、剧集服务记录解锁历史。从严格意义上说这三个操作需要保持一致。但仔细分析就知道真正需要强一致性的只有订单状态变更和用户权益发放这两个而这两个是同一个领域内的强关联操作完全可以在订单服务内用一个本地事务完成。至于剧集解锁历史的记录这个失败了也不影响用户观看属于可以容忍短时间不一致的数据。我的做法是订单服务本地事务里更新订单状态和发放权益同时发送一条事务消息给RocketMQ由剧集服务消费消息记录解锁历史。如果消息发送失败订单本地事务回滚权益和状态一起回滚。如果消息消费失败RocketMQ会有重试机制重试到最大次数后进入死信队列由定时任务扫描死信队列补发。这个方案本质上是本地消息表加事务消息的异步确保方案用最终一致性替代强一致性既保证了核心数据的正确又避免了两阶段提交那种大范围的资源锁定。短剧系统的业务复杂度完全够用。有人会提SeataSeata的AT模式确实能实现分布式事务但它带来的代价是全局锁、undo_log、额外的网络开销性能损耗不小。我的建议是除非你的业务确实需要一个操作里强一致地更新多个微服务的数据否则不要轻易引入Seata单纯增加系统复杂度。3. 分布式存储在短剧场景下的落地选型3.1 数据画像先看清短剧系统里的四类数据分布式存储方案的设计必须基于数据画像不同数据有不同的访问特征和存储诉求一句话说不清楚。第一类是核心业务数据包括用户、剧集元数据、订单、支付流水、权益。这些数据的特点是数据量增长慢、访问次数高、强一致性要求高、需要复杂查询。这类数据放MySQL做读写分离配合Redis缓存。第二类是行为日志数据包括用户播放记录、观看时长上报、点击行为、搜索词记录。这类数据的特点是高吞吐写入、海量存储、几乎不需要更新、查询场景单一。这类数据放MongoDB最合适MongoDB的写入性能很强水平扩展也简单按天建表或者按月建表数据量大了按时间归档即可。第三类是视频文件数据短剧正片、试看片段、封面图、推广海报。这类数据的特点是文件体积大、读多写少、访问需要通过CDN加速、需要持久化保存。选型上用MinIO自建对象存储加CDN或者直接用阿里云OSS加CDN。自建MinIO的优势是成本低适合已经有服务器资源的团队如果不想操心运维直接上云OSS更省心。第四类是全文检索数据用户搜索剧名、演员、标签。MySQL的LIKE查询在数据量大了以后性能非常差短剧系统需要一个专门的搜索引擎。ES在Java技术栈里是标准答案通过Canal监听MySQL的binlog把剧集信息同步到ES搜索请求直接走ES不打扰业务数据库。3.2 对象存储选型对比MinIO自建与云OSS该怎么选对象存储在短剧系统里存储的是视频文件和封面图选型上我给出一个实际对比云OSS最大的优势是省心不用自己部署、不用运维、容量弹性扩容配合CDN加速上传和下载链路都是现成的。缺点是费用是持续性的特别是流量费用短剧系统视频播放量极大流量费用占比很高。MinIO自建的优势是软件本身免费只需要承担服务器和带宽成本。短剧视频文件可以只存储在MinIOCDN回源到MinIO存储成本比OSS低不少。缺点是需要自己运维包括集群部署、容量规划、数据备份、故障恢复。如果是创业团队早期想做验证日活几千的规模直接上MinIO一台机器就能跑成本几乎可以忽略。如果已经有了稳定的用户量而且没有专职的运维人员还是建议用云OSS稳定性比省那点钱重要。技术接入上无论选哪种都可以用S3协议统一封装。MinIO原生兼容S3协议阿里云OSS也提供S3兼容接口。项目里引入AWS的S3 SDK把endpoint配成MinIO地址或OSS地址切换存储后端时业务代码不需要改只改配置就行。这是我经验里比较重要的一个设计决策避免了和某个存储厂商深度绑定。3.3 视频文件的存储细节与CDN加速链路短剧视频文件有几个特性单集时长通常在1到3分钟文件不大但数量很多一套剧下来几十上百集高清视频文件从几十兆到几百兆不等播放时用户频繁拖动进度条对CDN的缓存命中率要求很高。视频上传链路的规范是运营后台通过前端直传MinIO的预签名URL直接上传文件不经过应用服务器中转。应用服务器只需要调用MinIO的SDK生成一个预签名URL返回给前端前端拿着URL直接PUT文件到MinIO。这样做有几个好处上传文件不占用应用服务器的带宽和连接资源大文件上传不会阻塞业务线程上传速度和稳定性由前端SDK直连存储端保证。上传完成之后业务系统需要拿到文件的唯一对象名存到剧集表里。然后触发一个异步任务调用FFmpeg对视频进行转码。转码不是为了改变清晰度而是做两件事一是把视频转成适合Web播放的H.264编码和MP4封装格式保证浏览器能直接播放二是生成不同清晰度的版本比如标清、高清、超清让播放端根据用户网络自动选择。播放访问链路的细节是用户端的播放地址统一指向CDNCDN的源站配置指向MinIO。用户首次播放某个剧集时CDN没有缓存会回源到MinIO拉取视频文件之后视频内容缓存在CDN节点上同一个城市的用户再访问就直接从CDN边缘节点读取不再到达源站。这里面有一个容易被忽略的配置CDN的缓存过期时间。视频文件的缓存时间应该设置得很长比如一年因为视频文件发布后基本不会修改。如果缓存时间设短了CDN频繁回源源站带宽压力会非常大同时也会产生高额的回源流量费用。还有一个细节是防盗链。短剧是付费内容不能让用户把视频链接复制出去随便传播。做法是在CDN上开启Referer防盗链只允许白名单域名访问更严格一点用URL鉴权给播放地址加一个签名签名里包含过期时间过期后链接自动失效。4. 实操实现从零搭建短剧微服务的核心环节4.1 服务拆分规范与工程结构微服务落地第一个难题就是拆服务。拆多了运维成本高拆少了没效果拆错了服务间循环调用比单体还痛苦。短剧系统的服务拆分我最终定成八个模块gateway-service网关服务负责路由转发、统一鉴权、限流、跨域user-service用户服务用户注册、登录、个人资料、会员权益drama-service剧集服务剧集信息、分类、章节、试看规则order-service订单服务下单、支付、订单状态管理payment-service支付服务对接微信支付、支付宝、回调处理search-service搜索服务基于ES的剧集搜索comment-service评论服务剧集评论、点赞、举报report-service数据服务播放上报、行为日志、运营数据统计拆分的时候参考了业务边界原则和团队协作原则。同类功能、同生命周期、同团队负责的功能聚在一个服务里播放上报这种高频写入的独立成一个服务避免影响其他业务。工程结构方面我建议用Maven多模块管理分三层父工程只做依赖管理统一锁定Spring Boot、Spring Cloud Alibaba的版本。子模块分common、framework、apps三层。common放公共工具类、统一返回结果、异常定义framework放各个服务需要的基础配置封装比如RedisConfig、MybatisPlusConfig、分页插件apps下面按业务域建各微服务模块。每个微服务模块内部再按controller、service、mapper、entity分层。4.2 服务注册发现与配置管理Nacos的引入极大简化了微服务之间的连接管理。所有微服务启动时把自己的IP和端口注册到Nacos网关和各个服务之间的调用通过Nacos发现目标服务的实例列表做负载均衡。Nacos配置中心的使用有一个很重要的注意事项不要把所有配置都放进Nacos。我的分配原则是各服务之间共享的配置放进Nacos的公共配置比如Redis地址、MySQL连接池、RocketMQ的NameServer地址每个服务独有的、可以写在本地配置文件里的保持本地比如服务端口。放进Nacos的配置需要在开发、测试、生产环境用不同的namespace或group区分避免联调时改错环境。Nacos服务端的部署在高并发场景下也有讲究。服务注册需要心跳维持服务实例越多心跳请求越多Nacos服务端的压力就越大。服务规模超过几百个实例之后建议Nacos集群化部署至少三节点用MySQL集中存储配置数据。我见过一个团队Nacos单机部署服务量起来之后心跳处理不过来导致服务频繁上下线线上调用错误率飙升排查了一个晚上才发现是Nacos的锅。网关连接Nacos做服务发现时负载均衡策略一般保持默认的轮询就行。不过有一个场景需要调整当剧集服务某个实例CPU使用率过高时轮询仍然会把请求发到这台慢实例上可能导致连锁超时。这时候可以考虑用Spring Cloud LoadBalancer的权重策略或者配合Sentinel的服务端熔断超时比例高的实例自动摘除流量。4.3 高并发接口的落地实现热门剧集列表与观看鉴权我挑两个最典型的高并发接口来拆解一个是首页热门剧集列表一个是观看鉴权。首页热门剧集列表是短剧App打开后立即调用的接口QPS极高而且所有用户看到的都是同一份热门数据是典型的读多写少热点数据。这个接口的Redis缓存不是简单set一个字符串我用的是两级缓存方案一级是本地缓存Caffeine缓存时间60秒存储在网关或应用实例内。二级是Redis缓存时间5分钟。请求进来先查本地缓存命中直接返回QPS可以到几万本地缓存未命中再查RedisRedis未命中才查MySQL。当运营在后台修改了热门剧集的排序时设计一个管理接口通知所有实例刷新本地缓存同时删除Redis缓存。这个方案里Caffeine的60秒和Redis的5分钟之间有时间差所以运营调整排序后用户最多在60秒内看到的还是旧数据这个延迟对短剧用户的体验是完全可以接受的。观看鉴权接口是短剧系统的命脉它的QPS和视频播放量成正比用户每播放一集就要调用一次。这个接口的业务逻辑是校验用户是否登录、校验剧集ID是否有效、校验用户是否有权观看该集、校验用户当前设备是否超过同时在线限制。这些校验每次都查MySQL效率太低全部走Redis。用户权限的缓存结构用Hash类型key是userIdfield是dramaIdvalue是解锁时间或过期时间。用户解锁某部剧时在订单服务里更新MySQL之后同步写入Redis。鉴权时只需要读Redis判断当前剧集ID是否在用户的已解锁列表中。缓存一分钟缓存过了再去数据库同步一次用户因为缓存延迟多等待的这一两秒几乎感知不到。这个方案的核心思想是把热点的读操作从数据库转移到缓存数据库只承担低频的写操作和缓存未命中时的回源。4.4 存储方案的具体配置与接入MySQL层面的核心配置我直接给参数连接池用的Druid或HikariCP都行我的建议是HikariCPSpring Boot默认轻量稳定。核心配置是maximum-pool-size常规业务服务设置20到50但数据上报服务这种高频写入的别有太高的连接数写多读少的服务连接池大小10到15就够。有一个经验值CPU密集型服务连接池建议等于CPU核心数加一IO密集型服务是CPU核心数的两倍。别把连接池配太大连接池越大MySQL端需要维护的线程和内存越多反而容易拖垮数据库。MySQL读写分离是必须做的。主库负责写从库负责读短剧系统的读请求远大于写请求读写分离能把数据库的负载大幅降低。实现方式可以用ShardingSphere的读写分离功能也可以在代码里通过动态数据源切换。我建议用ShardingSphere它还能顺带做分库分表能力预留后面数据量上来了不用改代码。MongoDB在短剧系统里的配置相对简单。播放记录表按用户ID做索引用户查询自己的观看历史通过userId查速度极快。数据增长到一定量级后按月建立集合比如play_record_202503历史月份的数据自动归档到冷存储。这个方案避免了单个集合数据量过大导致的写入性能下降。Redis的部署模式短剧系统的核心缓存我建议至少哨兵模式起步。单机一旦宕机整个缓存层全挂下游数据库瞬间被打爆。生产环境更推荐Cluster集群模式Redis Cluster自动分片、自动故障转移容量可以水平扩展。短剧系统的缓存数据量不大但QPS很高Redis集群最少三主三从写操作分散到三个主节点。5. 线上常见问题与排查实录5.1 缓存穿透、击穿、雪崩的排查与预防这三个问题在高并发读场景下几乎必然会遇到我逐个说实战解法。缓存穿透发生在请求查询一个不存在的Key时Redis没有缓存每次都打到MySQL。短剧系统里最常见的场景是用户用编造的剧集ID请求详情。解决办法有两个一是缓存空值整个剧集数据不存在的时候在Redis里也写一个空对象设置一个较短的过期时间比如50秒防止同一ID短时间内反复打到数据库。二是布隆过滤器把系统内所有有效的剧集ID预先加载到布隆过滤器里请求来了先判断ID是否存在不存在直接返回。数据量大的情况下建议用布隆过滤器空值缓存太消耗缓存空间。缓存击穿发生在热点Key过期的瞬间大量并发请求同时打到数据库。短剧系统里最典型的是热门剧集详情刚好缓存到期了同一时刻一万个用户查同一部剧。解决方式一是互斥锁缓存过期后只有一个线程能去查数据库其他线程等待后重新查缓存。实现上用Redis的SETNX命令获取分布式锁拿不到锁的请求sleep一小段时间后重查缓存。二是逻辑过期把Key的过期时间写到Value里查询时判断逻辑上是否过期过期了就额外开一个线程去刷新缓存主线程返回旧数据。这个方案对用户体验最友好不会因为锁等待造成响应延迟适合热点Key更新不频繁的场景。缓存雪崩发生在大量Key同时过期或者Redis集群整体宕机时。防止大量Key同时过期的方案前面说过过期时间加随机值。防止Redis整个不可用的核心是Redis高可用架构哨兵或集群模式保证自动故障转移。另外在应用层一定要做兜底如果Redis不可用热点数据接口走本地缓存Caffeine还是没有就查数据库绝对不能因为缓存挂了导致整个接口不可用。5.2 分布式环境下的事务一致性事故这里分享一个我踩过的真实事故。有一次上线运营活动用户在活动页购买限时折扣剧下单时我先创建了订单然后调用用户服务扣减活动专属的优惠券。当时优惠券扣减失败没有抛异常订单服务没感知到本地事务提交了用户没扣券但订单创建成功了。结果是同一个活动优惠券用户可以反复购买平台损失了。排查的过程也很有代表性。用户投诉说扣款金额不对我们查订单发现确实创建成功了但查优惠券记录发现根本不存在。因为订单和优惠券在两个服务里没有强一致性的保证异常被内部catch了事务照样提交。后续修复用了两招。第一招任何跨服务调用的返回结果必须做显式判断失败就向上抛异常或显式回滚不允许静默吞掉。第二招对这类跨服务一致性的核心操作引入RocketMQ事务消息本地事务提交成功后才发消息通知用户服务扣券用户服务扣券失败则消息重试重试到最大次数转发到死信队列人工处理。这个事故让我意识到分布式系统里最大的风险往往不是技术复杂度而是代码里那些被顺手吞掉的异常。5.3 视频存储与CDN回源性能问题线上有一个阶段用户反馈晚上8点到10点视频加载很慢播放一卡一卡的。排查发现不是应用服务和数据库的问题问题出在CDN回源链路。当时的存储方案是MinIO自建CDN源站直接指向MinIO的地址。高峰期几千个用户同时播放不同剧集CDN边缘节点没有缓存全部回源到MinIO服务器带宽被打满导致回源请求排队用户拿不到视频数据。问题的根源是CDN预热做得不到位。新剧上线后应该通过CDN的预热API提前把这部剧所有视频文件推送到各省的CDN节点。预热之前用户第一次访问时还是要回源但由于预热了热门剧集大部分流量在CDN边缘节点命中回源压力骤降。另外一个优化是把源站的公网带宽升到上限同时在MinIO前面加一层Nginx做代理启用静态文件缓存缓存有效的视频文件在内存中进一步降低回源到MinIO的请求量。视频转码产物也做了一下优化输出码率控制在合理范围在画质影响不大的情况下把文件体积降低让CDN缓存的效率更高。还有一个容易被忽视的点CDN的Range回源配置。播放器拖动进度条会发Range请求如果CDN没有开启Range回源每次请求都会回源拉整个视频文件源站压力直接翻倍。开启之后CDN只需要回源获取请求的那一小段数据大大降低回源流量和延迟。几点实操体会做完整套短剧系统我最想说的是高并发的核心不是某个组件有多牛而是把合适的组件放在合适的位置并做好兜底设计。Nacos解决服务发现Sentinel解决流量控制Redis解决热点读RocketMQ解决削峰和异步MinIO加CDN解决大文件分发每一层都有自己的职责各司其职才能扛住突发流量。另一个感受是设计要留有余量。数据库连接池不要用满带宽不要跑满Redis内存不要用到80%以上磁盘监控要提前告警。系统在80%负载下运行和95%负载下运行稳定性完全不是一个量级。上线后我每天必看的基础指标就是这几个一旦接近阈值就开始准备扩容而不是等报警了才处理。最后再分享一个小技巧短剧系统的性能压测一定要用真实的流量模型。不要只压测单个接口要把用户注册、剧集列表、播放鉴权、订单支付、上报记录混在一起做混合场景压测这才是线上真实的情况。我第一次压测就漏了播放上报接口结果上线后它成了第一个被打挂的服务。压测模型贴近生产系统上线才靠谱。