API接口并发处理：异步与队列方案深度对比

电商秒杀，一瞬间涌入几万请求，你的接口同步处理每个请求要200毫秒，算下来单实例一秒只能处理5个——这谁顶得住？高并发场景下，同步处理就是最大的瓶颈，异步和队列才是正解。

异步处理：快速释放连接

同步处理的的问题是：HTTP请求线程要等业务逻辑执行完才能返回，线程被占着，连接池很快耗尽。异步处理的核心思路是：接口收到请求后，把耗时操作扔到后台线程池去执行，接口立即返回。用户不需要等这个操作完成就能拿到响应。比如发邮件、生成报表这类操作，用户不需要等结果，异步处理就非常合适。实现上，Java用CompletableFuture，PHP用Swoole的协程，Node.js天然异步。但注意控制线程池大小，别无限制创建线程，否则内存会炸。一般CPU密集型任务线程数设为CPU核数+1，IO密集型可以设大一些。

消息队列：削峰填谷利器

异步处理解决的是“不需要等结果“的场景，但如果请求量远超处理能力，就需要消息队列来做缓冲。常用方案是RabbitMQ或Kafka。接口收到请求后，把任务写入消息队列就返回，消费者按自己的节奏从队列里取任务处理。秒杀场景下，10万请求进来，写入队列只要1秒，但后台消费者可以慢慢处理，数据库压力可控。选RabbitMQ还是Kafka？请求量万级别以下选RabbitMQ，简单可靠；日志类、大数据量场景选Kafka，吞吐量高。Redis的List也能做轻量队列，LPUSH写入BRPOP消费，适合量不大的场景，省得额外部署一套中间件。

幂等性：必须做

异步和队列都会引入一个关键问题：消息可能重复消费。网络抖动、消费者重启、重试机制都可能导致同一条消息被处理多次。所以消费者端必须做幂等性处理。最简单的方案是用唯一业务ID去重，处理前先查一下这个ID有没有处理过，处理完记录下来。可以用Redis的SETNX命令实现：SETNX order:12345 1 EX 86400，返回1说明是第一次处理，返回0说明已处理过直接跳过。

失败重试与死信队列

消息处理失败怎么办？不能直接丢掉。RabbitMQ可以配置死信队列，处理失败的消息进入死信队列，人工后续处理或告警。重试次数要限制，比如最多3次，每次间隔递增，避免毒药消息把消费者拖死。异步和队列不是万能的，但用对了能让你的接口扛住十倍百倍的流量。