设计一个支持百万级企业客户、日均处理10万+笔贷款审批请求的高并发企业贷款审批系统，要求响应时间≤3秒，99.9%可用性，请描述系统架构、关键技术选型及容灾方案。

三菱日联银行Global Corporate难度：困难

答案

1) 【一句话结论】
采用微服务解耦架构，通过分布式事务（Seata AT模式）保障核心数据一致性，结合请求限流、熔断、降级，以及Redis缓存、消息队列异步处理、数据库分库分表（含热点数据虚拟分片），并部署多活容灾（MySQL GTID同步+异步复制），确保系统支持百万级客户、日均10万+笔审批，响应≤3秒，99.9%可用性。

2) 【原理/概念讲解】
老师讲解：设计高并发系统需从流量控制、资源隔离、异步解耦、数据分片、容灾保障、数据一致性等维度入手。

分布式事务（Seata AT模式）：核心业务（如审批结果写入数据库）需保证ACID，采用Seata AT模式，将数据库操作转化为本地事务+补偿事务，确保数据一致性，避免分布式事务的复杂性和性能损耗。
消息队列流量控制（背压策略）：消息队列（如Kafka）设置最大堆积数（如1000条），当队列满时，服务端回退请求或前端限流，避免消息堆积导致系统过载；优先级队列用于紧急请求（如风控异常），确保关键消息优先处理。
数据库分库分表与热点数据处理：按企业ID哈希分片，确保数据均匀分布；针对热点企业（如大型集团），采用虚拟分片（如按时间范围分片，如按月分片），或数据迁移策略（如定期将热点数据分散到多个分片），避免热点数据集中导致查询性能下降。
容灾方案（多活数据中心）：主备数据中心部署，数据通过MySQL GTID同步（主从复制）+异步复制（如Binlog异步同步），监控延迟（如延迟指标≤2秒），故障时通过DNS切换或ZooKeeper实现快速切换，业务中断时间≤3秒。

3) 【对比与适用场景】
（注：此处简化，聚焦核心架构，避免分散重点，若需对比可补充，但根据要求，此处省略表格，以要点说明）

分布式事务 vs 最终一致性：分布式事务（如Seata AT）用于核心数据（如审批结果），保证强一致性；最终一致性（如消息队列+补偿）用于非实时逻辑（如通知发送），提升性能。
数据库分片策略：哈希分片（按企业ID）用于数据均匀分布；虚拟分片（按时间/业务类型）用于热点数据分散。

4) 【示例】

请求示例（JSON）：

{
  "requestId": "L202401010001",
  "customerId": "E10001",
  "loanAmount": 5000000,
  "businessType": "制造业",
  "riskScore": null
}

系统流程伪代码：
1. 用户调用贷款审批API（Nginx负载均衡分发）。
2. 审批服务检查Redis缓存（企业信息、信用记录），命中则直接返回。
3. 未命中则查询数据库（分库分表+主从复制），数据写入Redis（随机过期30分钟）。
4. 通过Sentinel实现请求限流（QPS=5000），若超过则返回429。
5. 调用风控服务（通过Kafka异步发送请求），风控处理完成后，Kafka通知审批服务（Seata AT确保风控结果与审批结果一致）。
6. 审批服务根据风控结果、业务规则生成结果，调用熔断器（Hystrix）检查风控服务状态，若熔断则降级（返回默认风控结果）。
7. 最终返回审批结果给用户。

5) 【面试口播版答案】
面试官您好，针对百万级企业客户、日均10万+笔审批的系统，我设计的方案是采用微服务解耦架构，结合分布式事务（Seata AT模式）保障核心数据一致性，通过请求限流、熔断、降级控制高并发，以及Redis缓存、消息队列异步处理、数据库分库分表（含热点数据虚拟分片），并部署多活容灾（MySQL GTID同步+异步复制）。具体来说：前端用Nginx负载均衡分发请求，微服务拆分为用户、审批、风控等模块；关键数据用Redis缓存减少数据库压力，设置随机过期避免雪崩；风控逻辑通过Kafka异步处理，避免阻塞主流程；数据库按企业ID哈希分片，针对热点企业采用虚拟分片迁移；容灾部署主备中心，数据同步延迟≤2秒，故障切换≤3秒。这样既能应对高并发，又能保证低延迟和高可用。

6) 【追问清单】

问：如何解决分布式事务的性能问题？
回答要点：采用Seata AT模式，将数据库操作转化为本地事务+补偿事务，减少分布式事务的开销，确保数据一致性。
问：消息队列的流量控制具体机制？
回答要点：设置最大堆积数（如1000条），队列满时服务端回退请求，或前端请求限流，避免消息堆积。
问：数据库分库分表如何处理热点数据？
回答要点：针对热点企业，采用虚拟分片（如按时间范围分片）或数据迁移策略，将热点数据分散到多个分片，避免热点数据集中。
问：容灾方案中数据同步的延迟如何监控？
回答要点：通过监控延迟指标（如Binlog延迟≤2秒），优化同步策略（如调整复制线程数、网络带宽），确保故障切换时业务中断时间≤3秒。
问：系统如何保证99.9%可用性？
回答要点：通过多活容灾、故障自动切换、健康检查（如Nginx健康检查）、冗余部署（如数据库主从、服务集群），确保系统在故障时仍能保持可用。

7) 【常见坑/雷区】

分布式事务选型不当：如直接用两阶段提交，导致性能下降，应选择Seata AT模式。
消息队列流量控制仅限流入口：未控制内部服务，导致内部服务过载，应设置队列最大堆积数。
缓存未设置随机过期：导致缓存雪崩，影响业务，应设置随机过期时间。
分库分表导致热点数据集中：查询性能下降，需额外数据倾斜方案。
容灾方案同步延迟过高：切换时业务中断，影响可用性，应监控延迟并优化同步。