Appearance
03 - RDS 数据库与缓存
本章目标：数据库是面试必考且最能区分"背概念"与"干过活"的领域。要求讲清：RDS MySQL 产品系列与主备高可用、只读实例与读写分离、备份恢复、参数模板/慢日志、RDS 与自建的取舍、PolarDB 概念、Redis/Tair 架构选型、DTS 迁移通道；对标我移动云真实配套：MySQL 主备高可用 8C16G/300G、Redis 主备双机热备、RocketMQ 两节点、Nacos。水位：架构与选型【必背】，参数细节【理解】，内核调优【了解】。
3.1 RDS 是什么——产品系列【必背】
知识点：RDS（Relational Database Service）是全托管关系型数据库，支持 MySQL、SQL Server、PostgreSQL、MariaDB。核心是三个系列：
| 系列 | 架构 | 备库可读？ | 适用 |
|---|---|---|---|
| 基础系列 | 单节点，无备库 | — | 测试/非核心 |
| 高可用系列 | 一主一备，自动故障切换 | 备库不可读 | 生产默认选择 |
| 集群系列 | 一主多备/可读节点 | 备节点可读 | 更高可用与读扩展 |
- 生产铁律：高可用系列起步，基础系列不进生产。
- 概念辨析：备库（高可用冗余）≠ 只读实例（读扩展）——备库不可读、只为故障切换兜底；只读实例是独立计费的读流量分摊节点。
标准回答（面试官问"讲讲 RDS 的高可用架构"）：
RDS 是全托管的关系型数据库服务，生产场景我默认选高可用系列：一主一备架构，主备之间做实时同步，主库故障时平台自动把备库提升为主，通常秒级到分钟级完成切换，应用只需要用连接地址重连，不需要人工介入；备库不对外提供读服务，它存在的唯一意义就是随时能顶上——这是很多人容易和只读实例混淆的点，只读实例是另外一种东西，专门分摊读流量，独立计费，可以挂多个。我在移动云生产环境用的就是同构的主备高可用形态：8 核 16G、300G 存储的 MySQL 实例承载业务库，平台托管主备和自动切换，我的运维动作集中在备份策略核对、慢日志巡检和水位监控上。我的观点是：托管数据库的意义不只是省安装，而是把"切换可靠性、备份完整性、监控告警"这些平时验证不到的能力工程化了——手工主从的切换演练和脑裂防护，绝大多数团队其实做不过云厂商。
追问 1：主备切换会丢数据吗？
取决于同步方式，这是 MySQL 复制的通识问题。异步复制下主库提交即返回，事务还没传到备库就宕机会丢最近几笔；半同步复制要求至少一个备库确认收到 binlog 才算提交成功，把丢失窗口压到极小。云上托管 RDS 在高可用系列里用的是强同步类机制来保证切换不丢数据，代价是主库写入延迟受备库响应影响。我的运维习惯是不空谈机制，而是看指标：盯主备复制延迟告警，延迟大的时段要排查大事务和备库压力；另外重要业务做切换演练，在维护窗口主动触发一次主备切换验证 RTO 和数据完整性，切换能力只有演练过才算真的有。
追问 2：什么时候选集群系列？
两个信号：一是读流量大，主库扛不住写但读可以水平拆——集群系列备节点可读，直接扩读能力；二是对可用性要求到"一主一备还不够"的等级。但多数中小业务高可用系列加只读实例的组合已经够用。我的判断逻辑是先看读写比和容量水位，不要一上来就上最高配——我在移动云的 MySQL 8C16G/300G 主备形态跑了整个业务周期水位都很健康，说明选型匹配；如果当时盲目选集群系列就是成本浪费。架构升级跟着数据说话。
3.2 只读实例与读写分离【理解】
知识点：
- 只读实例：基于主实例的 binlog 实时同步的独立只读节点，独立规格独立计费，可挂多个，用于分摊读流量（报表、复杂查询、大搜索）。
- 读写分离接入：阿里云提供**数据库代理（Proxy）**做统一地址，写走主库、读按权重分发到只读实例；不用代理则应用侧自行路由（ShardingSphere 等中间件）。
- 关键坑：主从延迟——写完立即读的场景读到旧数据；方案：关键读强制走主库（Hint 或代理路由策略）。
- 基础系列不能直接加只读，需先升级高可用系列。
- 移动云对标：我项目读流量单主库扛得住，未上只读实例——这个"为什么不上"的决策也能讲。
标准回答（面试官问"只读实例和读写分离你怎么用"）：
只读实例是挂在主库后面、通过 binlog 实时同步的独立只读节点，规格和计费都是独立的，用途是把报表、复杂查询这类重读流量从主库剥走；接入层用云数据库代理做统一地址，写自动走主库、读按权重分到只读实例，应用无改造。我要主动讲两个生产细节：一是主从延迟是读写分离绕不开的坑，写完立刻读的业务会读到旧数据，我的做法是在代理路由里把这类关键读强制路由回主库，或者应用侧用 Hint 指定；二是只读实例不是白送的，它独立计费，读流量单主库扛得住时加它就是浪费。我在移动云的 MySQL 主备高可用实例就没有上只读——当时读流量水位长期不高，单主足够，架构按需演进；如果读水位持续 70% 以上，第一步就是加只读实例分摊，这个决策路径我是清楚的。另外有个前置关系：基础系列不能直接加只读，要先升高可用系列，所以生产从第一天就该选高可用。
追问：怎么监控主从延迟？
云上托管数据库直接看平台指标——RDS 的复制延迟监控项配阈值告警，我建议 5 秒级告警起步；自建就命令行看 Seconds_Behind_Master 配上脚本采集。发现延迟大按三步排查：先看是否有大事务或批量 DML 造成 binlog 堆积，再看只读实例自身规格是否打满，最后看是否网络抖动。我们移动云项目里复制延迟纳入了监控大盘，作为数据库健康度的核心指标之一，因为它既是读写分离正确性的前提，也是主备切换 RTO 的先行指标——延迟小切换才快。
3.3 备份与恢复【必背】
知识点：
- RDS 自动备份：全量备份（物理/逻辑快照）+ 增量日志（binlog），保留期可设（默认 7 天，生产建议 7-30 天）。
- 恢复能力：任意时间点恢复 PITR——全量备份回放 binlog 到指定秒；克隆实例恢复（不动生产）。
- 最佳实践：保留期按合规要求定；重大变更前手动备份；恢复演练纳入季巡检（没演练过的备份等于没有备份）。
- 移动云对标：云数据库 MySQL 托管自动备份，我在项目里核对备份策略、验证备份文件存在性，并做过恢复演练记录。
标准回答（面试官问"云数据库的备份恢复你怎么做"）：
托管数据库的备份体系是全量加增量两层：RDS 自动做全量备份，同时持续归档 binlog 增量日志，两者组合能实现任意时间点恢复——比如数据误删了，可以恢复到删除前一秒，方式是建一个临时克隆实例把数据恢复出来，确认后再导回生产，全程不碰生产库。我的运维动作有三件：一是按合规和业务要求定保留期，生产至少七到三十天，不要用默认值糊弄；二是重大变更前手动触发一次备份，给回滚留锚点；三是做恢复演练——我坚持一个观点：没验证过的备份等于没有备份，备份文件是否存在和备份能否恢复是两回事。我在移动云项目里就把备份核对和恢复演练写进了运维 SOP，演练时记录恢复耗时作为 RTO 的实测值，而不是拍脑袋写个数字在应急预案里。这套纪律在阿里云 RDS 上同样适用，机制同构。
追问：误删库了怎么办，说下处置流程？
第一步止损：立即停止对数据库的写入，能停应用先停，防止错误继续扩散；第二步确认恢复点：从审计、binlog 里定位误操作的确切时间，决定恢复到哪个时间点；第三步克隆恢复：用 PITR 建临时实例恢复到该时间点，验证数据完整性；第四步比对回导：只把误删的数据差异导回生产，避免整库回滚覆盖掉误删之后产生的正常业务数据——这一步是最容易出二次事故的，我会导出差异 SQL 走变更流程执行；第五步复盘：补权限最小化、危险语句拦截、操作二次确认等防复发措施。我项目里虽然没出过误删生产库，但恢复演练是按这套流程走的，演练记录在案。
3.4 参数模板与慢日志【理解】
知识点：
- 参数模板：把一组数据库参数（连接数、缓冲池、超时等）固化为模板，批量应用到实例，新实例一键套用，保证环境一致性——等价于配置管理的数据库版。
- 慢日志：记录超过阈值的 SQL；配合 explain 分析执行计划；云上还有 DAS 自动诊断建议索引。
- 常用关注参数【理解】：max_connections、innodb_buffer_pool_size、慢查询阈值 long_query_time。
- 移动云对标：云数据库同样有参数模板与慢日志，项目里慢 SQL 巡检纳入周任务，配合开发优化索引。
标准回答（面试官问"数据库性能问题你怎么排查"）：
我的路径是先定位慢在哪，再决定动参数还是动 SQL。第一步看监控：主机层 CPU、内存、磁盘 IO 水位，数据库层连接数、QPS、慢查询数量，先判断是资源瓶颈还是 SQL 问题；第二步拉慢日志：把超过阈值的 SQL 按执行次数和耗时排序，找 Top 慢查询；第三步 explain 分析执行计划：是不是全表扫描、索引没走对、返回行数异常；第四步分诊：SQL 问题归还开发加索引或改写，参数问题走参数模板调整——比如连接数打满可能是应用连接池没配好也可能是 max_connections 偏小。我在移动云项目里把慢 SQL 巡检做成了周任务，慢日志 top 十和开发一起过，改了索引之后回看慢查询曲线验证效果。参数层面我用云平台的参数模板固化基线配置，新实例直接套模板，避免每台手工调一遍造成配置漂移。阿里云 RDS 参数模板加慢日志加 DAS 自动诊断，这套能力同构，DAS 还能给索引建议。
3.5 RDS vs 自建 MySQL【必背】
知识点：
| 维度 | RDS/云数据库 | 自建 MySQL |
|---|---|---|
| 高可用 | 主备托管自动切换 | 自己搭主从/自己写切换脚本 |
| 备份 | 自动全量+binlog、PITR | 自己搭 xtrabackup/binlog 体系 |
| 监控告警 | 平台内置 | 自建 Prometheus+Exporter |
| 安全 | 内置审计、加密、白名单 | 自己配 |
| 成本 | 实例费高 | 机器费低+人力成本高 |
| 自主性 | 内核参数受限 | 完全掌控（特殊插件/内核） |
结论口径：中小团队/标准业务上托管；需要深度定制内核、极端成本敏感、有强合规的数据自主要求才自建。
标准回答（面试官问"RDS 和自建 MySQL 怎么选"）：
我的判断框架是算三笔账。第一笔可靠性账：RDS 把主备切换、备份恢复、监控告警这些"平时看不见、出事才致命"的能力工程化了，自建团队要么投入人力把这套做扎实，要么长期裸奔——大多数团队做不到云厂商的切换可靠性水平。第二笔成本账：RDS 实例费明显高于同配置机器费，但自建的隐性成本是人力——备份、监控、切换演练、打补丁全是活，中型业务往上摊，托管反而划算。第三笔自主性账：需要特殊内核、特殊插件、或合规要求数据完全自主时，自建有不可替代性。我的实践两边都有：移动云生产用的是云数据库 MySQL 主备高可用 8C16G/300G，看重的就是托管的主备切换和自动备份；同时我也有自己维护 MySQL 环境的经验，主从搭建、备份脚本、慢查询优化都做过。所以我的结论是：标准业务无脑托管，把人力花在业务优化上；自建留给有特殊理由的场景，并且要为可靠性投入补课。
追问：你们为什么用云数据库而不是 ECS 上自建？
三个现实原因。一是项目要生产级可靠但运维人力有限，托管主备加自动备份把数据库的保命能力直接买齐了，我自己搭主从再加切换脚本，开发和验证周期至少一周还未必可靠；二是等保和审计要求，云数据库自带备份留痕、白名单、审计能力，检查时直接出示；三是版本升级和补丁由平台维护，减少停机窗口。代价是实例成本高一些、内核参数自由度低，但这两点在项目约束下完全可接受。这个选型我在方案文档里写过论证，不是默认跟着平台走，而是比较过自建方案的工期和风险后做的决定。
3.6 PolarDB 概念【理解】
知识点：
- PolarDB：阿里云自研云原生数据库，核心架构创新是计算与存储分离——多个计算节点（一写多读）共享同一份分布式存储，存储层自动多副本。
- 优势：100% 兼容 MySQL、读节点分钟级扩展、存储自动弹性、备份秒级（存储层快照）；主打 HTAP 场景。
- 与 RDS 关系：RDS 是传统主备架构的托管化；PolarDB 是下一代存算分离架构，单机 MySQL 的业务几乎无改造迁移。
- 一句话记忆："RDS 是把 MySQL 搬上云，PolarDB 是按云的特征重新设计的 MySQL"。
- 移动云对标：移动云有自研/合作云数据库产品线，我用的是传统主备形态——PolarDB 属于概念层学习，如实标注。
标准回答（面试官问"了解 PolarDB 吗，和 RDS 什么区别"）：
PolarDB 是阿里云自研的云原生数据库，和 RDS 的本质区别在架构：RDS 是把传统 MySQL 主备架构托管起来，计算存储还是绑在主机上的；PolarDB 是计算存储分离——多个计算节点通过共享分布式存储组成集群，一个主节点负责写、多个读节点直接读共享存储，加读节点不用搬数据所以分钟级扩展，存储层自动多副本，备份靠存储快照能做到秒级，而且 100% 兼容 MySQL，单机业务几乎不用改就能迁。它的适用场景是读扩展压力大、存储快速增长、想要 HTAP 能力的业务。我如实说明水位：PolarDB 我是产品概念和架构层的学习，没有生产实操——我移动云生产用的是传统主备高可用的云数据库，业务规模下这个形态是够用的；但存算分离的思想我是真理解的，因为我理解 RDS 主备和只读实例的扩展瓶颈在哪，也就理解 PolarDB 为什么要这么设计——它是冲着这些瓶颈去的。
3.7 Redis / Tair 架构选型【必背——真实用例】
知识点：
- 阿里云 Redis 全托管产品现称云数据库 Tair（兼容 Redis），分社区兼容版与 Tair 自研版（增强数据结构、持久化、性能）。
- 三种架构：
| 架构 | 组成 | 容量/性能 | 适用 |
|---|---|---|---|
| 标准版（主备） | 主备双节点 | 单分片容量，主故障自动热备切换 | 中小规模缓存，生产默认起点 |
| 集群版 | 多分片，每分片主备 | 容量/吞吐水平扩展 | 大容量、高并发 |
| 读写分离版 | 主+多副本 | 读扩展 | 读多写少 |
- 单线程本质：Redis 单命令处理，大 key 和热 key 是两大杀手；集群版解决容量与吞吐，不改变单 key 处理模型。
- 选型口径：先标准主备，容量水位或 QPS 触顶再升集群——和 MySQL 一样的按需演进。
- 移动云对标——我的真实用例：云数据库 Redis 主备双机热备，承载缓存与会话，主故障平台自动切换，业务用连接地址无感；我负责水位监控与过期策略巡检。
标准回答（面试官问"Redis 云上怎么选架构"）：
阿里云的全托管 Redis 现在叫云数据库 Tair 兼容 Redis，架构三选：标准版是主备双机，主库故障备库自动热备切换，单分片容量；集群版是多个分片、每个分片带自己的主备，容量和吞吐水平扩展，能突破单分片上限；读写分离版给读多写少的场景加副本。我的选型纪律是标准主备起步、触顶再升级：中小业务的缓存与会话场景，主备热备已经是生产级可用性，直接上集群是花冤枉钱。我在移动云生产用的就是云数据库 Redis 主备双机热备，承载业务缓存和会话状态，主故障时平台自动切换，业务通过连接地址重连无感，我的日常运维是水位监控——内存使用率、连接数、命中率——加过期策略巡检，防止大对象把内存打爆。要补一句演进意识：如果内存水位长期 70% 以上或 QPS 触顶，升级路径是清晰的，加副本解决读、升集群版解决容量，架构升级在托管平台上是变配动作，不需要数据搬家重建。阿里云 Tair 上这套演进同样成立。
追问 1：Redis 生产上你关注哪些指标？
我盯四类。内存：used_memory 和使用率水位，加过期淘汰策略是否匹配——打满会触发淘汰甚至写失败；连接数：突增往往意味着连接池配置不当或异常流量；命中率：命中率下跌通常是缓存设计问题或大促预热不足；主备状态和延迟：热备切换的前提是备库数据跟得上。另外两个主动巡检项：大 key 扫描——单个 key 太大会拖慢单线程处理，热 key 识别——单 key 过热要本地缓存兜底。移动云项目里这些指标进了监控大盘，Redis 和 MySQL 一样是重点保障对象。
追问 2：缓存和数据库的一致性怎么保证？
常用方案是缓存旁路加过期兜底：读请求先查缓存、未命中查库回填；写请求先更新数据库再删除缓存，让下次读触发重建。为什么是删缓存不是改缓存——并发写时改缓存容易出现脏数据，删除语义幂等。兜底是给 key 设过期时间，即使同步出问题也能在过期后自愈。强一致要求的场景就用延迟双删或订阅 binlog 异步删除，但多数业务允许秒级不一致，不用过度设计。我项目里会话数据就是这样处理的，过期时间与业务容忍度对齐，线上没出过一致性问题。
3.8 消息队列 RocketMQ 与 Nacos——中间件三件套对标【必背】
知识点：
- 阿里云对应产品：云消息队列 RocketMQ 版（Apache RocketMQ 商业托管）、MSE 微服务引擎（Nacos/ZooKeeper 注册配置中心托管，SLA 99.99%）。
- 概念层【必背】：RocketMQ 核心概念 NameServer/Broker/Topic/生产消费组；Nacos 双职责——服务注册发现 + 配置中心。
- 我的真实用例【必背】：移动云生产环境 RocketMQ 两节点集群（自部署，承载业务异步消息与削峰）+ Nacos 注册配置中心（微服务注册与配置管理）。
- 自部署 vs 托管的取舍逻辑：与"RDS vs 自建 MySQL"同一框架。
标准回答（面试官问"中间件这块你有实际经验吗"）：
有，而且是生产级的。移动云项目里我部署维护了两套：RocketMQ 是两节点集群，承载业务的异步消息——订单类操作通过消息解耦，峰值流量用队列削峰；Nacos 是注册配置中心，微服务启动注册地址、运行时监听配置变更。这两套是我亲手部署、扩容和排障的：RocketMQ 关注过磁盘水位和消费堆积告警，Nacos 做过集群部署和数据备份策略。阿里云这边，RocketMQ 对应它的云消息队列 RocketMQ 版，MSE 微服务引擎对应托管 Nacos——托管版把高可用、监控告警、版本升级全平台化了，SLA 能到 99.99%。我的取舍逻辑和数据库一样：自部署可控性强、成本低，但运维责任全在自己；托管版省心但要花钱。我两边的概念都是通的，自部署的深度运维经验我有，托管产品的选型逻辑我也清楚，这就是我说的双云对标的优势——中间件不依附于某一家云。
追问：RocketMQ 为什么部署两节点？高可用够吗？
两节点是当时项目在成本和可用性之间的平衡点：消息可靠性靠主从复制保证，一台故障另一台有完整数据，消费不中断；但两节点意味着写能力没有多副本冗余余量，运维上要更勤地盯磁盘和复制状态。如果业务对消息可用性要求更高，标准做法是至少两主两从或多主多从，把写入压力和故障域都摊开。我同时在 RocketMQ 之外做了消息可靠性设计：生产端发送确认加失败重试，消费端幂等处理防重复消费——中间件的高可用不只是节点数，端到端的投递语义同样重要。这套理解在托管版上同样适用，托管的 RocketMQ 版默认就是多可用区部署，可靠性由平台保证，我只需要关注消费端监控。
3.9 DTS 数据迁移与 DAS【理解/了解】
知识点：
- DTS（数据传输服务）：迁移/同步/订阅通道产品。支持自建库（IDC/ECS/其他云）→ 阿里云 RDS 的全量+增量迁移，迁移期间持续同步增量数据，业务短暂停写后完成切换，停机窗口极小。
- 三种任务类型【理解】：迁移（一次性搬家）、同步（长期实时，如异地容灾）、订阅（把 binlog 当消息流用）。
- 迁移流程骨架：源端评估 → 目标实例就绪 → 创建 DTS 任务（结构+全量+增量）→ 校验数据 → 低峰切流量 → 释放旧库。
- DAS（数据库自治服务）【了解一句话】：数据库智能巡检与诊断平台，自动发现慢 SQL、给索引建议，RDS 配套使用。
- 移动云对标：DTS 概念对标各类"数据迁移工具"，我项目里没做跨云迁移，但数据库迁移流程（全量+增量+校验+切换）是通用工程方法。
标准回答（面试官问"业务数据库要迁上云，你怎么做"）：
我的标准打法是用 DTS 这类迁移通道做全量加增量的无缝迁移。流程五步：第一步评估，梳理库表规模、字符集版本兼容性、业务停写容忍度，确认源库到目标云的网络链路；第二步准备目标实例，规格按源库水位加余量，参数模板对齐源端配置；第三步建 DTS 任务，它先做结构迁移和全量迁移，然后自动进入增量同步，把源库 binlog 持续追到目标库；第四步数据校验，用行数比对和抽样比对确认全量加增量一致；第五步切换，选业务低峰短暂停止写入，等增量追平，把应用连接串切到新实例，观察正常后释放旧库。整个过程业务停机窗口压缩到分钟级。我在移动云项目里虽然不是跨云迁移场景，但这套"全量加增量加校验再切换"的工程方法是通用的，我也理解 DTS 各任务类型的差别——迁移是一次性搬家，同步是长期实时复制比如做容灾，订阅是把 binlog 当消息流消费。真遇到迁移需求，我的知识是就位的。
3.10 RDS 安全与访问控制【理解】
知识点：
- 白名单：RDS 默认拒绝一切来源，仅白名单内 IP 可连；原则：只放行业务 ECS 所在 VPC 网段 + 运维跳板，绝不开 0.0.0.0/0。
- 连接串选择：内网地址（免费、低延迟、不经公网）vs 外网地址（按流量计费、有暴露面）——生产一律内网串；外网地址仅临时开启用完即关。
- 账号分级：高权限账号只给 DBA 管理动作；应用用普通账号按库授权；读写可用不同账号。
- 传输与存储：SSL 加密连接、透明加密 TDE（了解）。
- 移动云对标：同构的白名单/账号分级/内外网串，我项目全量落地且是等保检查项。
标准回答（面试官问"云数据库的安全你怎么配"）：
RDS 的安全配置我抓四件事。第一是白名单：RDS 默认拒绝一切来源，只有白名单里的 IP 才能连，我的原则是只放行业务 ECS 所在的 VPC 网段和运维跳板，绝不开 0.0.0.0/0——开了全通等于白名单形同虚设。第二是连接串选择：RDS 提供内网和外网两个地址，生产一律走内网串——内网免费、延迟低、流量不经公网；外网地址只在临时数据导出这类场景短暂开启，用完立即关。第三是账号分级：高权限账号只留给 DBA 的管理动作，应用连接用普通账号，按库授权、按需最小化，读写敏感操作还可以再拆账号——这直接呼应误删防护里的权限防线。第四是传输与存储安全：敏感业务开 SSL 连接，存储层有透明加密选项。我在移动云的 MySQL 主备实例上这套配置是全量落地的，等保检查时白名单和账号清单都是必查项。阿里云 RDS 的白名单、账号体系、内外网串完全同构，配置项名字都差不多。
追问：数据库连接数打满了怎么排查？
先看监控曲线确认形态：突增还是缓慢爬升。突增通常对应应用发布——连接池配置变化或新实例重复建连；缓慢爬升是连接泄漏——应用不释放连接。定位手段：云数据库控制台看会话列表，按来源 IP 聚合，锁定问题应用机；临时止血是 kill 空闲会话或临时调大 max_connections 撑住，根因修复一定在应用侧连接池参数——最大连接数、空闲超时、回收策略。容量公式我也备着：数据库 max_connections 要大于所有应用实例连接池上限之和再留余量，这个核对应该发生在上线前而不是故障后。
3.11 RocketMQ 与 Nacos 运维深入【理解——对标两节点/自部署】
知识点：
- RocketMQ 角色：NameServer（无状态路由注册中心）+ Broker（存储转发）+ Producer/Consumer。消息可靠性：生产端发送确认+失败重试、消费端幂等、死信队列兜底。
- 运维三盯：磁盘水位（消息存储大头）、消费堆积（消费者掉线/处理变慢）、主从复制状态。
- Nacos 双职责：服务注册发现（AP 倾向，保可用）+ 配置中心（走一致性协议，保一致）；配置变更有历史可审计。
- 对标：阿里云云消息队列 RocketMQ 版托管 NameServer/Broker；MSE 托管 Nacos 集群（SLA 99.99%）。
- 我真实配置：移动云 RocketMQ 两节点、Nacos 注册配置中心，全亲手部署运维。
标准回答（面试官问"消息队列和注册中心的运维你做什么"）：
RocketMQ 我在移动云部署的是两节点集群：NameServer 是无状态路由中心，Broker 承担存储转发。运维上我盯三件事：磁盘水位——消息存储是磁盘消耗大户，堆积加上保留策略会把盘写满，我配了水位告警和保留期清理；消费堆积——消费者掉线或处理变慢时堆积曲线上涨，要有告警和扩消费者预案；主从复制状态——同步延迟影响消息可靠性。消息可靠性两端我坚持做满：生产端发送确认加失败重试，消费端幂等处理防重复消费——这两端不做，中间件副本再多也白搭。Nacos 我部署的是注册配置中心形态，它有双重职责：服务注册发现偏向 AP 保可用，配置中心走一致性协议保一致，配置变更留历史可回滚可审计。对标阿里云：云消息队列 RocketMQ 版把 NameServer 和 Broker 全托管，MSE 把 Nacos 做成托管集群，SLA 99.99%。自部署省成本，但备份、监控、版本升级三件套要自己扛——我两边都算得清账，这是自部署运维经验给我的判断力。
追问：消息堆积了怎么处置？
先定位环节：看堆积曲线和消费者在线状态，区分"生产突增"还是"消费变慢"。消费者掉线就恢复实例；处理变慢看日志找传导源头——通常是下游依赖变慢，临时手段是加消费者实例扩并发，前提是消息分区允许并行；消息本身错误导致的反复重试要有死信队列兜底，人工介入。恢复后处理积压老消息：按优先级消费或批量补处理。我在移动云经历过一次发布期间的堆积尖峰，靠告警发现、扩并发压平，之后把"消费能力核对"加进了发布检查单。
3.12 RDS 引擎版本与实例管理【理解】
知识点：
- 版本选择：MySQL 新业务建议 8.0（性能、JSON、窗口函数等新特性），存量 5.7 升级要评估兼容性（认证插件、保留字、SQL 模式变化）。
- 小版本升级：平台支持窗口内升级，修复 bug 与安全漏洞，建议定期跟。
- 存储管理：云盘型实例支持自动空间扩容（水位触发），防"磁盘满导致库锁死"。
- 变配：规格升降级有瞬时闪断，走业务低峰变更窗口。
- 移动云对标：同构的版本/变配/存储管理；我项目固定版本+水位告警+低峰变更窗口。
标准回答（面试官问"数据库版本和实例变更你怎么管理"）：
版本上我的原则是新业务直接上新稳定版本——MySQL 8.0 的性能和新特性都值得，存量老版本升级要单独评估兼容性：认证插件变化、SQL 语法差异、字符集默认值这些点逐一核对，不能原地升。小版本升级我建议定期跟——平台窗口内升级修复 bug 和安全漏洞，代价小收益稳。实例管理三件事：第一，存储自动扩容能开就开——磁盘满是最不该发生的故障，水位触发自动扩容是廉价保险；第二，规格变配有瞬时闪断，必须走业务低峰变更窗口，提前公告；第三，版本和参数变更前做备份，变更后核对主备同步和慢查询。我在移动云的 MySQL 8C16G/300G 就是固定版本加水位告警加低峰变更窗口的管理模式，300G 存储按业务增长评估过，水位健康。版本管理的本质是"变更可控"——云托管把升级做成了按钮，但按钮按下去之前的影响评估还是运维的责任。
追问 1：5.7 升 8.0 有哪些典型坑？
四类高频：认证插件默认从 mysql_native_password 变成 caching_sha2_password，老客户端和驱动连不上，要升级驱动或显式兼容配置；保留字扩充——像 rank、groups 这类变成关键字，老 SQL 可能直接报错；SQL 模式和默认排序规则变化引起行为差异；GROUP BY 隐式排序被移除，依赖隐式排序的老查询结果顺序变化。我的方法：升级前用官方兼容性检查工具扫一遍，测试库全量回归后再动生产，升级窗口前备份兜底。
追问 2：存储自动扩容和手动扩容怎么选？
自动扩容适合持续增长的业务库——水位到阈值自动加，避免半夜磁盘告警人工介入，但要注意设置单次和总量上限防止误触发成本失控；手动扩容适合预算强管控的场景，配合 80% 水位告警留出手动操作时间。我的倾向：生产核心库自动扩容加上限，告警保留——自动扩容解决"来不及"，告警解决"该不该"，两个机制管两个问题。
3.13 实操模板
模板 A：数据库选型决策表
| 问题 | 判断 | 我的答案示例 |
|---|---|---|
| 是否生产核心库？ | 高可用系列起步，禁基础系列 | 移动云 MySQL 主备高可用 8C16G/300G |
| 读流量是否单主扛不住？ | 加只读实例+读写分离代理 | 水位健康未上，按需演进 |
| 备份保留多久？ | 生产 7-30 天+恢复演练 | 托管自动备份+演练记录 |
| Redis 规模？ | 标准主备起步，触顶升集群 | 主备双机热备（缓存+会话） |
| 中间件自建还是托管？ | 同 RDS vs 自建框架 | 移动云自部署 RocketMQ 两节点+Nacos |
| 迁移方式？ | DTS 全量+增量+校验+低峰切换 | 方法论通用 |
| 引擎版本策略？ | 新业务新稳定版，小版本定期跟 | 固定版本+兼容性评估先行 |
模板 B：数据库日常巡检清单（少而精）
- 水位：CPU/内存/存储使用率（阈值告警 70-80%）。
- MySQL：主备复制延迟、连接数、慢查询数趋势。
- Redis：内存水位、命中率、连接数、主备状态。
- 备份：最近一次备份成功时间、保留期内备份完整性。
- MQ：消费堆积、磁盘水位、复制状态。
- 配置：参数变更走模板与变更记录。
- 安全：白名单范围核对、账号最小权限复核、临时账号到期清理。
3.14 章末自测（一句话答案）
- RDS 高可用系列的备库能读吗？——不能，备库只做故障切换冗余；可读的是只读实例。
- 基础系列能加只读实例吗？——不能，要先升级高可用系列。
- 任意时间点恢复靠什么？——全量备份回放 binlog（PITR），克隆实例恢复不动生产。
- 主从延迟对读写分离的影响？——写后立读会读旧数据，关键读强制走主库。
- PolarDB 和 RDS 的本质区别？——RDS 是传统主备托管，PolarDB 是计算存储分离、一写多读、共享存储的云原生架构。
- 阿里云 Redis 全托管产品名？——云数据库 Tair（兼容 Redis），标准主备/集群/读写分离三种架构。
- Redis 生产四大监控指标？——内存水位、命中率、连接数、主备状态延迟。
- 我的移动云数据库配套一句话？——MySQL 主备高可用 8C16G/300G + Redis 主备双机热备 + RocketMQ 两节点 + Nacos。
- DTS 迁移不停机的原理？——全量迁移后持续增量同步 binlog，低峰停写追平再切连接。
- 什么情况才自建 MySQL？——深度内核定制、极端成本敏感、数据完全自主的强合规要求。
- "备库是保命的、只读是干活的"指什么？——高可用备库不可读只为切换，只读实例可读分摊读流量独立计费。
- 大表 DDL 的安全三件套？——在线改表工具（gh-ost/pt-osc）、低峰窗口加备份、盯主从延迟。
- "丢消息"九成的原因？——消费段位移提交过早，先提交后处理崩溃即丢；防线是先处理后提交加幂等。
- 消息丢失排查三段法？——生产段查发送确认、存储段查落盘复制、消费段查位移管理，九成在消费段。
- 托管数据库登不了主机，观测面靠什么？——平台指标（延迟/连接/慢查询/会话管理），需要底层证据走工单。
3.15 高频追问补充包（连环追问应对）
追问 A：只读实例可以写吗？普通备库和只读实例到底差在哪？
只读实例只读，写操作会被拒绝。三者一句话分清：高可用备库——不可读，只为切换兜底；只读实例——可读，为分摊读流量，独立计费；PolarDB 读节点——共享存储的读扩展。面试最容易混的是前两个，我用"备库是保命的、只读是干活的"来记。
追问 B：MySQL 大表加字段、加索引怎么做才安全？
核心风险是 DDL 长时间锁表。方案按版本：8.0 很多 DDL 支持 online DDL，INPLACE 执行仍有风险窗口；大表稳妥做法是 gh-ost/pt-osc 这类在线改表工具——影子表加增量同步加原子切换；云托管环境下我还会用低峰窗口加备份兜底双保险。流程上大表 DDL 是高危变更：先评估表大小和写入量、测试环境演练、生产低峰执行、盯主从延迟——DDL 会在备库重放，延迟大影响切换能力。
追问 C：Redis 托管版的持久化怎么理解？
托管平台替你管理 RDB 快照和 AOF 的策略与恢复，我关注三层：持久化配置是否匹配业务——纯缓存可接受较弱持久化，当存储用就要强配置；主从切换后数据完整性依赖同步机制；重建恢复时长要心里有数——大实例恢复慢，影响 RTO。我的移动云 Redis 是缓存加会话用途，秒级丢失可接受，这个容忍度是选架构的依据。
追问 D：什么信号出现该考虑分库分表？
三个信号：单实例容量接近平台上限或成本拐点——存储和 QPS 线性外推要打满；写入瓶颈明确在单主——读写分离救不了写；业务天然可拆——按租户、按业务线拆分边界清晰。我的态度是分库分表是伤筋动骨的重构，先用引擎升级、读写分离、归档冷数据三板斧顶，真到写瓶颈再拆，且优先按业务边界垂直拆，慎用水平分片的复杂性。
追问 E：数据库账号密码怎么轮换？
轮换流程四步：新密码生成——随机高熵；双账号过渡——新账号先建好，应用配置切换，避免"先删旧再建新"的断档；灰度切换——分批改应用连接配置，监控连接成功率；旧账号清理——确认无连接后禁用删除。配合机制：密码不进代码仓库，走配置中心或密管；轮换周期纳入安全计划。我在移动云项目按这套做过轮换，零断档。
追问 F：慢 SQL 优化过的一个例子？
我项目里一条订单查询 SQL，开发反馈偶发超时。慢日志显示执行 3 秒以上，explain 看到 WHERE 条件里对时间字段套了函数导致索引失效走了全表扫描——典型的"索引杀手"写法。处理：改写 SQL 把函数移到常量一侧，配合业务时间范围改用范围查询，走时间索引后降到毫秒级。经验两句：慢 SQL 八成是索引没走对，explain 是第一现场；改完要看慢日志曲线确认收敛，不是改完就算完。
追问 G：慢日志开启本身影响性能吗？
影响极小可忽略：只记录超过阈值的语句，阈值合理时增量 IO 相对数据库整体负载可以接受。生产建议长期开启——慢 SQL 是性能问题的第一现场，关掉它等于放弃数据库最重要的可观测性。配合定期清理控制日志量即可。我的立场：宁可多记不可不记，性能顾虑用阈值调节解决，不能因噎废食。
追问 H：数据库审计开了会拖慢业务吗？
主流审计实现在代理或旁路层异步落盘，对业务延迟影响在可接受范围；真正要管理的是审计范围和保留期——全量语句全量长期保留成本高，按敏感库表和操作类型过滤更务实。等保要求的审计能力必须开，这是合规底线；性能顾虑用范围和保留期控制解决。我在移动云的数据库审计就是按敏感操作优先的策略运营的，检查和性能两头都满足。
追问 I：怎么估算数据库规格够不够？
三个数：目标负载——从业务量推峰值 QPS/TPS；实例能力参照——同规格的压测数据或平台基准；余量折算——按目标负载除以实例能力，留 50% 左右余量。存储按当前量加年增长率外推再加备份空间。我移动云的 8C16G/300G 就是这么估出来的，上线后实测水位验证了估算的准确性。规格估算不求精确求"留有证据的余量"——数字可以不完美，但推导过程要在方案里写清楚，评审时才有讨论基础。
3.16 专题：数据库的日常巡检与周报【理解】
知识点（日巡检七项）：
- 可用性与主备状态。
- 复制延迟曲线（阈值告警兜底）。
- 连接数水位。
- 慢查询数量趋势。
- 最近备份完成度与文件校验。
- 存储空间水位与增长速率。
- 错误日志扫描。
周报三沉淀：慢 SQL Top 十及处置进度、当周变更记录（参数/账号/结构，全留痕）、备份与恢复演练状态。
标准回答（面试官问"数据库的日常运维你怎么做"）：
我有一张日巡检清单七项：可用性与主备状态、复制延迟曲线、连接数水位、慢查询趋势、最近备份完成度、存储空间水位与增长速率、错误日志扫描——每天过一遍五分钟以内，靠监控大盘加一条巡检脚本撑着，异常自动进待办。周报在巡检之上做三个沉淀：慢 SQL Top 十和处置进度——推动开发闭环；当周变更记录——参数、账号、结构变更全留痕，出问题能回溯；备份与恢复演练状态——备份体系健康度的直接证据。我移动云项目这套是真实执行的：周巡检发现过保留策略失效导致的磁盘慢性增长，周报把慢 SQL 的处置进度推给了开发团队，巡检和周报形成"发现—跟踪—闭环"的链条。巡检的意义不是看了而是闭环——每项异常有处置记录和验证结果，清单本身每季度修剪一次，根治的撤下、新风险补上。这套清单迁到阿里云 RDS 同样适用，数据源换成 RDS 控制台和 DAS 诊断报告即可。
追问：巡检发现主从延迟持续偏高怎么处理？
先按影响分级：延迟秒级且业务无读写分离依赖、切换能力未受威胁——排期查根因，常见是大事务、批量任务、备库规格不足；延迟已经影响读写分离正确性或主备切换 RTO——立即处理：限流拆分大事务、批量任务错峰、必要时升级备库规格。处理完把根因和对策写进巡检记录，同类问题复发说明缺结构性防线——比如批量任务就应该带"复制延迟感知"的限流设计，而不是靠人盯。巡检发现的问题是改进机制的输入，不只是当次故障的修复。
追问 J：云数据库能像 ECS 一样登录进去看吗？
不能直接登主机——托管数据库不开放底层系统访问，这是托管模式的天然边界，也是它安全性的来源。我能用的观测面是平台层：性能监控、慢日志、会话管理、参数修改、备份恢复全在控制台和 API 上。这改变了排障姿势：自建可以进系统 strace、看内核 IO，托管只能从数据库观测面推理。我的适应方式是把巡检清单完全建立在平台指标上——复制延迟、连接数、慢查询、临时表溢出这些平台指标足够定位八成问题；剩下两成需要底层证据的，提工单走厂商支持，这也是托管的服务边界之一。
追问 K：业务现在连的是主库还是备库，怎么确认？
用连接地址的解析确认：高可用连接地址的域名解析指向当前主库，主备切换后解析自动漂移，应用连接串不用改——这就是托管切换对应用透明的原理。管理侧看控制台的实例角色图交叉验证。我做切换演练时会专门记录"切换前后的解析变化和应用连接恢复时间"，把"地址不变、角色互换"的承诺变成实测数据。运维上要提醒应用的：重连机制要配好——切换瞬间连接会断，应用自动重连才真正无感。
追问 L：数据库账号要给第三方系统对接，怎么给？
四步最小化：独立账号——绝不复用现有应用账号；权限收敛到指定库的指定操作——只读就只读，要写只给目标表；白名单收来源——连接来源限定对方出口 IP；配额与监控——连接数限制加访问审计，异常流量可发现可阻断。对接结束账号即回收，不能"先这样以后再删"。我在项目里给第三方开过对接账号，台账里专门有一节记录"临时账号+到期时间"，到期即清理。
追问 M：Redis 的大 key 怎么发现和清理？
发现两条路：平台侧用大 key 分析能力自动扫描 top 名单；自扫用采样遍历或
--bigkeys类工具离线跑。清理讲手法：大字符串直接 del 可能阻塞单线程，用 unlink 异步删除；集合类大 key 拆批——scan 游标分批删除成员再删壳；业务侧从源头治理——结构设计避免单 key 承载海量成员，过期时间分散打散。我的节奏是大 key 扫描进周巡检，发现即评估业务影响后择机清理，绝不高峰期硬删。
追问 N：消费端反馈"消息丢了"，你怎么排查？
按"丢失发生在哪一段"拆三段查：生产段——发送是否确认成功，生产端日志和返回码核对，发送失败未重试是最常见"丢失"；存储段——Broker 落盘与复制状态，磁盘异常或未刷盘窗口；消费段——消费是否提交位移过早，消费者先提交后处理，崩溃时消息"已提交未处理"就表现为丢。九成"丢消息"是消费段位移管理问题。我的防线设计就是冲着这三段去的：生产端确认加重试、Broker 主从复制、消费端先处理后提交加幂等。这套排查思路在移动云 RocketMQ 上实际用过。
参考资料（链接采集时间 2026-10）
以下链接均于 2026 年 10 月通过搜索与抓取核实可用：
- 云数据库 RDS 文档总入口：https://help.aliyun.com/zh/rds
- RDS 产品选型（高可用系列一主一备/只读实例说明）：https://help.aliyun.com/zh/rds/product-overview/purchase-guide
- RDS MySQL 使用限制（主备复制架构说明）：https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/limits
- 创建 RDS MySQL 只读实例：https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/create-a-read-only-apsaradb-rds-for-mysql-instance
- 自建数据库迁移至 RDS MySQL 实例（DTS 迁移教程）：https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/step-3-migrate-a-user-created-database-to-an-rds-mysql-instance
- DTS 功能特性（迁移/同步/订阅）：https://help.aliyun.com/zh/dts/product-overview/product-function-node-dts
- 云数据库 Tair（兼容 Redis）标准架构（主备）组件介绍：https://help.aliyun.com/zh/redis/product-overview/standard-master-replica-instances
- 云数据库 Tair（兼容 Redis）集群架构及主备架构组件介绍：https://help.aliyun.com/zh/redis/product-overview/cluster-master-replica-instances
- Tair 变更实例配置（主备/集群架构切换）：https://help.aliyun.com/zh/redis/user-guide/change-the-configurations-of-an-instance
- 什么是 PolarDB MySQL 企业版：https://help.aliyun.com/zh/polardb/polardb-for-mysql
- 云数据库 Tair 产品页：https://www.aliyun.com/product/tair