去年双11凌晨两点十七分，我盯着大老板的来电显示，手抖了三秒才接起来。电话那头只有一句话：“销售大屏卡了十分钟了，我现在看的是静止画面。”我当时是那家百亿级电商平台的数据架构负责人，整个数据团队为那个大屏准备了三周，结果还是崩在了峰值时刻。事后复盘时我们发现，当时的并发查询量只不过比日常峰值高了6倍，远低于我们以为的“可以扛住”的倍数。问题不出在硬件不够，出在我们对“并发查询如何吃掉资源”这件事的认知有根本偏差。这篇文章要讲的，就是那次事故之后我用两年时间验证过的一套方法，在大促级别的并发压力下，到底怎样才能让BI仪表盘真正扛住，而不是赌运气。
大多数人以为大促期间仪表盘卡顿是因为数据量太大，链路太长。但根据我对十几家中大型电商平台BI系统的观察和测试，真正的瓶颈80%以上出现在同一层：应用层的查询调度和资源分配，而不是存储层的数据量。换句话说，你的数据库可能每秒能处理几百万行数据，但它架不住几百个用户同时点开同一个大屏，每个人又触发十几个独立查询，而这些查询之间没有任何复用机制。
我们用数字说话。一个典型的电商销售大屏通常包含20-30个图表组件。每个组件背后可能对应1-3个SQL查询。一个运营总监和五个部门经理同时打开这个仪表盘，瞬间就产生至少120到540个查询请求。这些请求可能会扫描同一张订单表、同一张用户表，但它们彼此之间完全独立执行。数据库的查询缓存往往因为参数不同而无法命中，最终导致完全相同的聚合计算被执行了六遍。这不是数据问题，这是查询调度问题。
所以我们得出的核心结论非常简单：在大促场景下，避免仪表盘卡顿的本质不是提升单次查询速度，而是减少“不必要的查询”和“重复的查询”。所有技术手段都应该围绕这两个目标来设计。
先还原一个我亲身经历的场景。2023年618大促期间，我们为某品牌客户的直播带货专场部署了一套实时BI大屏。业务要求是每15秒刷新一次数据，同时有大约200个运营人员在不同城市远程打开同一个仪表盘链接。理论上，200个用户各看各的屏幕，互不影响。实际上，当所有人都盯着同一个链接时，系统在刷新间隔内会收到200次几乎完全相同的查询请求集合。
这里的坑在于，大多数BI平台默认的设计逻辑是“每个用户会话独立维护查询上下文”。这意味着用户A和用户B看到的是同一组图表，但系统会为A和B分别向数据引擎发起请求。200个并发用户不是200个查询，而是200乘以每个大屏的图表数量。按一个仪表盘30个图表来算，单次刷新就要处理6000个查询。15秒刷新一次，每秒钟就要处理400个查询。这还只是一个仪表盘。如果同时有多个业务线的仪表盘都在跑，查询量级会迅速膨胀。
很多人用“用户数×单个用户查询数”来估算并发，这个公式在日常是对的，在大促期间是错的。原因是大促期间用户行为高度同步。日常场景中用户打开仪表盘的时间是分散的，查询请求自然错峰。大促期间，所有运营人员几乎在同一时间点涌入系统，比如活动开始前5分钟、结束前30分钟、促销节点切换时刻。这些“同步点”会在瞬间制造出远超平均值的查询洪峰。
我们曾经监控过一个数据：日常场景下，BI系统的QPS峰值约为40。618当晚十点的同步刷新时刻，QPS在5秒内飙升到1200，然后跌落回150。这个1200的瞬时峰值才是导致卡顿的元凶，它持续的时间甚至不到10秒，但足以让一批查询超时、排队、最终拖垮整个连接池。
还有一个容易被忽略的点是自动刷新机制在不经意间放大了并发量。不少BI平台支持设置自动刷新间隔，比如30秒、60秒。业务方为了“看到最新数据”，通常倾向于设置较短的间隔。但他们不知道的是，自动刷新实际上是定时向所有打开该仪表盘的用户广播一次全量查询请求。如果仪表盘本身覆盖的图表很多，每一次自动刷新就等于一次小型洪峰。
我的建议很直接：大促期间，关闭所有非关键仪表盘的自动刷新功能。只保留核心作战大屏的手动刷新或由专人控制刷新节奏。这个改动不需要任何技术开发，但效果立竿见影。
日常场景中，一个查询跑5秒是可以接受的。但在大促高并发场景下，5秒的查询会持续占用数据库连接和计算资源，后续查询只能排队等待。当连接池被慢查询占满时，新请求会直接失败或超时，用户看到的就是白屏或报错，而不是“等一等就出来”。这种体验比卡顿更致命。
在我接触过的电商数据团队中，面对大促卡顿问题，有几个反应是反复出现的。这些反应看起来合理，实际上不仅解决不了问题，往往会让情况恶化。
这是最常见也最危险的认知。大促前临时扩容服务器、增加数据库实例、上调连接数上限，这些操作在硬件资源确实不足时有效，但在大多数卡顿场景中，瓶颈不在硬件，而在查询效率和调度策略。加机器相当于给一条拥堵的城市道路增加更多车道，但如果拥堵的根源是路口信号灯配时混乱，车道再多也照样堵。
我见过一个典型案例：某平台在618前将数据库从8核16G升级到32核64G，花费近十万元。大促当晚QPS峰值从原来的600提升到900后照样卡死。事后分析发现，有一条跨表Join的查询语句扫描了1.2亿行数据，升级后的数据库只是“更快地完成了这次无效扫描”，但并发一上来，CPU照样被打满。
缓存是好东西，但不分青红皂白地全量缓存会制造新的问题。大促期间很多数据是需要准实时更新的，比如订单监控、库存预警、转化率趋势。把这些数据也做了长周期缓存，业务方看到的就是过时信息，决策就会出错。正确的做法是分层缓存，我们后面会详细讲。
这个建议在技术逻辑上成立，在业务逻辑上不成立。大促期间运营人员的工作状态是高度紧张的，他们需要同时监控多个维度才能快速决策。让他们“少看点”等同于让他们“少知道点”，这在业务侧无法接受。正确的做法不是减少信息量，而是让信息的获取不再以消耗计算资源为代价。
换工具解决不了架构问题。我见过不少团队在大促卡顿后开始调研新的BI平台，花三个月选型、三个月迁移、三个月磨合，等到下一次大促时发现新平台在同样场景下也会卡，因为根本原因不是工具能力，而是使用工具的方式。任何BI工具在面对未经优化的查询模式和缺乏调度的并发请求时，表现都不会有本质差异。
这是典型的“救火式”思维。大促期间的卡顿问题必须在日常就建立预防机制，因为很多优化措施需要数据建模层面的调整、查询逻辑的重构、缓存策略的测试，这些都不是临阵磨枪能做好的。把优化留到大促后，意味着下一次大促依然要赌运气。
经过多次大促的实战和复盘，我形成了一套比较稳定的判断框架。这套框架的核心思维很简单：把BI平台的并发查询想象成一座城市的交通系统。每一条查询就是一辆车，数据库引擎就是道路网络，BI应用层就是交通指挥中心。
日常场景下，车流量不大，道路够用，信号灯按固定周期切换就行。大促场景下，相当于突然有几百辆车在同一秒冲进同一个路口。这时候，加宽道路（升级硬件）有用但有限，真正需要的是一个智能交通调度系统：知道哪些车可以拼车（查询合并）、哪些车可以走公交专用道（优先级调度）、哪些车可以改道绕行（查询路由）、哪些车可以等红灯时熄火（连接池管理）。
这是投入产出比最高的优化手段。原理很简单：当多个用户请求相同或高度相似的查询时，系统只执行一次，结果共享给所有请求者。这在技术上称为“查询结果集共享”或“物化视图复用”。
实现这一点的前提是，BI平台需要能够识别“哪些查询在逻辑上是等价的”。这听起来简单，做起来有不少细节。比如用户A筛选“2024年11月1日到11月11日”的数据，用户B筛选“2024年11月1日到11月11日”的数据，这两个查询完全等价。但如果用户B的筛选条件中有毫秒级的时间戳差异，就可能被系统判定为不同查询，从而错过合并机会。因此需要在查询标准化层面做工作，将时间粒度、维度取值进行归一化处理后再进行匹配。
并非所有查询都同等重要。在大促期间，核心作战大屏上的查询优先级应该远高于某个运营人员临时打开的探索性分析。我们可以定义三到四个优先级层级：
在工业实践中，这个优先级机制可以通过查询标签+资源队列的方式实现。BI应用层在执行查询前打上标签，数据库端根据标签将查询放入不同的资源队列，P0队列享有独立的连接池和更高的CPU权重。
同一张仪表盘上的不同图表，对数据时效性的要求可能完全不同。比如“今日累计销售额”需要准实时更新，“去年同期的销售趋势”则是完全固定的历史数据。如果后者的查询也打到实时计算引擎上，就是巨大的浪费。
查询路由的核心思想是根据查询的数据时效性需求，自动路由到不同的计算通道：
| 数据时效需求 | 路由目标 | 典型场景 |
|---|---|---|
| 实时（秒级） | 实时OLAP引擎 | 当前订单量、库存预警 |
| 近实时（分钟级） | 预计算中间层 | 小时级销售额、转化率 |
| 历史（天级） | 预物化视图/离线表 | 同期对比、历史趋势 |
| 静态（不变） | 应用层缓存 | 目标值、计划值、参考线 |
这个路由逻辑需要在仪表盘配置层面实现，让每个图表组件声明自己的“数据时效等级”，系统据此决定从哪个数据源取数。这样一来，一次仪表盘刷新可能同时命中四个不同的数据通道，大幅减少了对实时引擎的无效压力。
数据库连接池的大小是有限的。在高并发情况下，如果连接池被打满，新的查询请求会直接失败。熔断机制的作用是在连接池接近饱和时主动拒绝低优先级查询，为高优先级查询保留通道。这相当于交通拥堵时交警手动限制辅路车辆进入主路，确保主路畅通。
熔断阈值需要提前测试和设定。我的经验是，当连接池使用率达到80%时触发预警，达到90%时开始拒绝P3查询，达到95%时拒绝P2和P3，只保留P0和P1。这个策略需要提前和大促指挥部沟通确认，确保业务方理解为什么某些查询会被拒绝。
下面以我深度参与过的一家电商平台为例，展示这套方法在三次大促中的实际效果演变。该平台日均订单量约30万单，大促峰值可达日均120万单。BI系统采用主流的云原生数据仓库加前端BI工具的组合。
当时我们的做法是“大力出奇迹”：提前一个月扩容数据库集群，把所有仪表盘的自动刷新间隔统一设置为30秒，没有做任何查询层面的优化。结果是当晚十点QPS峰值达到800时，数据仓库的CPU使用率达到99%，连接池满载，大量查询超时。核心大屏卡顿了近15分钟，业务方不得不切换到备用Excel报表来应急。
事后复盘时我们分析了5000多条超时查询的SQL，发现了一个惊人的事实：其中62%的查询扫描的是同一张订单汇总表，只是筛选条件和聚合维度略有不同。这个发现直接催生了后来的查询合并机制。
基于上次的教训，我们做了三件事：一是对10张核心宽表建立了物化视图，支持查询结果复用；二是对核心大屏的图表逐个标注了时效等级，实施查询路由；三是建立了初步的优先级体系，把核心大屏标记为P0。
效果是明显的。618当晚QPS峰值达到1200，但数据仓库CPU使用率峰值只有72%，连接池使用率最高85%未触发熔断。核心大屏全程可用，未出现超过5秒的卡顿。但还有一些问题：P2和P3级查询的失败率偏高，达到18%，一些业务方抱怨自己的分析看板打不开。这说明优先级调度是有效的，但低优先级查询的用户体验还需要改善。
到了2023年双11，我们补齐了剩余的能力：上线了基于查询指纹的智能合并引擎，优化了缓存分层策略（应用缓存+数据库缓存+CDN缓存三级），完善了熔断和降级预案，并与业务方提前两周对齐了查询优先级矩阵。
结果可以看数据：当晚QPS峰值跑到了1850，是日常峰值的近15倍。数据仓库CPU使用率峰值控制在68%，核心大屏平均响应时间0.8秒，P0查询零超时，P1查询超时率仅1.2%，P2/P3查询失败率控制在6%以内。更重要的是，这些效果是在没有增加任何硬件成本的情况下实现的，我们沿用了618时的集群配置。
大促BI优化不是一套方案打天下。不同规模、不同技术栈、不同业务形态的电商平台，需要有针对性的策略。我根据自己的经验，把常见情况分为三类，分别给出建议。
这类平台的卡顿通常不是因为并发量真的很大，而是基础设施配置低+缺少基本的优化意识。建议优先级如下：
对这类平台来说，不需要投入复杂调度系统，做好基础优化就足以应对大多数场景。一台中等配置的服务器加上合理SQL优化，支撑日常几十个并发用户的大促峰值不成问题。
这类平台开始出现“并发查询叠加”带来的真正压力。除了基础优化外，需要引入系统性的查询调度：
到了这个体量，BI并发压力已经成为系统性问题。除了上述所有措施外，还需要在架构层面做出调整：
大促期间的资源是有限的，必须有所取舍。我见过一些团队试图把所有查询都优化到极致，结果反而因为精力分散导致核心场景出问题。下面讲几个典型的取舍决策。
业务方总是希望看到“最新”的数据。但“最新”是有代价的。每一秒更新一次的实时查询消耗的资源，可能是每分钟更新一次的60倍。在大促高峰期，我的建议是主动降低非核心指标的新鲜度要求。比如核心大屏的订单金额保持实时刷新，但地域分布、品类排行等辅助指标可以降到1分钟甚至5分钟刷新一次。这个决策需要和业务方提前沟通并达成一致，不要等到大促当晚再解释。
业务方希望一个屏幕上看到尽可能多的信息。但每个图表都是一组查询请求。我们曾做过一个测试：把一个30个图表的大屏拆成两个15个图表的分屏（通过Tab切换），并发压力降低了约40%，而业务方的使用效率几乎没有下降，他们本来就无法同时消化30个图表的信息。分屏+懒加载是平衡信息密度和系统压力的有效手段。
大促期间，很多公司会“全员拉通”式地分享仪表盘链接。但并不是每个人都有必要看到所有数据。通过按角色授权来控制仪表盘的可见范围，可以显著减少不必要的并发用户。比如区域数据只开放给对应区域的运营，品类数据只开放给对应品类的负责人。这个措施在管理层面可能遇到阻力，但技术负责人需要有底气推动，这不是限制信息流通，而是保障核心信息的可用性。
自助分析功能在日常是效率工具，在大促期间是资源黑洞。一个运营人员临时拖拽一个字段、更换一个筛选条件，可能触发一次扫描几千万行数据的全表查询。我的建议是：大促期间关闭或限制自助分析功能的使用，只开放预设好的、经过性能优化的标准仪表盘。这个限制可以提前一周告知，并在大促结束后立即恢复。
很多团队把BI大促优化当作一个“项目”来做，大促前突击优化，大促后归档不管。这种模式的问题在于，每次都从零开始，经验不沉淀，能力不积累。更严重的是，大促优化中暴露的许多问题本质上是日常架构缺陷的集中体现，只在大促期间打补丁解决不了根本问题。
我们在2023年双11之后做了一个重要决定：把大促期间验证有效的优化策略固化为系统的默认配置。查询优先级不再是大促专享，而是全年生效。查询路由也作为新建仪表盘的默认推荐。这个改动让日常的系统稳定性也得到了明显提升，而且下一次大促时不再需要“重新捡起来”。
不知道“正常”是什么样，就无法判断“异常”有多严重。我们建立了一套性能基线监控，记录每日、每周、每月的QPS均值、P95延迟、连接池使用率等关键指标。当大促前压力测试时，这些基线就是最可靠的对比参照。建议每个季度至少做一次性能回归测试，确保系统能力没有因为新功能上线而退化。
技术团队单方面优化能解决很多问题，但解决不了“业务期望与系统能力不匹配”这个根本矛盾。我们花了很多时间与业务团队对齐一个概念：数据的“可用”不等于“实时”。不同业务场景对数据时效性的需求不同，但大多数业务人员缺乏这个意识，默认要求“越新越好”。通过建立数据SLA，明确每种数据类型的最长响应时间承诺，我们让双方的预期对齐了，后续的优化方向也更清晰了。
回到开头那次凌晨两点的电话。那次事故之后，我花了很多时间反复想一个问题：为什么我们准备了那么久，还是没扛住？后来我明白了，因为我们一直在用“日常思维”应对“大促场景”。日常思维是“只要系统够强，就能应对任何请求”。大促场景的逻辑是相反的：系统再强也有上限，真正的能力在于如何在上限之内，用调度智慧让最重要的请求不被牺牲。
如果你是正在为下一次大促做准备的BI或数据负责人，我的建议很具体：从现在开始，做三件事。第一，拉出你的慢查询日志，找出那些被反复执行但逻辑相似的查询，这是你最该优先解决的问题。第二，和业务方开一次会，对齐大促期间的数据优先级矩阵，不是所有数据都值得实时，达成这个共识你就已经赢了一半。第三，在大促前至少进行一次3-5倍峰值的压力测试，不要相信估算，要相信压测结果。
大促不会消失，BI卡顿的挑战也不会消失。但当你把这套方法融进日常的技术架构和管理流程里，下一次凌晨电话响起时，你可以从容地接起来，告诉老板：“大屏正常，数据在跑。”
我是一名电商公司的数据分析负责人，每次大促前都做了充分的准备，数据仓库扩容、SQL优化都搞了，但一到峰值时刻，老板们盯着的大屏还是转圈圈，后台数据库CPU飙到100%。我特别想知道，除了数据量大，还有哪些隐藏的瓶颈是大多数人忽略的？
从我的实战经验看，大促卡顿的元凶并不仅仅是数据量大，更核心的是“查询爆炸”和“资源争抢”的叠加效应。在2023年双11零点，我们的BI系统瞬间涌入平常30倍的并发查询，每个查询都在请求不同的维度组合和聚合粒度，这导致OLAP引擎的查询计划生成和执行调度成了最大瓶颈。
举个例子，我们当时使用ClickHouse，单表扫描速度很快，但一旦出现大量高基数group by，CPU和内存会迅速被打满。更隐蔽的问题是：很多仪表盘控件（如下拉筛选器）会触发独立的查询，一个页面可能同时发起20个查询，这些查询在数据库层面没有智能排队，导致互相抢占资源。
所以根本原因不是单一环节薄弱，而是整个请求链路缺乏“红绿灯”机制。我的建议是：必须引入查询优先级管理（老板/核心指标的查询优先）、结果缓存（相同参数查询直接返回）以及并发限流（限制单仪表盘最大并发数）。
比如我们后来在API网关层配置了令牌桶，限定总查询QPS不超过200，超过的请求直接排队或降级提示，同时为CEO大屏单独开了一条专属连接池，才彻底解决了卡顿问题。
我司BI系统底层用Doris，数据量几百亿条，大促期间销售看板需要实时更新每小时GMV，但直接跑SQL要30秒才能出来，完全无法接受。我看到很多文章说用物化视图可以预计算，但担心刷新频率和存储成本，而且不同维度的需求太多，我该如何选择需要预计算的指标？
这个问题我踩过两次大坑。第一次是盲目把所有常用维度都建了物化视图，结果存储暴增了10倍，而且有些低频率的视图在大促前刷新占用了大量CPU，影响实时写入。
后来我总结了一套“二八法则”：只对最高频查询且计算复杂的指标进行预计算，比如GMV、订单量、退款率，按“天+小时+店铺”粒度建一个宽表物化视图，而像“SKU颜色分布”这种低频率分析则走原始表。
具体细节：我们在Doris中使用了异步物化视图，设置刷新策略为“每隔10分钟+增量触发”，并且采用分区同步，只刷新最近24小时的热分区。效果显著：核心大屏查询时间从30秒降到1.2秒，整体存储只增加了300GB（原始数据1.2TB），完全可接受。
对你来说，关键步骤是：1）先收集大促期间的真实查询日志，找出Top 10慢查询；2）针对这些查询的聚合维度创建物化视图，不贪多；3）监控物化视图刷新对写入链路的压力，必要时将刷新调度到业务低峰期（例如凌晨4点）。
我们团队尝试过给BI仪表盘加Redis缓存，但发现数据更新不及时，老板看到的是15分钟前的数据，结果被骂了。后来我把缓存时间设短到1分钟，结果数据库压力又上去了，感觉陷入了两难。有没有一种模式可以既保证近实时性又能抵御高并发？
我开发过一套“三级缓存”方案，在大促中扛住了10万QPS的仪表盘访问。第一级是浏览器本地缓存（LocalStorage）：对于用户当天第一次加载的、不频繁变化的静态数据（如店铺列表、后台配置），有效期设为1小时，这样减少了60%的重复请求。
第二级是内存缓存（比如应用层的Caffeine或Redis）：缓存那些近实时但允许微秒级延迟的中间结果，比如“当前小时GMV”在不同维度下的聚合值，TTL设为30秒，并通过消息队列（如Kafka）监听数据变更，实现基于事件的缓存失效。
第三级是数据库层的结果集缓存：对完全相同的查询（参数一致）在OLAP引擎层面直接缓存结果，不做计算。关键判断：我们曾纠结要不要使用全局缓存，但发现不同用户的筛选条件千差万别，缓存命中率极低。于是改为按“查询MD5签名”做缓存，同时给核心大屏（如高管看板）提供最高缓存优先级。
最反直觉的一点是：缓存并不是越短越好，而是要根据数据变化频率动态调整。例如大促期间GMV每分钟变化量巨大，我给它设了15秒TTL；而退货率这种相对平滑的指标设了5分钟。这样既保证了数据新鲜度，又把后端查询量减少了78%。
你的第一步应该是：分析你的仪表板中哪些组件的数据变化频率低但查询频次高（如昨日环比、品类配置），然后优先对这些组件开启多级缓存。
目前我们用的是自建Hadoop+传统BI工具，每次大促前都需要提前2周申请扩容服务器，很麻烦而且成本高。很多云厂商推荐存算分离架构（比如StarRocks+对象存储），但迁移成本让我犹豫：迁移期间业务不能停，而且我们团队没有云计算运维经验，怕中途出问题。请问您在实际项目中是如何评估与落地的？
我在2024年帮助一家电商客户完成了从传统架构到存算分离的迁移，经历很痛苦但结果值得。先讲判断：如果你的BI查询毛刺非常明显（大促峰值是日常的20倍以上），并且对成本敏感，存算分离是唯一解。传统方案要按峰值预留计算资源，平时浪费70%；
而存算分离可以在5分钟内拉起500台计算节点，用完即释放，成本降低约40%。具体迁移过程分三步：第一步，双轨运行。我们保留了旧集群，同时用StarRocks搭建了一套新集群，将核心大表的数据通过CDC实时同步到对象存储（如S3），然后通过StarRocks的External Table读写。
这一步花了2周，期间旧系统照常使用，用户无感知。第二步，切换只读流量。在大促前一个月，将报表工具的数据源指向新集群，只做查询，写入仍走旧集群。我们发现新集群在同样的查询负载下，CPU使用率下降了50%，因为计算层可以弹性扩展。第三步，全量切换。
大促前一周，进行全量迁移，将数据写入也切到新集群，对象存储作为统一存储层。避坑经验：千万不要一开始就追求完全实时，先保留1分钟的延迟，确保稳定性。
另外，选择存储计算分离的引擎时，要关注冷热数据分层能力，我们将历史5年数据放在低成本对象存储，最近7天数据放在SSD，查询时自动路由，节省了80%存储成本。如果你担心运维难度，可以先用托管服务（如腾讯云EMR+StarRocks），等团队熟悉后再自建。
最终，客户那年双11的BI仪表盘QPS峰值达到75万，没有任何卡顿，而费用比往年节省了25万元。
读者评论
作为运营总监，作者那句‘让业务方少看点图表在业务逻辑上不成立’直接戳中痛点。大促期间我们需要同时监控库存、转化率、物流时效等多个维度，任何信息延迟都可能导致决策失误。但文章也提醒了我，不是所有大屏都该设15秒自动刷新，我准备和IT团队沟通，把核心作战大屏和日常监控屏的刷新策略分开，既保实时又不浪费资源。
文章里把查询合并比作‘拼车’很形象。我在公司负责BI运维，日常踩的坑就是缓存失效和重复计算。我们试过加机器，结果峰值一上来照样卡，验证了作者说的‘瓶颈不在硬件而在查询调度’。看完后我打算在下个大促前先梳理所有仪表盘的查询逻辑，按P0-P3做优先级标签，并开启结果集共享，这些改动成本低，但效果应该比买新服务器实在。
最触动我的是‘大促后再优化’这个误区的副作用100%。作为技术负责人，以前总把性能优化留到复盘后，结果每次大促都在赌运气。文章里强调的日常预防机制，比如查询标准化、连接池调优、压力测试，确实得提前做。今年双11前我计划用作者的交通调度思维重新设计资源队列，把应急车道留给核心大屏，避免像去年那样全员卡死在峰值时刻。