党建内管系统需要7x24小时高可用运行，请设计高可用架构，包括主备切换、负载均衡、灾备方案，并说明如何保证业务连续性。
上海证券交易所A05 党建内管类难度：困难
答案
1) 【一句话结论】
采用“数据库主从热备（主备切换）+ 负载均衡（会话粘性）+ 异地灾备（RPO/RTO）”的混合架构，通过多级冗余、秒级切换和实时数据同步，确保7x24业务连续性，核心是“数据一致性保障+快速切换+冗余资源”。
2) 【原理/概念讲解】
老师：要实现7x24高可用，核心是“冗余”和“快速切换”，具体分三部分：
- 主备切换（数据库热备）：主库处理写操作，备库异步同步数据（如MySQL主从复制），心跳检测（如Keepalived）确保秒级切换，数据一致性通过事务提交确认（如XID或事务日志）保障。
- 负载均衡：Nginx分发请求到后端多台服务器，支持健康检查（剔除故障节点）和会话粘性（如cookie/IP绑定），避免切换后用户会话丢失。
- 灾备方案（两地三中心）：主数据中心与异地灾备中心通过CDC（Change Data Capture）或数据库复制（如MySQL GTID）实时同步，RPO（Recovery Point Objective）<1分钟，RTO（Recovery Time Objective）<5分钟。
类比：主备切换像双引擎飞机的备用引擎，负载均衡像交通枢纽的流量分流，灾备像异地备份数据中心，灾难时快速接管。
3) 【对比与适用场景】
| 架构组件 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 主备切换（数据库热备） | 主库处理写，备库异步同步数据 | 备库不对外服务，切换时数据延迟（秒级），通过事务提交确认保障一致性 | 数据库、核心业务系统 | 需控制同步延迟，切换前验证同步状态 |
| 负载均衡（Nginx） | 分发请求到后端多台服务器 | 均衡负载，支持健康检查和会话粘性 | Web前端、API网关 | 会话粘性配置（如cookie），健康检查频率 |
| 异地灾备（两地三中心） | 主数据中心与异地灾备中心实时同步数据（如CDC） | 灾难时快速切换，RPO<1分钟，RTO<5分钟 | 金融、政务等敏感系统 | 网络延迟低（<50ms），数据同步技术（如MySQL GTID） |
4) 【示例】
-
数据库主从复制配置（伪代码）：
# 主库配置（/etc/mysql/my.cnf） [mysqld] server-id=1 log-bin=binlog binlog-do-db=党建内管系统 # 从库配置（/etc/mysql/my.cnf） [mysqld] server-id=2 log-bin=binlog binlog-do-db=党建内管系统 read-only=1 replicate-ignore-db=mysql replicate-do-db=党建内管系统 -
主备切换脚本（伪代码，使用Keepalived检测同步状态）：
# 检查主库同步状态 status=$(mysql -h 192.168.1.10 -u root -p -e "SHOW MASTER STATUS\G") if [ $? -ne 0 ] || [ "$(echo "$status" | grep -c 'No master for replication')" -ne 0 ]; then # 主库故障，切换到备库 systemctl stop mysql@master systemctl start mysql@slave # 更新Keepalived状态 echo "master down, switch to slave" fi -
Nginx负载均衡配置（会话粘性）：
upstream backend { server 192.168.1.10:3306 weight=1; server 192.168.1.11:3306 weight=1; server 192.168.1.12:3306 weight=1; health_check; sticky cookie session_id expires=1h domain=.example.com; } server { listen 80; server_name app.example.com; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } -
灾备数据同步（假设使用CDC）：
# 主中心CDC配置 bin/cdc-start --source=192.168.1.10:3306 --user=root --password=secret --schema=党建内管系统 --target=192.168.2.10:3306 # 灾备中心CDC配置 bin/cdc-start --source=192.168.2.10:3306 --user=root --password=secret --schema=党建内管系统 --target=192.168.2.11:3306
5) 【面试口播版答案】
面试官您好，针对7x24高可用，我设计的是“数据库主从热备+负载均衡+异地灾备”的混合架构。首先，主备切换采用MySQL主从复制，主库处理写操作，备库异步同步数据，通过Keepalived心跳检测，切换时间控制在秒级，数据一致性通过事务提交确认（如XID）保障。其次，负载均衡用Nginx分发请求，配置会话粘性（如cookie），确保用户会话在切换后不丢失。灾备采用两地三中心，主中心与灾备中心通过CDC实时同步数据，RPO<1分钟，RTO<5分钟。业务连续性通过多级冗余（主备、负载均衡、灾备）、秒级切换和实时数据同步，确保系统无中断。
6) 【追问清单】
- 问题1：主备切换的同步延迟如何处理？
回答要点：通过异步复制，延迟控制在秒级，关键操作（如事务）通过事务提交确认（如XID或事务日志）确保一致性，避免延迟导致的事务不一致。 - 问题2：灾备中心的切换流程是怎样的？
回答要点：灾难时，监控系统检测主中心故障，自动切换到灾备中心，数据同步后恢复服务，恢复时间小于5分钟，具体流程包括故障检测、切换执行、服务验证。 - 问题3：负载均衡的会话粘性如何实现？
回答要点：通过Nginx的cookie或IP绑定，设置session_id cookie，确保用户请求始终发到同一后端服务器，切换后用户会话不丢失。 - 问题4：网络链路冗余如何设计？
回答要点：采用多条网络链路（如光纤+4G），配置BGP或MPLS，确保链路故障时主备切换不受影响，网络延迟低（<50ms）。 - 问题5：监控系统如何保障高可用？
回答要点：实时监控服务器、数据库、网络状态，告警后自动切换，并记录日志便于故障排查，如使用Zabbix或Prometheus。
7) 【常见坑/雷区】
- 数据同步延迟：忽略同步延迟可能导致事务不一致，需通过事务补偿或事务提交确认解决。
- 切换脚本逻辑：未验证备库同步状态就切换，导致数据不一致，需检查同步状态（如binlog位置）。
- 灾备RPO/RTO模糊：未说明具体技术（如CDC）和目标，需明确RPO<1分钟，RTO<5分钟。
- 会话状态管理不当：切换后用户会话丢失，需配置会话粘性或分布式缓存（如Redis）。
- 网络单点故障：单条网络链路导致主备切换失败，需多链路冗余设计。