2025年高频蚂蚁专家面试题及答案.pdfVIP

2025年高频蚂蚁专家面试题及答案

Q1：在金融级分布式系统中，如何设计一个支持日

均10亿笔交易的支付核心系统，确保交易成功率

99.999%且事务一致性？需要重点考虑哪些技术点？

A：设计此类系统需从高并发处理、事务一致性保

障、容灾容错、流量削峰填谷四个维度展开。首先，高

并发处理层面，采用分层架构：接入层通过Nginx+Lua

实现请求分流，按业务类型（如C2C、B2C）和地域做

负载均衡；核心交易层使用微服务拆分，将支付请求拆

解为鉴权、账户扣减、清算等独立服务，每个服务部署

为无状态实例，通过K8s弹性扩缩容。关键是将热点账

户（如高频交易的商户账户）的读写操作从主库剥离，

采用本地缓存+分布式锁（如Redlock优化版），配合

批量写机制（如每100ms聚合1000笔操作后批量更新

数据库），避免单行锁竞争。

事务一致性方面，金融场景需强一致，优先选择

TCC（Try-Confirm-Cancel）模式，但需解决空回滚和

幂等问题。例如，在账户扣减服务中，Try阶段预占额

度并记录事务日志（包含事务ID、账户ID、预占金额、

状态），Confirm阶段根据日志提交预占，Cancel阶段

释放预占。为防止网络波动导致的空回滚（即未执行

Try却收到Cancel），需在Cancel前检查事务日志是

否存在且状态为“尝试中”；幂等性通过事务ID作为

唯一标识，所有操作先查日志，已完成则直接返回。对

于跨多个服务的长事务（如跨境支付涉及清算、合规

等），可结合本地消息表（每个服务将操作结果写入本

地消息表，通过异步MQ通知下游）+对账补偿（每日

凌晨跑批核对各系统交易状态，对不一致的事务人工干

预或自动重试）。

容灾设计需满足“两地三中心”架构，主中心处理

日常流量，同城灾备中心实时同步（通过OceanBase的

Paxos协议实现日志实时复制），异地灾备中心异步同

步（延迟不超过5分钟）。关键服务采用多活部署，如

支付核心服务在主中心和同城灾备中心同时提供服务，

通过GSLB（全局负载均衡）根据中心健康状态动态路

由请求。当主中心故障时，同城灾备中心30秒内接管

流量，切换过程中通过事务ID的全局唯一性确保未完

成交易可恢复（如记录事务在主中心的处理阶段，灾备

中心继续执行）。

流量削峰方面，大促期间（如双11）支付请求可能

达到平时的50倍，需在接入层做限流（基于令牌桶算

法，按服务实例的CPU、内存使用率动态调整阈值）和

降级（非核心功能如支付成功页的个性化推荐暂时关

闭）。同时，使用消息队列（如自研的SOFA-MQ）做异

步化处理：将支付请求先写入队列，核心交易系统按自

身处理能力从队列拉取消息，确保系统不会被突发流量

压垮。队列需支持持久化（RocksDB存储）和高吞吐

（单队列支持10万TPS），并通过死信队列监控失败

请求，人工介入处理。

Q2：在分布式系统中，如何定位跨服务调用链的延

迟突增问题？请描述具体排查步骤和常用工具。

A：排查步骤需从网络、应用、中间件、存储四层

递进分析，结合链路追踪和监控数据。首先，确认延迟

发生的时间范围和影响范围，通过APM工具（如蚂蚁的

SOFATracer）提取该时间段内的调用链，筛选出耗时超

过500ms的链路。观察调用链的拓扑结构，确定延迟是

集中在某个服务（如订单服务）还是跨多个服务（如订

单→支付→库存）。

第一步，检查网络层。使用Tcpdump抓取服务间的

网络包，分析是否存在丢包、延迟或重传。例如，若A

服务调用B服务的RTT（往返时间）从20ms增至200ms，

需查看是否有大量ICMP超时包（可能是路由问题）或

TCP重传（可能是带宽瓶颈）。同时，通过MTR（My

Traceroute）工具追踪A到B的网络路径，确认是否有

跳节点延迟异常（如某运营商节点拥塞）。

第二步，分析应用层。进入延迟服务的服务器，使

用Arthas查看线程栈，定位是否有线程阻塞（如等待

数据库连接、锁竞争）。例如，若线程栈显示大量线程

在等待ReentrantLock的lock()方法，可能是该服务

的某个热点方法未优化，导致锁争用。同时，检查JVM

指标（通过Jstat或Prometheus+JMXExporter），关

注GC频率和停顿时