微信支付是腾讯的关键金融服务，承载着海量交易。这道题考察对分布式事务模式、数据一致性保障和容错系统设计的理解，是腾讯金融科技团队的核心技能要求。
梳理支付流程：用户发起支付→余额校验→余额扣减→订单状态更新→商户入账，涉及多个微服务和数据库。
解释为什么传统2PC在此规模下不可行——阻塞和可用性问题。
描述基于Saga模式的补偿事务方案：每个步骤都有对应的回滚操作。
讨论幂等键、事务状态机和异步对账作为额外的安全网。
对于微信支付这种规模的系统，我会采用基于Saga的最终一致性模型，而非分布式2PC。支付流程由事务协调器编排：第一步预留用户余额（软锁定，未实际扣减）；第二步将订单状态更新为"支付中"；第三步确认余额扣减；第四步异步完成商户结算入账。每一步的状态都记录在事务日志中。如果第三步失败，补偿事务按逆序执行：订单回退为"未支付"，释放余额预留。每个API调用通过唯一的交易ID保证幂等性——重试产生相同的结果。对账服务每隔几分钟运行一次，将事务日志与各服务的本地状态进行比对，标记差异后进行自动或人工处理。对于余额服务，我会使用基于版本号的乐观锁来安全处理并发扣款。
强调幂等性是支付系统的底线要求——面试官会特别关注这一点。
提及对账机制作为最终安全网，不只讲Saga的正常流程。
讨论at-least-once和exactly-once语义的区别，说明为什么at-least-once加幂等性是工程实践中的最优选择。
跨服务的强一致性需要协调协议（2PC/3PC），在网络分区时会降低可用性。微信支付的规模下，允许临时不一致但保证最终对账修正，能提供更好的可用性和吞吐量，同时确保正确性。
事务日志记录了余额已扣减但订单更新失败的状态。对账服务检测到不一致后，要么重试订单更新，要么发起退款。用户也可以通过支付状态查询接口触发人工核查。