面试提到的问题

怎么排查MySQL的慢查询？MySQL慢查询可能的原因？

  1. 开启慢查询日志、Explain命令看看SQL有没有走索引
  2. 没加索引、没走索引、索引失效、锁冲突（长事务不提交，select … for update加了行锁间隙锁导致其他事务无法修改）、表数据量太大没有分库分表、数据库自身问题（网络问题、连接池满了、CPU100%、内存不足、磁盘IO慢）、offset分页太长、join大表关联大表

数据库写SQL时有没有踩坑？使用数据库的时候你有遇到什么问题吗？数据库用的是什么？

  1. 主要操作的是离线数仓，Hadoop、Hive和Spark，计算引擎从Spark换到了自研的SuperSQL，处理遗留SQL脚本的时候遇到了测试时没问题，流水线执行时超时错误，发现是计算引擎没选对。
  2. Join顺序要小表Join大表比较好；一对多Join时要先去重；
  3. 在Join的key中不要出现NULL，可能会数据倾斜
  4. Union All 拼接比Join效率要高，虽然都能实现；Union 拼接+去重，Union All 只拼接，速度快；
  5. 处理跨时间分区的增量表数据

【准备】怎么实现灰度的？灰度怎么保证固定比例的流量迁移到新的Pod？CPU容量预警是在什么时候处理的？在事前、事中、事后能怎么预警？事后对比过预警容量与真实容量的差别吗？预警的准确性怎么确认？后续有跟进吗？

  1. 发布变更单会进过调权灰度一台机器5分钟、灰度0.1%、灰度10%、灰度50%、全量发布，CPU容量预警是在调权灰度阶段进行的，控制分析时间在5分钟内。灰度的机器和没灰度的机器的调用量比来预测。
  2. 发布的话是先拉起一堆新Pod，将变更后的进程启动到新Pod，然后慢慢把流量迁移到新Pod上，灰度其实就是流量迁移。不是踢流发布，不需要先下线再启动变更后的进程，不然的话可能一下踢流太多在线机器的话导致问题，直接从灰度10%升级到全量发布会直接导致线上可用机器减少出现问题。（蓝绿发布、金丝雀发布、热更新、踢流发布）
  3. 可以尝试用网关来让流量迁移到新的Pod上；一般做法是在RPC服务中去处理流量迁移任务，因为公司内代码都是通过RPC来调用服务的，给新的在灰度的Pod打上对应的标签，RPC调用的时候流量按比例迁移到Pod上
  4. 事前是业务去review；预警的准确性认为是80%，因为之前根因分析也是用皮尔逊系数处理的，根因分析准确性为80%左右
  5. 预警容量与真实容量有差别，因为有一个粗糙的假设，每个调用量消耗的CPU负载是一样的
  6. 用最近7天的CPU负载曲线通过最小二乘法建立出线性模型，如果皮尔逊系数（相关性系数）>0.8就使用模型预测，否则使用兜底；兜底是用去除毛刺（已有功能）后的CPU负载曲线峰值乘上灰度和没灰度之间的调用量比值算出可能峰值，与阈值相比；超了就阻断变更，提示先扩容机器再发布，先扩容后续机器多了再缩容也行；之前有故障单就是因为没扩容机器，发布后缺少机器

【准备】告警分类做了些啥？告警特征分析有啥用？还有什么方法减少无效告警吗？（剔除可自愈的告警、机器学习算法代替阈值和不同算法剔除误告）

  1. 主要就是增加可能有用的维度筛选掉无效告警，方便业务排查告警，比如最近7天首次告警可以筛选掉频繁告警（占所有告警的20%左右，可能是阈值设置错误，毕竟连续告警那么多天都没有去处理或阻断告警说明不重要），是否在灰度期间告警（可以筛选出与最近变更强相关的告警），当然也有兜底（有展示所有告警事件单的选项）
  2. 减少无效告警的方法：剔除可自愈的告警（有些调用下游服务的告警可能只是网络抖动导致下游服务响应时间慢，不是下游服务有问题，过十分钟就自动好了）、【研究了下但还没上线】机器学习算法（时间序列异常检测）代替阈值剔除误告（如果前后的曲线周期性比较相似，但由于营销活动导致流量上涨不少超过阈值，这种是误告需要忽略）
  3. 研究机器学习算法时的难点是需要对几千种告警曲线进行标记，用大模型进行批量标记；大模型比较适合处理图片，所以给大模型监控数据点值转化出的图片；虽然有人工复查，但是不可能完全准确，可以先做个原型上线再修改（分布式打标），不过后续离职了没有上线，只是用大模型打的标测试了机器学习算法，对比了下召回率、准确率、F1分数…指标

