文章目录
-
-
- [1. 为什么要设计新的数据库Schema？](#1. 为什么要设计新的数据库Schema？)
- [2. 怎么保证新的Schema不污染老的，及项目上线注意事项？](#2. 怎么保证新的Schema不污染老的，及项目上线注意事项？)
-
- [（1）避免新Schema污染老Schema的核心原则：**隔离性 + 兼容性**](#（1）避免新Schema污染老Schema的核心原则：隔离性 + 兼容性)
- [（2）上线注意事项：**灰度发布 + 回滚预案**](#（2）上线注意事项：灰度发布 + 回滚预案)
- [3. 怎么保证backfill（数据回填）时不丢数据？](#3. 怎么保证backfill（数据回填）时不丢数据？)
- [4. Cache的一致性怎么保证（写回/写穿）？](#4. Cache的一致性怎么保证（写回/写穿）？)
- [5. 有没有监控来保证Cache的数据没有问题？](#5. 有没有监控来保证Cache的数据没有问题？)
-
1. 为什么要设计新的数据库Schema？
数据库Schema变更（新增/修改表结构）的核心驱动力是业务需求迭代，具体场景包括：
- 功能新增 ：比如用户系统需要新增"会员等级"字段，需在
user表中添加member_level列； - 性能优化 ：原表字段冗余导致查询缓慢，需拆分表（如将
order表的物流信息拆到order_logistics表）； - 数据规范调整 ：原字段类型不符合业务发展（如
phone字段从varchar(10)扩容到varchar(20)支持国际号码）； - 兼容性适配 ：支持新业务模式（如从单币种支付升级为多币种，需新增
currency_type字段）。
本质是让数据存储结构与业务逻辑匹配，避免因Schema僵化导致业务迭代受阻或性能瓶颈。
2. 怎么保证新的Schema不污染老的，及项目上线注意事项？
（1）避免新Schema污染老Schema的核心原则：隔离性 + 兼容性
- 物理隔离 ：新业务逻辑优先使用新表（如
user_v2），而非直接修改老表；若需扩展老表，通过新增字段实现（禁止删除/修改老字段，避免影响依赖老字段的代码）。 - 逻辑隔离 ：用"字段标识"区分新老数据（如
schema_version字段，1代表老结构，2代表新结构），代码层面按版本处理逻辑。 - 兼容性设计 ：新Schema需兼容老数据（如新增字段设置默认值，避免
NULL导致老代码报错）。
（2）上线注意事项：灰度发布 + 回滚预案
- 分阶段上线 ：
- 先发布"仅读取新Schema"的代码（不写入），验证新结构可用性；
- 再发布"读写新Schema"的代码，同时保留老Schema的读写能力（双写）；
- 待新数据稳定后，逐步下线老Schema的依赖。
- 禁止大事务变更 ：如
ALTER TABLE加字段时，用"Online DDL"工具（如pt-online-schema-change）避免锁表，尤其在核心表（如订单表）上。 - 回滚预案：提前准备回滚SQL（如删除新增字段、恢复老表结构），上线失败时10分钟内可回滚。
- 监控校验：上线后监控新表的读写QPS、错误率，对比老表数据确认一致性。
3. 怎么保证backfill（数据回填）时不丢数据？
数据回填（将老数据同步到新Schema）需保证完整性、幂等性、可追溯性，关键措施：
- 全量扫描 + 增量同步 ：
- 全量：按主键范围分批扫描老表（如
id BETWEEN 1 AND 10000），避免一次性扫描导致内存溢出； - 增量：记录全量同步的"时间戳"，之后通过binlog监听老表变更，实时同步到新表（避免全量期间的新数据丢失）。
- 全量：按主键范围分批扫描老表（如
- 幂等性处理 ：回填逻辑必须支持重复执行（如用
INSERT IGNORE或ON DUPLICATE KEY UPDATE），防止因重试导致数据重复。 - 校验机制 ：
- 数量校验：回填后对比新表与老表的记录数（允许少量延迟，需在阈值内）；
- 抽样校验：随机抽取1%的记录，对比新老表字段值是否一致；
- 校验失败时，自动记录异常ID到错误表，人工介入修复。
- 限流与监控：回填时限制QPS（如每秒1000条），避免压垮数据库；监控回填进度、失败率，设置告警（如失败率>0.1%触发告警）。
4. Cache的一致性怎么保证（写回/写穿）？
缓存与数据库的一致性需根据业务场景选择策略，核心是避免"缓存脏数据"（缓存与数据库数据不一致）：
（1）写穿（Write-Through）：同步更新缓存
- 流程：更新数据库时，同步更新缓存（若缓存不存在则插入，存在则覆盖）。
- 优点：缓存与数据库实时一致，适用于读多写少、一致性要求高的场景（如用户余额）。
- 缺点：写操作耗时增加（需同时更新DB和Cache），可能因Cache故障阻塞DB更新。
（2）写回（Write-Back）：异步更新缓存
- 流程：更新数据库后，不立即更新缓存，而是标记缓存失效（删除缓存），下次读请求时从DB加载最新数据并更新缓存。
- 优点：写操作性能高（仅需更新DB），适用于写频繁、一致性要求不严格的场景（如商品浏览量）。
- 缺点：删除缓存后、下次读之前存在"缓存空窗期"，可能导致短暂的DB压力上升。
（3）关键优化：避免缓存不一致的细节
- 先更新DB，再删除缓存（而非先删缓存再更DB，避免并发场景下的脏数据）；
- 缓存设置合理的TTL（过期时间），即使出现脏数据，也能在TTL后自动失效；
- 对核心业务（如支付），用"双删+重试"机制：更新DB后删缓存，延迟1秒再删一次（避免删除缓存时DB事务未提交导致的不一致）。
5. 有没有监控来保证Cache的数据没有问题？
需通过多维度监控验证缓存数据的准确性、可用性和性能，关键监控项：
（1）数据一致性监控
- 缓存命中率：若命中率骤降（如从90%降到50%），可能是缓存失效策略异常或脏数据导致；
- 缓存与DB对比校验：定时抽样（如每小时）对比缓存与DB的关键字段（如用户余额、商品库存），记录不一致率（阈值通常<0.1%）；
- 缓存空值监控 ：若缓存中大量存在
NULL值，可能是查询不存在的key导致，需优化缓存穿透防护。
（2）缓存服务可用性监控
- 缓存节点状态：监控Redis集群的主从切换、节点存活数（如集群应有3主3从，若主节点<2则告警）；
- 响应时间：缓存读写响应时间（P99应<10ms），超时可能是网络或内存碎片问题；
- 内存使用率：若接近maxmemory阈值（如>90%），需警惕缓存淘汰策略导致的关键数据被删除。
（3）异常行为监控
- 缓存穿透：监控"不存在的key"的查询频率，若某类key高频命中不存在（如恶意攻击），需用布隆过滤器拦截；
- 缓存雪崩：监控某一时刻大量key同时失效的情况（如QPS突降后骤升），需通过TTL加随机偏移量避免；
- 大key监控：缓存中单个key体积过大（如>10MB）会导致读写延迟，需拆分或压缩。
（4）工具实现
- 用Prometheus+Grafana采集缓存指标（如Redis的
redis_exporter）； - 自定义监控脚本（如Python脚本定时校验缓存与DB一致性），通过AlertManager发送告警到钉钉/邮件。