关于工程实践的面试问题

文章目录

• • • 1. 为什么要设计新的数据库Schema？
    • 2. 怎么保证新的Schema不污染老的，及项目上线注意事项？
    • • （1）避免新Schema污染老Schema的核心原则：**隔离性 + 兼容性**
      • （2）上线注意事项：**灰度发布 + 回滚预案**
    • 3. 怎么保证backfill（数据回填）时不丢数据？
    • 4. Cache的一致性怎么保证（写回/写穿）？
    • • （1）写穿（Write-Through）：同步更新缓存
      • （2）写回（Write-Back）：异步更新缓存
      • （3）关键优化：避免缓存不一致的细节
    • 5. 有没有监控来保证Cache的数据没有问题？
    • • （1）数据一致性监控
      • （2）缓存服务可用性监控
      • （3）异常行为监控
      • （4）工具实现

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）上线注意事项：灰度发布 + 回滚预案

• 分阶段上线：
  1. 先发布“仅读取新Schema”的代码（不写入），验证新结构可用性；
  2. 再发布“读写新Schema”的代码，同时保留老Schema的读写能力（双写）；
  3. 待新数据稳定后，逐步下线老Schema的依赖。
• 禁止大事务变更：如ALTER TABLE加字段时，用“Online DDL”工具（如pt-online-schema-change）避免锁表，尤其在核心表（如订单表）上。
• 回滚预案：提前准备回滚SQL（如删除新增字段、恢复老表结构），上线失败时10分钟内可回滚。
• 监控校验：上线后监控新表的读写QPS、错误率，对比老表数据确认一致性。

3. 怎么保证backfill（数据回填）时不丢数据？

数据回填（将老数据同步到新Schema）需保证完整性、幂等性、可追溯性，关键措施：

• 全量扫描 + 增量同步：
  1. 全量：按主键范围分批扫描老表（如id BETWEEN 1 AND 10000），避免一次性扫描导致内存溢出；
  2. 增量：记录全量同步的“时间戳”，之后通过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发送告警到钉钉/邮件。