大型服务平台（如亚马逊）如何处理高并发海量交易请求？

一、并发交易核心处理思路 #

你描述的每秒100单的场景属于电商常见的热点商品交易场景，核心要解决超卖防控、请求响应效率、服务稳定性三个问题，常规处理逻辑如下：

• 缓存层预扣库存：把商品库存提前同步到Redis这类分布式缓存中，校验库存时直接调用Redis的DECR原子命令扣减，成功才进入后续流程，失败直接返回库存不足。这一步耗时可以压低到1ms级，远低于直接查数据库的10ms，还能避免并发场景下的库存超扣。
• 分布式锁隔离热点请求：针对单款商品加细粒度分布式锁，控制同时进入支付流程的请求数量，避免大量并发请求直接打垮下游支付、库存服务。
• 流程异步解耦：库存预扣成功后直接给用户返回「下单成功，等待支付确认」的响应，不需要同步等待卡组织支付、库存更新的全流程完成，大幅降低用户等待时间。

二、大型服务是否使用单一数据库 #

绝对不会仅使用单一数据库，原因如下：

• 单库的读写性能、存储容量都有上限，无法支撑电商场景下海量的交易、用户、商品数据存储和高并发读写请求。
• 大型平台会做多层存储架构设计：
  • 用分布式缓存扛高频的读请求（比如库存查询、商品信息查询）
  • 数据库层做分库分表、读写分离，按业务域拆分出交易库、库存库、支付库等独立库，读请求走从库，写请求走主库
  • 部分非核心数据还会用搜索引擎、对象存储等其他组件存储，不会把所有请求都压到数据库上。

三、是否会用到队列 #

一定会用到消息队列，核心使用场景包括：

• 削峰填谷：把支付、库存更新这类耗时的异步任务丢到队列中，下游服务按自己的消费能力慢慢处理，哪怕瞬时并发涨到每秒几千单，也不会直接把下游卡组织接口、数据库打垮。
• 服务解耦：订单、支付、库存三个服务通过队列通信，不需要同步等待对方的调用结果，某个服务暂时故障也不会导致全流程崩溃，还可以基于队列做失败自动重试。
• 延迟任务处理：比如支付超时未付款的订单自动取消、回退库存，都可以通过延迟队列实现。

内容的提问来源于stack exchange，提问作者yusung lee