面对每秒 200 笔订单请求到达支付服务，服务需调用第三方支付，且第三方限流为 100 笔每秒，请设计一个分布式支付服务，要求请求处理满足 FIFO 顺序，同时总发送量不超过第三方限流但尽量逼近 100 笔每秒的利用上限。请阐述设计思路及需要考虑的关键方面。

回答思路

1. 【回答框架 1】整体方案：采用分布式协调调度加本地队列双缓冲，以全局 FIFO 为目标配置消息队列（如 Kafka、Pulsar）按订单 ID 哈希分区，保证同订单有序，支付请求完成后确认消费，不同订单允许并行以逼近 100 TPS 限流。
2. 【回答框架 2】限流控制：设计中央限流器维护令牌桶或滑动窗口，按第三方 QPS 上限 100 配置，各服务实例通过 Redis/Lua 原子扣减令牌，超限请求进入缓冲队列或重试，确保瞬时请求不超限；同时通过动态调整消费速率尽量使实际发送量贴近 100。
3. 【回答框架 3】顺序保证：基于订单 ID 或支付流水 ID 做一致性哈希，确保同一订单的所有请求都路由到同一分片/队列，在消费端串行处理该分区任务；全局 FIFO 需权衡分区并行度与顺序性的精度，必要时结合时间戳或序号去重。
4. 【回答框架 4】削峰填谷与可靠性：服务器处理 200 TPS 的峰值，用消息队列缓冲，消费端按限流阈值拉取；引入确认和重试机制，确保发送成功才算提交偏移；若第三方返回限流错误，采用指数退避重试，但需保证不超限。
5. 【回答框架 5】监控与动态调整：实时监控队列积压、实际发送 QPS、限流拒绝率，通过自适应算法调整消费并发数或令牌桶速率，达到既不满载也不空闲；需考虑第三方错误码分类与超时设置，防止阻塞拖慢整体吞吐。
6. 【关键点 1】利用消息队列分区保证同一订单顺序，不同订单可并行。
7. 【关键点 2】令牌桶或滑动窗口限流器控制全局发送速率不超过 100 TPS，并尽可能逼近上限。
8. 【关键点 3】引入缓冲和重试机制应对峰值流量和第三方限流错误。
9. 【关键点 4】需要实时监控和动态调节，实现高可用与高利用率的平衡。
10. 【关键点 5】明确顺序语义，分布式下通常保证部分有序（如按订单），全局限定需权衡。
11. 【易错点 1】过度追求全局严格 FIFO 会导致吞吐量大幅下降，需结合业务场景明确顺序范围。
12. 【易错点 2】限流器若单点部署成为性能瓶颈和可用性风险，需考虑分布式令牌桶和降级策略。
13. 【易错点 3】重试不当可能造成重复支付或流量放大，需要幂等控制和退避策略。