评估岗需要对接公司的资产管理系统（如不良资产处置系统），该系统需支持高并发的不良资产信息查询和处置流程。请设计一个高可用、高并发的系统架构，并说明如何保证数据一致性（如资产状态变更、价格更新）。
中国长城资产管理股份有限公司评估岗难度：困难
答案
1) 【一句话结论】
采用微服务拆分+Saga分布式事务模式+缓存+消息队列，结合数据库读写分离与分库分表，通过最终一致性机制保障资产状态变更与价格更新的可靠性，满足高并发需求。
2) 【原理/概念讲解】
老师口吻解释关键组件：
- 微服务拆分：将系统拆分为资产服务、处置流程服务、价格服务等独立模块，通过API网关统一入口，实现独立扩展（类比：企业不同部门各司其职，如财务部、运营部，职责明确，互不干扰）。
- 高并发查询优化：数据库采用读写分离（主库写，从库读，从库分库分表水平扩展），并使用Redis缓存存储热点资产信息（如热门资产列表），减少数据库压力。
- 数据一致性保障：采用Saga模式（分布式事务）解决跨服务数据变更问题。例如，资产状态变更时，资产服务更新数据库后，发布消息到Kafka，处置流程服务消费消息更新流程，价格服务再更新价格，每个步骤通过幂等性处理（如检查消息是否已处理）确保最终数据一致（类比：订单处理中，库存减少且订单成功，避免“库存已减但订单失败”或“订单成功但库存未减”）。
3) 【对比与适用场景】
| 架构/方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| Saga模式（分布式事务） | 通过本地事务+补偿事务保证最终一致性 | 避免长事务，支持异步，适合高并发 | 跨服务数据变更（如资产状态变更） | 补偿逻辑复杂，可能产生循环补偿 |
| 2PC（两阶段提交） | 领导者-从者模式，保证强一致性 | 强一致性，但阻塞风险 | 对一致性要求极高，低并发 | 长事务阻塞，故障恢复复杂 |
| 缓存雪崩解决方案 | Redis集群+分布式锁+缓存预热 | 缓解集中过期压力 | 高并发热点数据查询 | 需合理设置过期时间，避免集中过期 |
| 消息队列持久化 | Kafka日志文件存储，生产者确认机制 | 确保消息不丢失 | 服务间异步通信 | 需消费者幂等性处理，避免重复消费 |
4) 【示例】
（资产状态变更的Saga流程，含补偿逻辑）
- 资产服务：检查Redis缓存（若存在且一致），更新数据库（主库事务内）：
UPDATE asset SET status='处置中' WHERE id=1001; - 资产服务发布Kafka消息（主题：
asset_status_update）：{"asset_id":1001, "new_status":"处置中"}。 - 处置流程服务：消费消息，更新流程表（事务内）：
UPDATE disposal_process SET step='处置中' WHERE asset_id=1001; - 处置流程服务调用价格服务，更新价格表（事务内）：
UPDATE price SET current_price=50000 WHERE asset_id=1001; - 价格服务发布Kafka消息（主题：
price_update）：{"asset_id":1001, "new_price":50000}。 - 处置流程服务：消费价格更新消息，完成流程。
补偿逻辑（若处置流程服务失败）：
资产服务通过补偿事务回滚状态（如从“处置中”变回“可处置”），并重试发布消息，避免循环补偿（通过补偿计数器控制重试次数）。
5) 【面试口播版答案】
面试官您好，针对高并发不良资产查询和处置流程，我设计的系统架构核心是微服务拆分+分布式事务（Saga模式）+缓存+消息队列。
服务拆分为资产服务、处置流程服务、价格服务等，通过API网关统一入口。高并发查询通过数据库读写分离（主库写，从库读，从库分库分表）和Redis缓存热点数据（如热门资产列表），减少数据库压力。
对于数据一致性，比如资产状态变更，采用Saga模式：资产服务更新数据库后，发布消息到Kafka，处置流程服务消费消息更新流程，价格服务再更新价格，每个步骤都有幂等性处理（如检查消息是否已处理），确保最终数据一致。具体来说，当用户点击“处置”按钮，资产服务先检查Redis缓存，确认状态为“可处置”，然后更新数据库状态为“处置中”，并发布消息。处置流程服务消费消息后，更新处置步骤，同时调用价格服务更新价格，价格服务更新后也发布消息，处置流程服务消费价格更新消息后完成流程。通过这种方式，既保证最终一致性，又避免长事务阻塞，同时消息队列的持久化存储和幂等处理确保消息不丢失，缓存预热和分布式锁解决缓存雪崩问题。
6) 【追问清单】
- 问题：消息队列如何保证消息不丢失？
- 回答：Kafka采用持久化日志存储（acks=all），生产者发送消息后等待服务器确认，消费者幂等性（每个消息只处理一次），确保消息可靠传输。
- 问题：缓存雪崩如何解决？
- 回答：Redis集群+分布式锁，对热点数据做缓存预热，设置合理的过期时间（如5分钟），避免集中过期导致大量请求打到数据库。
- 问题：Saga模式中补偿事务失败怎么办？
- 回答：补偿事务失败后，记录补偿状态（如重试次数），采用指数退避重试（如第一次1秒，第二次2秒，第三次5秒），若重试多次仍失败，触发人工干预。
- 问题：分库分表后跨分库查询如何处理？
- 回答：使用ShardingSphere中间件，自动路由查询，或设计时按资产ID哈希分表，确保查询时能正确路由到对应分库。
- 问题：系统高可用如何保障？
- 回答：服务部署在K8s集群（多实例），数据库主从复制，Redis哨兵模式，消息队列集群（Kafka多副本），确保单点故障不影响整体服务。
7) 【常见坑/雷区】
- 直接用2PC解决跨服务事务，导致长事务阻塞，影响高并发。
- 忽略缓存雪崩，导致数据库压力激增。
- 消息队列未做幂等处理，导致重复消费导致数据错误。
- 未考虑分库分表后的跨库查询路由，导致查询失败。
- Saga模式补偿逻辑不完整，可能导致循环补偿（如补偿失败后重复补偿）。