【准备】变更单审计是事后审计的吗？能不能在发布的过程中阻断？

  1. 是事后审计的，可以在发布的过程中阻断；因为之前每个部门自己管理发布流程没有统一接入到DevOps平台上，变更单流程是各个部门通过我们提供的统一API上报的，所以审计主要是看看历史不合规的变更单有多少，然后展示一下；统一接入DevOps平台后用的是同一套变更剧本发布系统，普通发布有限制必须灰度、必须有对应的审批链、必须有对应的需求链接，只有紧急修故障的特殊变更单才能不用灰度、减少审批流程

【准备】你如果要继续迭代，还有什么地方可以优化呢？

  1. 消除误告（前后周期性相同但平均水位提升【周期性不变可能只是营销放量，并不是告警】）和可自愈告警（由于网络波动，调用下游服务的响应时间可能超出阈值，这种告警是可以自愈的，过段时间网络好了之后就能自动恢复，无需告警；只有下游服务出问题【最终失败；内存、CPU、磁盘……爆了】导致的响应时间超出阈值才是需要告的告警）
  2. 提升可接入可监控告警的数量级，后续要接入全公司的告警，实现新的架构（目前使用开源的Prometheus监控，可以考虑切换到公司内现有的监控，不需要单独维护Prometheus）保证放量后能接住
  3. 当然要做好兜底，保证查全

【准备】怎么设定出这些告警特征的？

  1. 通过编写SQL得出报表图（分析不同类型告警中符合该特征的告警占总告警的比例【20%】）预研，后续关注业务同学的反馈，离职了没有跟进
  2. 变更单主要是对离线数据库里的历史变更单审计

实习中实现的规则引擎是啥？（就是模板方法+可扩展责任链/注册机制；聊一下正常的规则引擎指的是啥？）规则引擎的规则不只一个维度，长期维护下去会有几百条规则，如果同时命中多个规则会影响性能吗，怎么处理？

【看】假设服务器CPU都跑满100%，你会怎么排查问题？用什么命令排查？火焰图有什么用，Arthas用什么命令？

【看】服务请求量很多并且请求出现了服务超时，但CPU的利用率很低，需要排查哪些方面？（线程池的核心线程数配置的太小、DB的连接池大小太小、文件描述符不够、线程数上限、内存不足、网络IO、等待数据库返回、磁盘IO、调用第三方接口时返回慢或超时、阻塞式锁的竞争严重、代码里sleep太久……还有很多）

告警特征分析做了什么来解耦？加完之后的影响？引入Redis会不会增加复杂度？会不会降低可扩展性？

分析CPU容量风险的时候怎么解决毛刺、异常点？

  1. 别人实现好的，可以用P95、P99观察

有没有监测过Redis上线后是否满足延迟要求？如果有告警的话怎么排查告警？

发布的时候是踢流发布吗？除了踢流发布还有哪些发布方式？介绍一下蓝绿发布、金丝雀发布、热更新？

怎么部署上线的？是用了K8s/Docker吗，介绍一下？告警是怎么埋点获取到的？

灰度到K8s新Pod上的时候，在转发性能上有没有特殊优化？负载均衡相关的？（新Pod需要预热，不能一上来就满负载）

如果机器出现故障怎么自动容灾、自动下线？Redis、MySQL的容灾切换、集群技术？

了解K8s吗？了解Docker吗？Docker和K8s的区别？Docker是怎么实现资源的隔离？Docker和虚拟机的区别是什么？k8s pod是什么？k8s pod和docker的容器什么关系？

分布式系统中告警会打印一个日志里面有错误码，有一个Trace ID，怎么使用AI分析日志找出错误码是哪块代码里面抛出来的？

AI编程里面怎么固化对生成代码的基本要求

AI编程里面让AI修改的时候不影响以前的业务逻辑，只修改需要修改的

Redis里面的key会不会越来越多，怎么清理

每次启动服务的时候Redis会不会要重新拉MySQL离线表数据，Redis是从消息队列里面拉去最新的告警吗？

