请设计一个支持千万级不良资产记录、支持实时查询和处置流程的资产管理系统，需考虑高并发、数据一致性和可扩展性，请描述系统架构、核心模块设计及关键技术选型。

1) 【一句话结论】针对千万级不良资产管理系统，采用微服务+分布式数据库（分库分表+读写分离）+Redis+Kafka的架构，通过分库分表处理热点数据、缓存+异步解耦，结合Saga模式保证数据一致性，实现高并发查询与处置流程的实时管理，兼顾系统可扩展性与数据一致性。

2) 【原理/概念讲解】老师会解释系统核心设计：

• 微服务拆分：按业务边界拆分为资产查询服务（高并发读）、处置流程服务（读写操作）、用户服务（权限与日志）。服务间通过API或事件通信，拆分明确，避免职责混淆。
• 分布式数据库（分库分表）：核心资产表（如资产主表）按时间维度分库（如按年份，如2020库、2021库），按业务维度分表（如按资产类型，抵押物表、债权表），单表数据量控制在百万级以内。非结构化数据（如处置记录）用MongoDB存储。热点数据（如热门资产类型）在分库分表中分布不均时，采用“按资产类型+时间”复合分片键，确保热点数据均匀分布。读写分离：主库写，从库读，提高查询性能。
• 缓存策略：Redis缓存热点数据（如热门资产列表、用户信息、资产状态统计），采用“读多写少”模式。缓存穿透：用布隆过滤器拦截无效查询（如资产ID不存在）。缓存雪崩：设置随机过期时间（TTL在5-30分钟内随机），启动时预加载热门资产到缓存，避免集中失效。
• 消息队列解耦：处置流程的审批、通知等异步任务通过Kafka发送，将实时请求与耗时操作解耦，提高响应速度。事务性消息：确保消息发送与本地事务原子性（如Kafka事务性消息）。
• 分布式事务（Saga模式）：强一致性需求（如资产状态变更与审批记录同时写入）采用Saga模式。步骤：1. 资产状态变更服务执行本地事务（更新资产表状态为“处置中”）；2. 发布Kafka事件（资产状态变更事件）；3. 处置流程服务消费事件并写入审批记录表；若步骤2或3失败，触发补偿事务（回滚资产状态，删除审批记录）。补偿事务通过检查补偿状态字段（如compensation_status）保证幂等性。
• 负载均衡与服务注册发现：微服务部署在集群中，通过Nginx实现请求负载均衡（如轮询、权重），服务注册发现用Nacos，服务间通过Nacos注册服务地址，动态发现服务实例，支持集群扩展。

3) 【对比与适用场景】用表格对比数据库选型：

方案	定义	特性	使用场景	注意点
MySQL（分库分表）	结构化数据存储，支持ACID事务	事务强一致，支持分库分表，高并发下读写分离	核心资产信息（资产ID、状态、债权金额等）、用户数据	需合理设计分库分表规则（如时间+资产类型），避免热点表导致性能瓶颈
MongoDB	非结构化/半结构化数据存储	高扩展性，灵活的文档模型，读写快，支持聚合查询	处置记录（如拍卖记录、法律文书）、日志、非结构化资产描述	不支持复杂事务，数据一致性弱，适合非核心数据
Redis	内存数据库，支持数据结构	高速读写（毫秒级），支持缓存、会话、消息队列	热点数据缓存（如资产列表、用户信息）、分布式锁、消息队列持久化	需设置过期策略，避免缓存雪崩；持久化（RDB/AOF）保证数据不丢失
Kafka	分布式消息队列	高吞吐、持久化、顺序性	异步任务解耦（如处置流程通知）、日志收集、事件驱动	需配置持久化、分区、副本，避免消息丢失

4) 【示例】

• 查询请求示例（HTTP）：

  GET /api/assets?status=1&pageSize=20&pageNo=1
  Host: asset-management.com
  Authorization: Bearer <token>
  

  系统处理：1. 检查Redis缓存（key为assets:status:1:page1），命中则直接返回缓存数据；2. 未命中，查询MySQL分库分表后的资产表（如2020库的抵押物表），按分页条件查询；3. 结果存入Redis缓存（TTL设为5分钟），返回数据给用户。
• 分布式事务补偿示例（Saga模式）：
  当处置流程审批通过后，触发Saga补偿逻辑：
  1. 资产状态变更服务执行本地事务：更新资产表asset_id=A001的status为“处置中”；
  2. 发布Kafka事件：topic=asset_status_change, payload={"asset_id":"A001","new_status":"处置中","timestamp":"2023-10-27T10:30:00Z"}；
  3. 处置流程服务消费事件，执行本地事务：插入审批记录表approval_record；
     若步骤2失败（如Kafka发送失败），补偿事务检查资产状态是否已变更（通过查询资产表），若已变更则跳过；若步骤3失败，补偿事务回滚资产状态（将status改回“待处置”）并删除审批记录。

5) 【面试口播版答案】面试官您好，针对千万级不良资产管理系统，我设计思路是采用微服务架构，拆分为资产查询、处置流程等独立服务。数据库层面，核心资产表按时间分库（如按年份，如2020库），按业务分表（如按资产类型，抵押物表），避免单表过大。用Redis缓存热点数据，减少数据库压力。处置流程的异步任务通过Kafka消息队列解耦，提高响应速度。数据一致性方面，强需求用Saga模式（本地事务+补偿事务），非强需求用最终一致性。这样既能支持高并发查询，又能处理复杂处置流程，兼顾可扩展性与数据一致性。

6) 【追问清单】

• 问：如何处理缓存雪崩？
  回答要点：设置随机过期时间（TTL在5-30分钟内随机），启动时预加载热门资产到缓存；若缓存失效，通过布隆过滤器拦截无效查询，避免数据库压力激增。
• 问：分布式事务Saga的补偿逻辑如何保证幂等性？
  回答要点：补偿事务通过检查补偿状态字段（如compensation_status）判断是否已执行，若已执行则跳过；同时，补偿事务ID唯一，避免重复执行。
• 问：微服务间数据如何同步？
  回答要点：核心数据通过Saga模式保证强一致性（如资产状态变更时发布事件，其他服务消费并写入）；非核心数据通过事件驱动（如处置记录变更时发布事件，日志服务订阅处理），实现最终一致性。
• 问：系统如何实现水平扩展？
  回答要点：微服务独立部署，通过Nginx负载均衡分发请求；数据库分库分表后，通过读写分离（主从复制）提高查询性能；Redis和Kafka集群部署，支持节点水平扩展。
• 问：处置流程的复杂逻辑如何管理？
  回答要点：引入工作流引擎（如Activiti），定义处置流程的标准化节点（如审批、拍卖、法律执行），微服务调用工作流服务，实现流程的可配置与标准化管理。

7) 【常见坑/雷区】

• 忽略分库分表导致单表数据过大，查询性能下降（如未按时间或业务维度分表）。
• 缓存未加布隆过滤器，导致缓存穿透，数据库被大量无效查询压垮。
• 分布式事务Saga补偿逻辑未考虑幂等性，导致重复补偿，数据不一致（如资产状态被多次回滚）。
• 微服务间同步调用，高并发下服务阻塞，影响系统响应速度（如资产查询服务调用处置流程服务，导致查询延迟）。
• 忽略消息队列的持久化设置，导致消息丢失（如Kafka未开启持久化，处置流程失败后无法重试）。
• 数据库分库分表规则不合理，导致热点表（如热门资产类型）在所有分库中分布不均，性能瓶颈。