假期查询洪峰下的数据库读写分离排期，核心原则是“扩容先行、压测兜底、预案在前”，排期要围绕流量预估、读写分离压测、主从延迟治理、应急预案四个维度展开，在洪峰到来前完成所有变更。
假期查询洪峰下，数据库读写分离排期为什么容易翻车
很多团队对读写分离的理解是“搭好了就能扛住流量”，但假期的查询洪峰和日常完全不是一回事，日常流量是均匀的，假期的流量是脉冲式的，除夕抢票、春节查余票、五一查景区预约、国庆查酒店库存，这些场景都在极短时间内把查询请求打到数据库上，读写分离在这种场景下的表现，取决于排期是否把“查询比例暴涨”这件事想透。
排期翻车的常见原因有三个。
- 只做了容量评估，没做流量形态评估，假期查询洪峰的特点是“读多写少”极端化，平时读写的比例可能在几比一，假期热点场景下可能冲到几十比一,从库的QPS天花板成了整个系统的瓶颈。
- 主从延迟被低估，读写分离的核心问题是延迟窗口，假期场景下主库写入量虽然占比小，但绝对值可能比平时高，加上从库查询压力大，延迟可能从毫秒级膨胀到秒级,直接导致用户刚提交的订单查不到。
- 预案只写了“重启”和“扩容”，假期中间出了问题，DBA不敢动，业务方干着急，就是因为排期里没写清楚什么情况下允许降级、什么情况下可以切流量。
行业共识认为，读写分离排期的首要任务是确定“流量峰值模型”，而不是先讨论技术方案。 先回答假期里每天的查询量级、峰值时段、热点数据占比,再排具体的变更计划。
假期查询洪峰下读写分离排期怎么做
排期不是一张表，是三层动作：准备工作、压测验证、应急预案，把时间轴拉开看,大多数团队需要的是一份两周左右的排期表。
第一步：梳理业务查询场景，确定读路径依赖
假期洪峰下，查询场景通常分三类：实时一致性查询、弱一致性查询、离线统计查询，读写分离只能承载后两类,排期里必须明确哪些接口可以走从库。
实操上可以这样检查：
- 遍历所有查询接口，找出包含“刚提交的数据必须立刻可见”逻辑的接口,这类接口不能走从库。
- 对弱一致性接口，评估延迟窗口容忍度，比如用户查询订单状态,延迟30秒是否可接受。
- 把允许走从库的接口列表写进排期文档,并标出每个接口预估的QPS。
这里最容易漏掉的是“兜底读主”逻辑。 很多系统在从库查询失败时会自动重试主库，假期洪峰下这个兜底逻辑会导致主库流量暴涨，排期里必须明确重试策略的阈值，什么条件下允许重试,什么条件下直接返回降级结果。
第二步：容量评估与扩容排期
容量的核心指标不是“QPS多少”，而是“单从库QPS×从库数量”和“主从延迟P99”的关系，假期场景下,需要给每个从库预留一定程度的余量。
容量评估参考这几项：
- 历年同期查询量的增长趋势，近年来的数据显示节假日流量峰值普遍是平日的数倍,部分头部平台的热点场景会出现更极端的落差。
- 每个从库的CPU、内存、连接数水位。
- 从库和主库之间的网络延迟。
- 连接池最大连接数和当前配置的差距。
扩容操作建议排在洪峰前一周左右完成。 太早会导致资源浪费，太晚则万一有问题没有返工时间，扩容之后需要同步修改负载均衡配置和连接池配置，这一步经常被漏掉，很多团队扩容了实例数，但应用层连接池上限没动,新实例根本没接到流量。
第三步：读写分离压测怎么排
压测是排期里最容易被压缩的环节，但假期场景下的读写分离压测，重点不在“压到多少QPS”，而在“压出主从延迟的增长曲线”。
压测方案建议分四步走：
- 第一步，单独对从库施压,找到单从库的拐点QPS。
- 第二步，对一主多从整体施压,观察主库binlog同步是否追得上。
- 第三步，模拟热点查询，比如同一个商品ID的高并发查询,观察缓存穿透率。
- 第四步，读写混合压测，按预估的读写比例混跑,测出延迟P99。
压测结果直接决定排期是否需要调整。 如果压测发现延迟超过预期，需要在洪峰前做的不是调参，而是加从库或者改缓存策略，压测过程中记录的数据，就是后面应急预案里“什么阈值触发什么动作”的依据。
第四步：应急预案排期
应急预案不是文档，是排期里明确时间点的动作清单，读写分离场景下,应急预案要覆盖三个层级：
- 从库故障：备份从库自动顶上,还是直接切流量到主库。
- 延迟超阈值：是扩大延迟容忍窗口,还是强制部分查询走主库。
- 主库压力异常：是否允许降级为非核心查询返回缓存数据。
每个预案都要写着“谁来做、怎么做、什么指标触发、回滚怎么搞”。 另外建议在洪峰前安排一次应急预案演练，不用模拟全场景，挑“从库宕机”和“延迟超过阈值”两个最常见场景演练即可，这个动作能发现很多排期里没考虑到的问题，比如报警没接对、脚本没有执行权限等。
第五步：假期期间的监控与值守排期
监控指标不要贪多,写死五个就够：
- 从库QPS和CPU使用率。
- 主从复制延迟。
- 从库查询失败率。
- 主库连接数。
- 缓存命中率。
值守排期要明确“谁来盯监控”“出问题时找谁确认”，这里建议排一个一线值班、一个二线DBA、一个业务接口负责人，三层联动，很多团队假期待命只有一个小群，出了问题群里没人拍板，就等着工程师远程连电脑,洪峰就过去了。
读写分离延迟会导致什么问题
延迟是读写分离的天然属性，排期里如果没有延迟治理方案,假期出问题几乎是必然的。
主从延迟引发的数据不一致
主从延迟导致的典型场景：用户在假期抢到票后立刻查询订单详情，订单查不到，这个问题的根源是写入主库的数据还没同步到从库,查询就落在了从库上。
解决办法一般是两个方向。
- 增加延迟容忍度，前端展示“数据同步中”的loading状态，但这需要业务侧配合,排期里需要预留前后端联调时间。
- 关键接口强制读主，但这会增加主库压力,需要和容量评估联动。
高并发下的缓存穿透
假期热点的集中度非常高，比如春节回家的车票、五一热门景区的门票、国庆前夜的酒店库存，这些热点数据一旦缓存过期，请求会直接打到从库上,从库压力瞬间翻倍。
排期里要专门安排热点缓存方案的落地时间。 比如热点数据的缓存过期时间调整为随机值，避免同一时刻集体失效，或者对热点key做多级缓存，这些动作都不复杂，但需要业务侧配合,必须写在排期里留出时间。
从库负载不均
很多时候从库挂了不是真的挂了，是被某一类重查询拖垮的，假期场景下，复杂报表查询和简单查询混在同一个从库上，复杂查询耗尽CPU，简单查询全部排队，排期里如果没做从库流量拆分，比如报表查询走单独的从库，就会出现“一个老鼠坏一锅汤”的情况。
实操上是按查询类型拆分从库，把统计类、报表类查询单独分到专用从库，核心链路查询走另一组从库。
假期读写分离排期的时间轴模板
把以上动作落成时间轴,一份可用的排期模板大概是这样的：
- T-14天： 梳理查询场景，确定读写分离边界,列出风险清单。
- T-10天：
完成容量评估和扩容申请,确认从库资源。
- T-7天： 完成扩容变更,同步更新连接池和负载均衡配置。
- T-5天： 执行读写分离压测,记录延迟数据和拐点QPS。
- T-3天： 根据压测结果微调配置，更新应急预案,完成演练。
- T-1天： 最终巡检，确认监控报警正常,值守人员到位。
- T日： 按预案值守，监控核心指标,记录异常现象。
- T+3天： 撰写复盘报告,对比预估流量和实际流量的差距。
这个时间轴不是死板的，关键动作是“压测之前预留足够时间做配置调整”，如果压测结果不理想，最先需要压缩的不是压测时间,而是提前扩容。
读写分离排期后，节后复盘怎么做
复盘不是总结“我们扛住了”,而是回答三个问题：
- 预估的查询峰值和实际查询峰值差距有多少,下次预估是否需要调整系数。
- 主从延迟的概率分布曲线长什么样，哪些时间段的延迟最明显,能不能提前预判。
- 应急预案哪些动作真正被触发过,触发后是否按预期生效。
复盘的产出物应该是一份更新过的读写分离排期检查清单，下次节假日排期直接复用清单，再根据新的业务场景增删项目，这样可以有效避免每次假期的排期从头开始讨论,也能让团队积累针对自身业务特征的洪峰应对经验。
常见问题解答
假期期间读写分离的主从延迟突然变大怎么办
先判断延迟来源，从库CPU是否打满，若是则考虑临时摘掉非核心查询流量，如果从库CPU正常，检查主库binlog写入情况，确认是否存在大事务，操作顺序建议先限流非核心查询，再观察延迟是否回落,不要直接扩容或重启从库。
读写分离排期有没有必要做全链路压测
有必要，但不建议全链路、全场景覆盖。 假期洪峰下读写分离的关键瓶颈集中在从库QPS、主从延迟、缓存穿透三个点，排期围绕这三个点做专项压测即可，目前全链路压测的难点在于流量模拟和依赖隔离，如果历史同期数据积累充分,可以采用基于历史流量回放的压测方式。
什么时候读写分离不再适用，需要引入缓存或分库分表
当从库实例数量达到一定规模后，查询QPS仍然超出预期，则说明读写分离的扩展性已经到顶，需要考虑缓存层分担或分库分表，判断标准是：单从库的CPU在高峰时段持续处于高水位，并且增加从库实例无法线性降低延迟,此时排期的重心应该转向缓存预热方案和分片键设计。