冷启动，启动消费线程和同步线程双线程，同步需要消耗一段时间，这时MySQL里面一直增加数据，消息队列也来数据了，怎么保证数据不重复？

相关文章

  1. https://www.notion.so/7-314254b59a8380ad85cfcaadd3ba4fa8
  2. https://www.notion.so/31a254b59a8380c1bc04cc503475cc61
  3. https://www.notion.so/SOA-31a254b59a83807ba50ceabcca6910f1
  4. https://www.notion.so/IDKEY-MCP-31a254b59a838013b6c5fd0033d9a609
  5. https://www.notion.so/315254b59a838039b635db83846b5b48
  6. https://www.notion.so/315254b59a8380b1846ee28aa76c1a51
  7. https://www.notion.so/IDKey-315254b59a83805ea41ace2ecd06c568
  8. https://www.notion.so/IDKEY-315254b59a8380b99875eac26a0267ac
  9. https://www.notion.so/315254b59a838075a91be79e7ac15716
  10. https://www.notion.so/315254b59a8380d39a83c3c1892e978d
  11. https://www.notion.so/3-4-5-314254b59a83801686abf8551e5d6ed4
  12. https://www.notion.so/313254b59a8380f5880dcc738ebea1bb
  13. https://www.notion.so/313254b59a8380859956cfeee15d3526
  14. https://www.notion.so/CPU-314254b59a8380c39de5f3b0e3ba25a6
  15. https://www.notion.so/314254b59a8380a68b18e9583b8919c6
  16. https://www.notion.so/314254b59a8380d1819eefcd1255ff85
  17. https://www.notion.so/314254b59a8380d7a8f1ca0cb41bb29e
  18. https://www.notion.so/31a254b59a83800d875dfe845faa45d6

可以看看

  1. https://www.notion.so/314254b59a8380fcb196ca97deba561c
  2. https://www.notion.so/314254b59a83803da226f294b00f7a85
  3. https://www.notion.so/agent-server-314254b59a83804385e1d25722e66450
  4. https://www.notion.so/Appset-314254b59a8380bcb460c7c5b718fa2e

告警拓扑图

优化拓扑图组件

适配Vue3，增加右上角徽章展示、相关链路高亮、背景染色、Tooltip展示等功能，增强用户体验和信息传达效果。

告警分类

  1. 现象告警：用例告警，反映真实业务异常（拓扑图展示了CGI所属的类型、展示了告警事件单是在哪个用例步骤上的【根据告警事件单的监控id查出来】）
  2. 变更模块告警：变更模块自身 + 直接/间接上游（拓扑图展示了告警事件单是在哪个模块上的）
  3. 下游资源告警：直接/间接下游模块 + 单机资源（拓扑图展示了告警事件单是在哪个模块上的）

告警分类具体实现

  1. 下游模块资源告警负载，是直接下游还是要包含间接下游。—— 现阶段仅直接下游模块
  2. 现象告警展示视图中调用架构上的最小单元是模块，模块模块之间的连接是仅要模块间的关系？—— 按模块接口来展示，且架构图中先展示模块接口维度的最终失败的告警
  3. 变更模块维度的视图，直接展示告警事件单？ —— 直接展示跟变更模块能够关联起来的所有告警
  4. 下游模块资源告警，需要包含容量评估预测的告警吗？—— 不包含
  5. 阶段一是否是仅需要通过资产的关系关联到告警的即可，不需要做变更相关性分析？ —— 可以先不做变更相关性的分析

使用现有的模调接口查询，找到与变更模块相关的模块（其中告警事件单有监控的id，可以根据监控id查询到监控的模块）：从模块出发，找到调用到该模块的CGI，再查询完整的CGI调用链路。

2025.11–2026.03实习相关整理-告警查找链路分析

从上游消息队列中提取告警信息并落库。

重复告警的原因

  1. https://www.notion.so/315254b59a838039b635db83846b5b48

屏蔽截止时间

告警标签-查询最近7天首次告警

使用Redis实现-设计方案

当前存在一个告警消息队列，承载着告警事件的实时流转。有一个服务持续消费该队列，并将消息写入数据库的表中进行持久化存储。约2000万条

需要开发一个新的告警分析服务，该服务需要：实时消费消息队列中的告警消息；判断每条告警是否在最近7天内出现过；如果出现过，分别是哪些天出现过；将判断结果写入新的表中供后续业务使用

