这套架构已在星逐赛事源码中完整实现。代码开源无加密支持二次开发。演示站已搭建想了解技术细节或查看效果欢迎私信交流。去年五大联赛期间巴萨vs皇马国家德比我们的平台在巅峰时刻直接崩溃了。10万用户同时涌入直播间卡死、页面打不开、弹幕发不出去最后整个服务瘫了。投了那么多钱引的流量在最关键的时候接了锅。问题根源不是业务逻辑有bug而是那套采购的源码根本没有高并发设计——没有分流、没有降级、没有缓存策略单机扛所有请求不崩才怪。那次之后我们痛定思痛招了批技术人员从零自研了一套源码也就是现在公司正在使用的星逐赛事。经过完整的架构重构和多次压测验证这套源码已经能在百万级并发下稳定运行。下面把这套架构从接入层到数据层的完整设计方案写出来纯技术干货供同样在做体育直播平台的同行参考。一、先搞清楚体育直播的并发模型体育直播的流量模型和电商秒杀不一样和社交feed流也不一样。搞不清楚流量特征架构设计就是空中楼阁。流量特征极端尖峰以国家德比为例开赛前10分钟单直播间在线人数从0暴增到10万。比赛期间持续高位运行梅西进球的那一瞬间弹幕量暴增10倍。中场休息缓慢下降下半场开赛再次回升。90分钟内出现三次流量尖峰——开赛涌入、进球爆发、终场冲刺。请求特征读多写少读请求占95%以上——拉取直播间信息、拉取弹幕列表、拉取实时比分、拉取评论列表。写请求不到5%——发送弹幕、投注竞猜、送礼物、点赞评论。这种95%读5%写的特征意味着缓存做得好数据库压力能降90%以上。反之所有请求穿透到数据库再强的机器也扛不住。核心指标并发连接数≠QPS并发连接数同时在线用户数10万人同时在线。QPS每秒请求数每个用户每分钟操作3-5次10万人在线≈5000-8000 QPS。两者都要扛但压力性质不同连接的保持消耗内存和带宽QPS消耗CPU和数据库连接。二、接入层优化把流量挡在门外流量到达后端之前接入层是第一道防线。这道防线做好了能挡住80%的压力。负载均衡策略Nginx upstream配置加权轮询高性能服务器分配更高权重。开启keepalive长连接减少TCP握手开销。主动健康检查定期探测后端端口连续失败3次标记不可用自动剔除。故障恢复后自动加入对用户透明。WebSocket长连接配置尤其关键proxy_read_timeout设3600秒避免连接被提前断开。配置proxy_http_version 1.1和Upgrade头支持HTTP到WebSocket的协议升级。CDN多级缓存静态资源全部走CDN图片缓存7天CSS/JS缓存30天HTML缓存5分钟。HLS直播流同样走CDNm3u8缓存10秒ts缓存1小时回源带宽降低70%以上。关键配置合并回源分片预热避免大量用户同时拉流时产生回源风暴。开启智能DNS解析华南用户自动调度到华南节点电信用户走电信线路。动静分离Nginx层做动静分离动态请求API接口反向代理到后端服务静态资源图片、CSS、JS走CDN或本地缓存。互不干扰静态请求不消耗后端连接池资源。三、业务层优化代码扛得住才是真的扛得住接入层过滤完之后真实请求到达业务层。这一层的并发能力取决于代码质量、连接池配置和异步处理能力。接口幂等性设计投注接口要幂等——用户手抖点了两次投注不能扣两次钱。支付回调要幂等——微信重复通知只能处理一次。提现申请要幂等——重复提交只能生成一个提现单。实现方案每个请求带唯一requestId后端用Redis缓存处理结果。首次请求处理完成结果存入Rediskey: idempotent:{requestId}TTL: 24h。重复请求直接返回缓存结果不重复处理。分布式锁的正确用法竞猜投注场景单用户对同一比赛只能投注一次需要分布式锁保证并发安全。错误写法synchronized(this)只在单机有效分布式下完全失效。正确写法Redis SETNX原子操作锁超时时间5秒防死锁。javaString lockKey bet:lock: matchId : userId; Boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 5, TimeUnit.SECONDS); if (!locked) { throw new DuplicateBetException(请勿重复投注); } try { // 投注业务逻辑 } finally { redisTemplate.delete(lockKey); }乐观锁 vs 悲观锁扣减余额用乐观锁版本号机制适合读多写少。sqlUPDATE user SET balance balance - #{amount}, version version 1 WHERE id #{userId} AND balance #{amount} AND version #{version}库存扣减用悲观锁SELECT ... FOR UPDATE适合写多读少。原则能不用锁就不用锁能用乐观锁就不用悲观锁。异步处理与线程池发送弹幕可以异步落库——先回发送成功再慢慢写数据库。投注结算可以异步处理——先记录投注赛后再结算。推送通知可以异步发送——主流程不等待第三方接口返回。星逐赛事的线程池配置核心线程数CPU核心数×2最大线程数CPU核心数×4有界队列防止OOM拒绝策略CallerRunsPolicy保证任务不丢失。四、数据层优化数据库扛不住怎么办数据层是最后一道防线也是最容易成为瓶颈的地方。读写分离主库写、从库读。直播间信息、赛事列表、评论列表这些读请求全部走从库主库只处理写入操作。星逐赛事通过ShardingSphere-JDBC实现读写分离代码零侵入。分库分表单表数据量超过500万行或单库QPS超过5000时必须分库分表。用户表按userId hash取模分16张表订单表按时间按月分表。多级缓存星逐赛事采用三级缓存架构L1本地缓存Caffeine命中率60%响应时间1msL2 Redis缓存命中率30%响应时间5msL3数据库命中率10%响应时间50ms三级缓存将数据库直接请求量降低90%以上。缓存防击穿热点数据用互斥锁重建缓存只允许一个线程去查数据库。javapublic Object getWithMutex(String key) { Object value redisTemplate.opsForValue().get(key); if (value ! null) { return value; } String lockKey lock: key; Boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 30, TimeUnit.SECONDS); if (locked) { try { value dao.queryFromDB(); redisTemplate.opsForValue().set(key, value, 300, TimeUnit.SECONDS); return value; } finally { redisTemplate.delete(lockKey); } } Thread.sleep(50); return getWithMutex(key); }连接池调优HikariCP配置maximumPoolSize50minimumIdle10connectionTimeout30000msidleTimeout600000msmaxLifetime1800000ms。50是大多数场景的合理值具体根据压测调整。慢查询治理开启慢查询日志long_query_time1秒用Druid监控TOP慢SQL。给WHERE、JOIN、ORDER BY字段加索引避免SELECT *拆解复杂JOIN为多次简单查询。五、流媒体层优化直播流分发与加速图片加载慢还能忍直播流卡顿用户直接走人。推流端优化推流协议用RTMP延迟最低码率3000-5000Kbps分辨率1080P帧率30fps。开启GOP缓存减少关键帧丢失导致的画面花屏。拉流端优化播放协议用HLS兼容性最好切片时长4秒延迟3-5秒预加载3个切片开启硬解码设置2秒缓冲阈值。多线路CDN容灾星逐赛事配置3条CDN线路——主线路、备线路1、备线路2不同云厂商避免单一供应商故障。播放器每5秒检测当前线路加载速度超3秒则标记不稳定连续3次触发自动切换。切换过程无缝衔接用户无感知。多清晰度转码提供原画、1080P、720P、480P、360P五档清晰度根据用户网络自动切换。只对热门赛事做多码率转码普通赛事只保留原画和720P两档以控制成本。六、全链路压测能不能扛得住测了才知道星逐赛事的压测常态化流程压测工具JMeter 云PTS组合日常用JMeter大型压测用云PTS。核心指标吞吐量TPS、响应时间P99/P95/P50、错误率、CPU/内存/网络IO。压测场景单接口压测评估承载能力混合场景压测模拟真实用户行为尖峰流量压测模拟开赛前10分钟流量暴增。瓶颈定位Arthas在线诊断线程栈和CPU热点JProfiler分析内存和CPUSkyWalking全链路追踪定位慢接口。瓶颈现象根因解决方案CPU飙高大量计算或GC频繁优化算法、减少对象创建内存溢出内存泄漏或堆内存不足MAT分析dump、修复泄漏接口超时数据库慢查询或第三方慢加索引、加缓存、改异步连接池满连接未释放或池太小检查代码关闭连接、调大池带宽打满静态资源未走CDN或码率过高资源上CDN、降低推流码率七、总结百万并发架构的技术图谱星逐赛事的完整架构体系接入层Nginx负载均衡加权轮询健康检查 CDN多级缓存静态资源直播流 智能DNS解析就近访问 动静分离静态走CDN动态走后端业务层Spring Boot微服务6个独立模块 接口幂等设计requestId防重复 分布式锁Redis SETNX 乐观锁版本号机制 异步处理线程池消息队列数据层MySQL主从读写分离主写从读 分库分表ShardingSphere 多级缓存CaffeineRedis 连接池调优HikariCP 慢查询治理索引SQL优化流媒体层ZLMediaKit流媒体服务器 HLS切片分发 多线路CDN容灾3条线路自动切换 多清晰度转码监控层PrometheusGrafana业务监控 ELK日志收集 SkyWalking链路追踪从那次国家德比平台崩溃到星逐赛事百万并发稳定运行这条路走了一年多。核心经验就三条接入层把流量挡在前面Nginx分流CDN缓存动静分离这一层做不好后端再强也扛不住。业务层把压力分散到后面幂等防重复、锁保并发、异步解耦耗时、缓存降数据库压力。数据层把数据稳在下面读写分离扩读、分库分表扩写、连接池调优防耗尽、慢查询治理防拖垮。