针对智慧安防系统的核心存储模块，如何设计高可用架构？请说明至少两种冗余方案（如主从复制、集群），并分析其适用场景和优缺点。

1) 【一句话结论】智慧安防系统核心存储的高可用架构需结合数据读写模式与一致性要求，主从复制适用于读多写少、对实时性要求不高的场景，集群适用于高并发读写、复杂事务场景，需根据业务特性选择并设计冗余方案。

2) 【原理/概念讲解】主从复制（Master-Slave Replication）是指主节点接收所有写请求，通过二进制日志（Binlog）将变更同步到从节点，从节点可承担读负载。类比：超市收银台（主节点）处理所有付款（写），其他收银台（从节点）同步订单数据，顾客查询订单（读）可去从节点。集群（Cluster）是指多个节点共同存储数据，通过分布式共识协议（如Raft、Paxos）保证数据一致性，节点间负载均衡，支持故障自动切换。类比：餐厅多个厨师（节点）共同处理订单（数据），每个厨师负责部分菜品，餐厅关闭一个厨房（节点故障）不影响整体服务。

3) 【对比与适用场景】

方案	定义	特性	使用场景	注意点
主从复制	主节点写，从节点同步数据，读请求可路由到从节点	写由主节点处理，读可扩展；支持异步/同步复制	读多写少（如视频回放、历史数据查询）、对实时性要求不高的场景	主节点故障导致写不可用；从节点数据延迟（异步复制）；同步复制写延迟
集群	多节点共享数据，通过共识协议保证一致性，支持读写负载均衡	高并发读写、复杂事务（如实时报警、多表关联）；故障自动切换	高并发写、实时性要求高的场景（如实时监控、报警数据）	部署复杂，需处理节点故障恢复；网络分区可能导致脑裂；数据分片管理复杂

4) 【示例】
主从复制示例（伪代码）：

• 主节点（Master）处理写请求：Master.write(data); 将变更写入Binlog。
• 从节点（Slave）启动后，连接Master，读取Binlog并应用变更：Slave.readBinlog(); applyChanges();
• 读请求路由：if (request.type == 'read') routeToSlave();
  集群示例（以MySQL NDB Cluster为例）：
• 节点间通过MGM管理节点状态，数据分片存储在数据节点（Data Node）。
• 写请求：WriteRequest(data); 路由到数据节点，通过共识协议同步到其他数据节点。
• 故障恢复：节点故障时，MGM选举新主节点，数据节点自动同步。

5) 【面试口播版答案】面试官您好，针对智慧安防系统核心存储的高可用设计，核心思路是结合数据读写模式与一致性要求，主要采用主从复制和集群两种冗余方案。主从复制适用于读多写少场景，比如视频回放数据，主节点写，从节点同步并承担读负载，优点是简单易部署，缺点是主节点故障导致写不可用，从节点数据有延迟。集群方案适用于高并发写和复杂事务，比如实时报警数据，多个节点通过分布式共识保证数据一致，支持故障自动切换，优点是高可用，缺点是部署复杂，需处理节点故障和网络分区问题。具体来说，主从复制通过异步/同步复制实现读扩展，集群通过数据分片和共识协议实现高并发与高可用，需根据业务需求选择并设计冗余策略。

6) 【追问清单】

• 问题1：主节点故障时，从节点如何切换为主节点？
  回答要点：从节点通过监控主节点心跳，当检测到主节点故障后，通过选举机制（如Raft协议）成为新主节点，同步数据并继续服务。
• 问题2：集群中节点故障时，如何保证数据一致性？
  回答要点：通过分布式共识协议（如Raft）保证节点间数据同步，故障节点恢复后，重新加入集群并同步数据，确保全局一致性。
• 问题3：如何平衡数据一致性与延迟？
  回答要点：根据业务需求选择复制方式（如异步复制降低延迟，同步复制保证强一致性），例如实时报警需强一致性，视频回放可接受一定延迟。
• 问题4：读请求如何路由到从节点？
  回答要点：通过负载均衡器（如Nginx）或数据库代理（如ProxySQL）将读请求路由到从节点，避免主节点过载。
• 问题5：如何处理数据分片？
  回答要点：根据数据特征（如时间、区域）进行分片，例如按时间分片存储历史数据，按区域分片存储实时数据，避免单节点压力过大。

7) 【常见坑/雷区】

• 坑1：忽略数据一致性要求，比如主从复制中采用异步复制导致读数据不一致，影响业务。
• 坑2：集群方案未考虑网络分区，导致脑裂（节点间数据冲突）。
• 坑3：读请求路由策略不当，导致从节点负载不均，影响性能。
• 坑4：未设计故障恢复流程，比如集群节点故障后无法自动切换。
• 坑5：备份策略不当，比如仅备份主节点数据，从节点数据丢失导致数据不一致。