备注：线程1（消费线程）在冷启动期间，由于redis中没有最近7天的历史告警信息，可能会有短暂的窗口期，只能当作是首次出现告警。

指标 数值 说明
峰值 TPS ~40 条/秒 消息队列写入速度峰值
日均消息量 ~10万条 每日新增消息数量
7日消息量 ~70万条 去重判断的数据窗口大小
历史总量 2000万条 老表现有数据规模

过期策略：由于 Sorted Set 的 member 无法单独设置 TTL，采用以下策略：

  1. 查询时清理：每次查询前执行 ZREMRANGEBYSCORE key 0 <7天前时间戳>
  2. Key 级别 TTL：设置 8 天过期，作为兜底清理不活跃 key
  3. Lua 脚本原子操作：将清理、查询、写入合并，减少网络往返

QPS，每秒查询 TPS，每秒事务，在非常普通的意义上，术语每秒事务数是指每秒由某些实体执行的原子动作的数量。从更严格的角度来看，DBMS供应商和用户社区通常使用该术语来表示每秒执行的数据库事务数。 RT，响应时间 Concurrency，并发数 QPS（TPS）= 并发数/平均响应时间 并发数 = QPS*平均响应时间

  1. https://www.notion.so/Redis-314254b59a8380878cade73c89631ef7
  2. https://www.notion.so/DB-314254b59a838032ac7efc6d001847c9
  3. https://www.notion.so/314254b59a838098a306c890caf08273
  4. https://www.notion.so/31a254b59a8380c1bc04cc503475cc61
  5. https://www.notion.so/18-AlarmAnalyzer-318254b59a8381f09677ecae5b20f546
  6. https://www.notion.so/09-318254b59a83818cb73bdc34e0bdf930
  7. https://www.notion.so/01-Redis-TTL-318254b59a8381f0a3eaef2255831269

服务需要支撑 40 TPS 的实时查询与写入

为什么不能直接查询表：即使建立索引，需要在表被不断插入数据（插入速度也是40TPS）的情况下，在25ms(40TPS)内查询并返回结果，DB无法支撑峰值情况下的实时查询，会造成告警消息积压。

结论：需要引入 Redis 缓存层，将 7 天内的告警数据缓存在内存中，降低查询延迟。

注意跨天时间段处理，要看最近一周该告警的天数不能直接用当前时间戳减去7天时间再算日期，这可能会变成“最近一周告警8天”得到8个日期，需要获取当前日期0点的时间戳再减去6天时间再算日期

区分冷启动和正常消费的流程图

告警分析：变更关联分析、告警标签分析 规则引擎 + 策略模式的架构 任务队列实现并发控制 时区处理：所有时间计算均使用 Intl.DateTimeFormat + Asia/Shanghai 时区，不依赖服务器本地时区。 任务队列容量：当前每进程 30 并发、300 排队。如果告警量增长，需关注队列溢出监控指标并适时调整参数。

可以新增 消息队列的订阅 通过异步任务去接受告警消息；为现有功能添加耗时监控

两种要区别的类型

因为告警可能持续触发，告警触发间隔一般设置为1分钟/5分钟，最短间隔也有1秒。 可能会有告警持续触发一段时间，触发多次后才被解决。这种也要算成“最近一周首次出现”，因为排查告警也需要一定的时间，并不能严格设置为必须第一次出现才算首次告警。 所以，如果有多次告警但都是在6小时内统一触发的，后续没有新的触发，则为“最近一周首次出现”；如果有多次告警但不全是在6小时以内触发的，后续有新的触发，则正常分析为“最近一周n天出现”

“最近一周首次出现”： 说明该告警是最近7天首次触发的 “最近一周1天出现”：说明该告警是最近7天内范围内，仅在今天触发的，且在今天非首次触发

Redis里面的key会不会越来越多，怎么清理

过期策略：由于 Sorted Set 的 member 无法单独设置 TTL，采用以下策略：

  1. 查询时清理：每次查询前执行 ZREMRANGEBYSCORE key 0 <7天前时间戳>
  2. Key 级别 TTL：设置 8 天过期，作为兜底清理不活跃 key
  3. Lua 脚本原子操作：将清理、查询、写入合并，减少网络往返

每次启动服务的时候Redis会不会要重新拉MySQL离线表数据，Redis是从消息队列里面拉去最新的告警吗？

