面试题：Redis分布式锁保障MySQL数据完整性的故障恢复与数据一致性维护

Redis集群节点宕机：
- 可以通过Redis Sentinel或Redis Cluster自带的集群管理机制来检测节点宕机。Sentinel会定期向各个Redis节点发送PING命令，若在一定时间内没有收到回复，则判定该节点主观下线。当多数Sentinel都认为某个节点主观下线时，会将其标记为客观下线，并自动启动故障转移流程。
- 在应用层面，可以定期尝试获取Redis锁，若连续多次获取锁失败且错误提示与节点连接相关，可辅助判断Redis集群可能存在问题。
MySQL主从切换：
- 应用程序可以通过监控数据库连接状态来检测。例如，使用数据库连接池时，若连接池中的连接不断出现连接失败或重新连接的情况，可能意味着主从切换正在进行。
- 数据库自身通常也有监控工具，如MySQL的MHA（Master High Availability）或Orchestrator等，这些工具可以实时监测主从状态，并提供主从切换的相关信息。应用程序可以通过与这些工具进行交互来获取主从切换的通知。

Redis集群节点宕机：
- 如果使用Redis Sentinel，在故障转移完成后，新的主节点会接管原主节点的工作。应用程序在检测到故障恢复后，需要重新尝试获取分布式锁。由于Redis的持久化机制（如RDB或AOF），在重启后部分锁数据可能仍然存在，但为了确保一致性，应用程序应重新获取锁并按照正常流程操作。
- 若使用Redis Cluster，当节点宕机恢复后，集群会自动重新分配插槽（slot）。应用程序同样需要重新获取锁，在获取锁时，Redis Cluster会根据新的节点状态和插槽分配情况处理请求。
MySQL主从切换：
- 在主从切换期间，由于数据库连接可能不稳定，应用程序获取锁可能会失败。当检测到主从切换完成且数据库连接恢复正常后，应用程序要重新获取Redis分布式锁。可以设置一个重试机制，在一定时间间隔内多次尝试获取锁，直到成功为止。

Redis集群节点宕机：
- 由于Redis节点宕机可能导致部分锁操作丢失，在恢复过程中，应用程序重新获取锁后，要对相关数据进行一致性检查。例如，对于使用Redis锁来控制MySQL写入的场景，应用程序可以在重新获取锁后，对比MySQL中数据的状态与预期状态。若发现不一致，可以根据业务逻辑进行数据修复。比如，重新读取数据、重新计算某些字段值并更新到MySQL中。
- 可以利用MySQL的事务机制，在获取锁后，将涉及数据操作的步骤封装在一个事务中。若在数据操作过程中发现不一致，事务可以回滚，确保数据不会被错误修改。
MySQL主从切换：
- 主从切换可能导致数据复制延迟，从而出现短暂的数据不一致。应用程序在重新获取锁后，可以等待一段时间，让主从数据同步完成。可以通过查询MySQL的主从复制状态（如SHOW SLAVE STATUS命令）来判断数据是否已经同步。
- 对于关键数据，可以在主从切换完成后，进行全量数据对比。例如，通过计算数据的校验和（如MD5、CRC32等），对比主库和从库中相同数据的校验和，若不一致，则根据主库数据修复从库数据。同时，在应用程序层面，要确保在数据修复期间，其他对该数据的操作处于等待状态，避免并发问题导致新的数据不一致。

星途面试题库