上交所的系统需要高可用，请解释如何设计一个分布式系统的容错机制，比如主从复制、哨兵、一致性哈希，并举例说明在交易系统中的应用。
答案
1) 【一句话结论】分布式系统容错通过主从复制实现读写分离与数据持久化，哨兵保障自动故障切换，一致性哈希优化负载均衡与故障转移，三者结合可提升交易系统高可用性，需平衡数据延迟、切换延迟与系统复杂度。
2) 【原理/概念讲解】
老师：先讲主从复制，比如MySQL的主从复制，主节点负责处理所有写请求（如交易系统的订单插入），从节点通过同步主节点的二进制日志（binlog）来保持数据一致，从节点用于读请求（如查询订单状态），这样写性能高、读性能也提升。但异步复制时，主节点写入后立即返回，从节点延迟同步，导致数据延迟，甚至主节点故障时从节点数据丢失。解决方案：采用同步复制（如MySQL的半同步模式，从节点确认写入后主节点才返回），或在关键业务中引入分布式事务（如两阶段提交）确保最终一致。
接着讲哨兵，这是Redis的高可用方案，多个哨兵实例负责监控Redis主从实例的状态，当主节点故障时，哨兵通过多数投票选举新的主节点，从节点会重新连接到新的主节点。但选举过程存在延迟（如毫秒级），会影响交易系统的实时响应。优化措施：预选主节点（主节点健康检查时，从节点提前同步数据，故障时直接切换），或减少投票节点数量（配置更多哨兵，但需确保多数节点参与）。
最后讲一致性哈希，用于分布式存储系统，将数据哈希到环上，每个节点负责环上的一段区域。节点故障时，数据会重新映射到相邻节点，减少数据迁移量。为降低节点增删时的迁移影响，引入虚拟节点（每个物理节点对应多个虚拟节点），通过虚拟节点减少数据迁移量。
3) 【对比与适用场景】
| 机制 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 主从复制 | 主节点处理写，从节点同步数据 | 写性能高，读性能提升，数据同步延迟 | 数据库读写分离（如订单存储），读多写少场景 | 异步复制导致数据延迟/丢失，主从切换时读请求失败 |
| 哨兵 | 监控Redis实例，故障时自动切换主节点 | 自动故障检测与切换，高可用 | 缓存服务（如订单状态缓存），单点故障场景 | 脑裂问题（多主节点），选举延迟影响实时交易 |
| 一致性哈希 | 分布式存储，节点故障时数据重新映射 | 负载均衡，故障时数据迁移少 | 分布式存储（如订单分片），数据分片场景 | 节点增删时数据迁移，哈希环计算复杂度，虚拟节点减少迁移 |
4) 【示例】
假设交易系统订单存储在Redis集群，使用主从复制、哨兵、一致性哈希：
- 主节点写订单：
redis-cli set order:12345 {"id":12345,"status":"pending","timestamp":1672531200}（主节点处理写请求，返回成功） - 从节点读取：
redis-cli get order:12345（从节点同步后提供读服务，返回订单数据） - 哨兵配置：
sentinel monitor mymaster 127.0.0.1 6379 2（监控主节点，故障时自动切换） - 一致性哈希分片：
hash = crc32(order_id) % node_count，节点故障时，订单重新计算哈希值，迁移到新节点（如节点1故障，订单12345的hash落在节点2，数据迁移到节点2）。
5) 【面试口播版答案】
面试官您好，关于分布式系统容错，核心是通过主从复制、哨兵、一致性哈希结合实现高可用。主从复制中，主节点处理订单写入（写请求），从节点同步数据用于查询（读请求），提升读性能；哨兵监控Redis实例，当主节点故障时自动选举新主节点，保证缓存服务不中断；一致性哈希用于订单数据分片，节点故障时数据重新映射到相邻节点，减少数据迁移。比如订单系统，主节点写订单，从节点读，哨兵监控，一致性哈希分片，即使主节点故障，从节点接替，哨兵切换主，数据重新分配，确保交易系统持续可用。具体来说，主从复制通过异步复制可能存在数据延迟，但可通过同步复制或事务保障最终一致；哨兵的选举延迟需优化，比如预选主节点减少切换时间；一致性哈希用虚拟节点减少节点故障时的数据迁移量，三者结合提升系统高可用性。
6) 【追问清单】
- 问：主从复制中，从节点数据延迟如何解决？
答：通过设置同步延迟（如异步复制），或在关键业务中采用分布式事务（如两阶段提交），确保数据最终一致。 - 问：哨兵的脑裂问题如何避免？
答：哨兵配置时设置多数节点（如超过半数），故障时通过投票选举，避免多主节点导致数据冲突。 - 问：一致性哈希在节点增删时数据迁移量大吗？
答：一致性哈希通过虚拟节点减少迁移量，节点增删时，只有部分数据需要重新映射，不影响大部分数据。 - 问：交易系统如何保证数据最终一致性？
答：结合主从复制和消息队列（如Kafka），通过事务机制（如分布式事务）确保数据顺序写入，最终达到一致性。
7) 【常见坑/雷区】
- 主从复制只读延迟：忽略延迟可能导致读数据不一致，需评估延迟时间（如秒级内）。
- 哨兵脑裂：未配置多数节点，导致多主节点，数据冲突。
- 一致性哈希节点故障数据迁移：未考虑虚拟节点，导致大量数据迁移，影响性能。
- 高可用与性能平衡：过度设计高可用导致系统复杂，性能下降，需权衡。
- 数据一致性：未考虑最终一致性，导致交易数据不一致，影响用户体验。