需要抢一个分布式锁，抢到分布式锁的服务会启动两个线程：消费线程和同步线程，没抢到分布式锁的服务会启动一个消费线程。 同步线程分批同步数据，没数据需要同步后会释放分布式锁。保证同时只有一个线程在同步数据。

每次启动服务是Redis内部会有老数据，同步数据时会重复需要去重，根据 模块名+监控id+告警的时间戳 去重

需要重新拉取MySQL离线表数据，Redis会从消息队列中拉取最新的告警数据。

冷启动，启动消费线程和同步线程双线程，同步需要消耗一段时间，这时MySQL里面一直增加数据，消息队列也来数据了，怎么保证数据不重复？

会出现数据重复。根据 模块名+监控id+告警的时间戳 去重。

  1. https://www.notion.so/Redis-314254b59a8380878cade73c89631ef7

当前存在一个告警消息队列，承载着告警事件的实时流转。有一个服务持续消费该队列，并将消息写入数据库的表中进行持久化存储。约2000万条

需要开发一个新的告警分析服务，该服务需要：实时消费消息队列中的告警消息；判断每条告警是否在最近7天内出现过；如果出现过，分别是哪些天出现过；将判断结果写入新的表中供后续业务使用

备注：线程1（消费线程）在冷启动期间，由于redis中没有最近7天的历史告警信息，可能会有短暂的窗口期，只能当作是首次出现告警。

频繁告警治理

  1. https://www.notion.so/SOA-31a254b59a83807ba50ceabcca6910f1
  2. https://www.notion.so/315254b59a83805f8bf3d32985c09ccc

任务幂等键格式 过滤规则 联合索引 查询时按模块名分批（每批 500 个模块），每批内先查 count 再按 1000 条分页查明细。 模调告警指标类型 如果开启了算法告警，检查算法特征与告警类型是否匹配 如果开启了阈值告警，检查阈值是否偏低（≤ 10）

变更审计

完善变更审计机制，覆盖变更流程、人员及单据维度，对变更步骤执行情况（是否灰度发布、是否正常结单）、变更人员资质（是否通过考试）及单据完整性（是否包含关联任务计划链接）进行校验，提升变更规范性与风险可控性，辅助告警与变更关联分析。

告警分析

  1. https://www.notion.so/02-BFS-318254b59a8381468cd3dbbdb30eb551
  2. https://www.notion.so/01-mmpayalarmanalysis-318254b59a83812e9bf5cf56e7a1ae08
  3. https://www.notion.so/313254b59a8380b580f8d26c4ca15591

在同一条调用链上，如果上下游有影响就可以用这个根因分析

变更阻断

  1. https://www.notion.so/314254b59a8380d7a8f1ca0cb41bb29e
  2. https://www.notion.so/315254b59a83801d8f96e14f5ff88387
  3. https://www.notion.so/314254b59a8380a68b18e9583b8919c6
  4. https://www.notion.so/314254b59a8380d1819eefcd1255ff85
  5. https://www.notion.so/01-mmpayxdcchangeanalysis-318254b59a83815b951aeada7a6ecdf2
  6. https://www.notion.so/03-318254b59a83812fb263e8cbc6d6b0ab

减少误告-时间序列异常检测方法

目前告警大多是按 阈值 来设置的，缺点是无法适应业务的动态变化，容易产生误告（毛刺、周期趋势不变但用量放大【都正常需去除此类误告】）。时间序列异常检测方法可以根据历史数据自动学习正常的模式，能够更准确地识别异常情况，从而减少误告。

注意需要标记的样本过大不能人工标记，可以使用 大模型标记+人工抽查 的方式。 人工抽查：直接给大模型监控数据点值让他标记准确率60%-70%，给大模型监控数据点值转化出的图片让他标记准确率80%-90%

2025.11–2026.03实习相关整理-时间序列异常检测完整方案指南

难点与问题解决

https://www.notion.so/1-315254b59a8380cf952cf4c22a20d0b7

第6

https://www.notion.so/2-317254b59a838083abdae9701288b740

第2

https://www.notion.so/3-317254b59a838081afe4c35b54f507a8

第1、3

https://www.notion.so/4-317254b59a8380fc95eee4449c5e4be6

第2、4、5、6

https://www.notion.so/5-317254b59a8380c38bcef3621e30af4e

第3、4、6、7

https://www.notion.so/6-317254b59a83803ca1a9ee44bae9de7e

第3、4