面试题答案
一键面试触发调整的条件
- 数据量不均衡：定期监控各数据分片存储的数据量。当某一分片的数据量达到其他分片平均数据量的一定倍数（如2倍）时，触发数据分片调整。例如，通过在每个分片节点上设置数据量统计机制，定时将数据量信息汇总到一个监控中心，由监控中心进行比较判断。
- 负载不均衡：监测每个分片节点的负载情况，包括CPU使用率、内存使用率、网络I/O等指标。若某分片节点的负载持续高于其他节点平均负载的一定比例（如30%），且这种情况持续一段时间（如10分钟），考虑调整数据分片。可以使用系统自带的性能监测工具结合自定义脚本，实时获取各节点负载数据并进行分析。
- 业务需求变更：当业务规则发生变化，导致原有的数据分片规则不再满足业务需求时，需要调整。例如，原本按照用户ID的哈希值进行分片，现业务要求按照用户所属地区进行数据处理，此时就需要触发数据分片调整。这需要开发团队与业务部门密切沟通，及时掌握业务需求的变动。
数据迁移方案
- 增量迁移：在开始正式迁移前，记录从决定迁移到实际迁移这段时间内发生的增量数据。可以使用数据库的日志机制，如MySQL的二进制日志，记录新产生的数据操作。在迁移过程中，先迁移存量数据，然后在迁移完成后，将记录的增量数据应用到新的分片上。这样可以减少数据迁移过程中的数据不一致问题。
- 并行迁移：为了加快迁移速度，将数据按一定规则（如按数据块、按时间范围等）划分为多个子集，然后并行地将这些子集迁移到新的分片。例如，对于按时间戳存储的数据，可以按月份将数据划分成多个子集，同时启动多个迁移任务，每个任务负责迁移一个子集的数据到目标分片。但要注意并行任务之间的资源竞争问题，合理分配系统资源，避免因资源不足导致迁移失败。
- 预迁移：在正式迁移之前，可以先进行预迁移操作，即先将部分数据迁移到新的分片上，观察系统的运行情况。这样可以提前发现潜在的问题，如网络带宽是否足够、新分片节点的性能是否满足要求等。根据预迁移的结果，对迁移方案进行调整优化，然后再进行正式迁移。
保证系统可用性和数据一致性
- 读写分离：在数据迁移过程中，将读操作和写操作分离。对于读操作，仍然从原有的分片读取数据，直到新的分片数据迁移完成并验证无误后，再将读请求切换到新的分片。对于写操作，除了在原分片执行外，同时记录这些写操作到一个“迁移日志”中。当数据迁移完成后，按照“迁移日志”将写操作应用到新的分片上，保证新分片的数据一致性。可以使用数据库中间件（如Mycat、ShardingSphere等）来实现读写分离功能。
- 双写模式：在迁移期间，对数据的写入同时操作原分片和新分片，直到新分片的数据迁移和验证完成。这种方式虽然会增加系统的写入负担，但可以最大程度保证数据的一致性和系统的可用性。为了降低双写带来的性能影响，可以对写操作进行优化，如批量写入、异步写入等。同时，要确保双写过程中两个分片的数据更新操作具有原子性，避免出现部分数据更新成功、部分失败的情况。
- 版本控制：为每个数据记录添加版本号字段。在数据迁移过程中，每次数据更新操作都会使版本号递增。在迁移完成后，通过比较原分片和新分片上相同数据记录的版本号，来验证数据的一致性。如果版本号不一致，说明数据在迁移过程中可能出现了问题，需要进行修复。可以通过数据库触发器或应用程序逻辑来实现版本号的自动更新。
- 一致性校验：在数据迁移完成后，对迁移的数据进行一致性校验。可以采用哈希校验、数据总量对比等方式，确保原分片和新分片的数据完全一致。例如，计算原分片和新分片上数据的哈希值，若哈希值相同，则说明数据在迁移过程中没有发生变化。对于关键业务数据，可以进行全量对比，逐行检查数据的一致性。在校验过程中发现的不一致问题，要及时记录并进行修复。
- 故障恢复机制：在数据迁移过程中，若出现节点故障、网络故障等异常情况，要有相应的故障恢复机制。例如，记录迁移进度，当故障恢复后，从故障发生的位置继续进行迁移。同时，对已迁移的数据进行备份，以便在出现数据丢失等问题时能够恢复到故障前的状态。可以使用分布式文件系统（如Ceph）来存储迁移备份数据，保证数据的可靠性和可恢复性。