如何处理数据库模式（Schema）的变更和升级？

[muskanislam99]

在 WhatsApp 这样超大规模、高可用、持续演进的分布式系统中，数据库模式（Schema）的变更和升级是一个极其复杂且需要精心设计和执行的流程。目标是实现零停机时间、保证数据完整性、并确保新旧代码版本的兼容性。

WhatsApp 主要使用 NoSQL 数据库（如 Apache Cassandra 或 ScyllaDB），这些数据库相比传统关系型数据库在 Schema 演进方面具有一定的灵活性，但大规模的生产环境依然充满挑战。

WhatsApp 处理数据库模式变更和升级的关键策略
1. 优先考虑兼容性 (Prioritize Compatibility)
向后兼容（Backward Compatibility）： 最重要的原则。新的数据库 Schema 必须能被现有（旧版本）的应用程序代码正确读取和写入。例如，可以添加新列，但不能直接删除或修改现有列的类型。
向前兼容（Forward Compatibility）： 新部署的应用程序代码应该能够处理包含旧 Schema 数据的行。这意味着新代码在读取数据时，必须能优雅地处理那些新增加的列可能为空值的情况。
避免破坏性变更： 严格避免直接进行重命名列、修改列数据类型（非兼容性修改）、删除列等破坏性操作。如果必须进行这些操作，通常会采用更复杂的多阶段迁移策略。
2. 多阶段/滚动式部署 (Multi-Phase / Rolling Deployment)
Schema 变更通常不是一个单一的步骤，而是分解为多个阶段，与应用程序代码的部署紧密配合，实现零停机。

应用程序代码先行（读旧写旧/读新写旧）：
首先部署一个新版本的应用程序代码。这个版本能够兼容地处理旧 Schema 和新 Schema。
如果Schema是添加新列，新代码在读取时会考虑新列可能不存在（旧数据），在写入时可能仍然只写旧列，或者同时写入新旧列（但新列为空）。
Schema 变更部署：
在确保应用程序代码兼容后，逐步在数据库集群 印度 whatsapp 数据库 上应用 Schema 变更（例如 ALTER TABLE ADD COLUMN）。在 Cassandra 等分布式数据库中，Schema 变更通常是非阻塞的，可以滚动应用到集群的每个节点，最终在整个集群中一致。
数据迁移/填充（如果需要）：
如果新 Schema 的引入需要基于旧数据填充新列（例如，旧数据没有某个字段，新字段需要从旧字段衍生），会启动一个独立的、通常是异步的后台数据迁移任务。
这个任务会扫描旧数据，计算并填充新列的值。这可能是一个长时间运行的批处理或流式处理任务，在不影响在线服务的情况下逐步完成。
应用程序代码更新（读新写新/清理）：
一旦数据迁移完成并经过验证，部署最终的应用程序代码版本。这个版本将完全使用新 Schema，并可能停止写入旧列。
经过足够长的时间，确认所有旧数据都已处理，且所有旧代码版本都已淘汰后，旧的、不再使用的列才能被考虑移除（通常是一个非常谨慎和漫长的过程）。
3. 增量和原子性变更 (Incremental and Atomic Changes)
小步快跑： 优先进行小而增量的 Schema 变更，而不是一次性进行大量或复杂的修改。这降低了风险，便于回滚和调试。
数据库原子性： 数据库（如 Cassandra）在应用 ALTER TABLE 命令时，其内部会保证 Schema 变更本身的原子性。
4. 强大的版本控制与自动化 (Strong Version Control & Automation)
Schema 即代码： 将数据库 Schema 定义作为代码存储在版本控制系统（如 Git）中，与应用程序代码一起进行管理和版本控制。
自动化迁移工具： 使用专业的数据库迁移工具（如 Flyway、Liquibase）或自定义的自动化脚本来应用 Schema 变更。这些工具可以跟踪 Schema 版本，确保变更的幂等性（重复执行不会出错），并提供前滚和回滚机制。
5. 严格的测试流程 (Rigorous Testing Process)
开发与预生产环境： 所有 Schema 变更都必须在与生产环境尽可能相似的开发、测试和预生产环境中进行彻底的测试，包括：
功能测试： 确保新旧代码在 Schema 变更后都能正常工作。
性能测试： 评估 Schema 变更对读写性能的影响，确保没有引入回归。
兼容性测试： 验证与现有应用程序版本（可能还在运行旧 Schema 访问代码）的兼容性。
数据完整性测试： 确保数据迁移过程中没有数据丢失或损坏。
灰度发布/Canary 发布： 在生产环境中，Schema 变更和新应用代码的部署可能会采用灰度发布策略，逐步将变更推向小部分用户，监控其行为和性能，确认无误后再全面推广。
6. 影子读/双写 (Shadow Reads / Dual Writes)
对于特别复杂或关键的 Schema 演进，可能会使用**双写（Dual Writes）**策略：在过渡期间，新的应用程序代码同时写入旧 Schema 和新 Schema 的数据。
同时进行影子读（Shadow Reads）：从新旧 Schema 都读取数据并进行比较，验证数据一致性，但不影响生产服务的实际响应。
这提供了在不影响用户的前提下验证新 Schema 和数据迁移逻辑的强大手段。
通过上述一系列精心设计的策略，WhatsApp 能够在保持其服务的极高可用性的同时，持续不断地对其底层数据库 Schema 进行演进和升级。