是小鬏鬏啊1. 同步与异步接口：先搞清楚差异再谈选型
做后端开发这些年，被问得最多的一个问题就是：“这个接口到底该写成同步还是异步？”每次我都不急着给答案，先反问对方三个问题：调用方能接受多长的等待时间？这个请求在服务端是快任务还是慢任务？如果一个任务失败了，你要不要立刻告诉调用方？这三个问题问完，大部分同学自己心里就有眉目了。但实际落到项目里，情况远比这三个问题复杂，今天就把我这几年在接口选型上的经验和踩过的坑一次性说清楚。
所谓同步接口，就是发请求后一直等待服务端处理完并返回结果。而异步接口，是服务端先收下请求，返回一个“我已收到，正在处理”的凭证，处理完了再通过回调、轮询或者通知把结果给调用方。两者最本质的区别不在于“快”和“慢”，而在于“等待”与“解耦”。理解了这一点，选型就有了根基。
1.1 从响应时间模型看同步接口的本质
同步接口的黄金准则是“你的响应时间等于上游的全部处理时间之和”。如果接口内部要调三个下游服务，每个下游耗时200毫秒，串行调用时你的接口就是600毫秒起步，再算上自身逻辑和数据库IO，一秒出结果是常有的事。在用户感知层面，超过1秒的接口就已经让体验大打折扣了，超过3秒基本可以宣告这个同步接口设计得有问题。
我在实际的压测中发现，同步接口的吞吐量其实取决于两个因素：平均响应时间和线程池大小。Tomcat默认线程池200，公式上最大吞吐量约等于线程数除以平均响应时间。如果接口平均响应时间500毫秒，200个线程的理论吞吐大约每秒400个请求。看起来还行对吧？但一旦下游服务抖动，响应时间涨到2秒，吞吐就直接掉到每秒100左右，同时线程池迅速被打满，后续请求全部排队等待，这就是典型的“一个慢接口拖垮整个应用”。
所以我在设计同步接口时，一定会在代码里加上两层保护：第一层是RestTemplate或OpenFeign的超时设置，一般连接超时给1秒，读取超时给2到3秒；第二层是对整个Controller方法做信号量隔离或线程池隔离，避免慢调用耗尽全局线程。这两层保护不加上，同步接口在流量稍微上来一点的时候就是定时炸弹。
1.2 异步接口的核心场景与代价
异步接口的出发点很简单：当用户等不起、也不需要立刻拿到结果的时候，就先给一个“请求已受理”的响应，后台慢慢处理。最典型的例子是批量导出数据、大量数据的清洗任务、发送营销短信或邮件，以及和第三方系统的数据对账。这类场景的共同特征是处理时间呈长尾分布，偶尔会有几十秒甚至分钟级的任务，用户不可能一直傻等。
但是异步是有代价的，而且这个代价往往被新手低估。首先，你需要一个可靠的存储来记录任务状态，数据库里要多一张任务表。其次，你需要一套回调或查询机制，让调用方能在之后拿到处理结果。再次，你还需要考虑任务的失败重试、死信处理和监控告警。换句话说，同步方案把复杂度集中在调用链条上，异步方案把复杂度转移到了系统的各个角落里。
说到异步接口，我见过不少团队一上来就上消息队列，用的还是Kafka这种重型组件。对于绝大多数内部管理系统的场景，这完全是杀鸡用牛刀。一个可落地的做法是先用数据库任务表加上定时任务扫描，等单量真正上来了，再平滑迁移到MQ。我在多个项目里用这个方案扛过每天百万级的异步任务，稳定性一点不差。
1.3 大模型接口场景下的同步与异步选型
最近做AI应用相关的后端是热点话题，大模型接口的调用让同步异步选型又多了个特殊维度。市面上大部分大模型API的响应时间都很长，流式输出一个完整回答可能要几十秒，用同步方式显然不现实。所以现在主流做法是：用户请求进来，后端立刻启动一个异步任务去调用大模型API，同时返回一个任务ID，前端拿到这个ID后通过SSE（Server-Sent Events）或轮询去拉取流式结果。
这里的核心难点在于大模型接口的流式响应如何透传给前端。我的做法是后端用WebClient发起流式请求，逐块接收大模型返回的数据，然后通过SseEmitter推送给前端。这个过程中，整个请求链路其实是异步的，但用户体验是实时的。这种“异步处理+流式推送”的组合，是现在AI应用后端的主流架构，也最能体现同步异步选型在实际业务中的灵活性。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 选型策略：什么样的接口配什么样的方式
聊完概念和底层模型，进入正题：选型。我在实际工作中总结了一套判断标准，不会空谈理论，就是靠几个具体问题去套。套完之后，绝大多数接口该走同步还是异步，基本不会判断错。
2.1 判断接口走同步的四个硬指标
第一，调用方在用户请求链路中，且用户在等待结果。所有前端页面点击后的第一跳请求基本都是同步，比如登录、查详情、提交订单，用户要立刻看到结果。
第二，任务的预期耗时在1秒以内，最多容忍3秒。这源于用户对操作响应的心理预期。超过3秒，用户大概率会刷新页面或重复点击，引发更多问题。
第三，下游依赖少且稳定。如果接口只查一个库、调一个稳定的内部服务，同步完全够用。
第四，业务要求强一致性。比如转账扣款，你必须在同一个事务里把账记完，这种场景异步反而更麻烦。
这四个指标同时成立，闭着眼写同步就行。但有一个特例值得注意：查询类接口如果内部涉及多条复杂SQL或多次远程调用，即使数据量不大，我也倾向用CompletableFuture把无依赖的几个查询并行化，把串行的300毫秒压到80毫秒。这不改变同步接口的性质，但通过“同步接口内部异步化”来降延迟，算是一个进阶优化。
2.2 判断接口走异步的四个信号
第一，任务耗时有明显的长尾分布。平均可能就几十毫秒，但有些数据量大、要处理复杂的任务磨到几十秒，这类任务只要混在同步接口里，就会让接口的TP99惨不忍睹。
第二，用户不关心即时结果。典型的如导出报表，用户只需要知道“你的导出任务已提交，完成后可下载”。这种场景做成同步就是在透支用户体验。
第三，高并发写入场景。比如用户操作日志、埋点数据、账单流水，这类数据的特征是量大、实时性要求极低。用同步写入数据库反而拖垮主流程，异步批量写入是标准解法。
第四，需要和第三方系统交互，且对方接口响应不可控。外部接口超时和限流是家常便饭，同步方式会让你的线程池被对方的抖动拖死，异步加重试缓冲则是稳妥的解法。
2.3 一个真实的取舍案例：订单超时关闭
我之前做电商订单系统时，有一个“超时未支付自动关闭订单”的需求。最直观的想法是同步定时任务每分钟扫一次订单表，把超过30分钟未支付的订单数据库字段改掉。但随着订单量上涨，扫全表效率低，而且订单状态要及时关闭给库存释放信号。
后来改成异步方案：创建订单时同时发送一条延迟消息到RocketMQ，延迟30分钟。消息到了之后查询订单状态，如果还是待支付就关闭。这个方案精准地每单一条消息，不再全表扫描，同步改异步，成本就是多引入了一个MQ依赖。这个案例很好地说明，异步方案并不一定比同步复杂，关键看业务形态和现有的基础设施。
3. CompletableFuture实战：从线程池到异常处理全套细节
实际工作中，我用CompletableFuture做异步化的频率最高，但也是踩坑最多的工具，没有之一。网上教程一抓一大把，但大部分教的是API怎么用，真正有价值的线程池选型、异常传播和任务编排细节，很少有人说透。这一节我就把这些核心细节掰开揉碎讲清楚。
3.1 基础用法与重要概念：为什么线程池必须自己建
CompletableFuture最基本的功能是把任务丢到线程池里异步执行，主线程不用等。比如我要并发调用用户服务和订单服务，把结果拼装后返回，写法就是CompletableFuture.supplyAsync(用户服务, 线程池)和CompletableFuture.supplyAsync(订单服务, 线程池)，再用thenCombine把两个结果合起来，最后在主流程里join等待。
但这里第一个坑很多人没注意到：如果不传线程池参数，supplyAsync默认用的是ForkJoinPool.commonPool()。这个公共池的线程数等于CPU核数减一，而且它是全JVM共享的，被所有不指定线程池的异步任务共用。别小看这个默认值，在高并发场景下，线程数少会导致任务大量排队，响应时间急剧上升，更糟的是如果你在异步任务里又嵌了异步任务，一不小心就把公共池占满，连带影响系统里其他模块的异步逻辑。
所以我在代码规范里有一条铁律：任何异步任务必须显式指定线程池，绝不使用默认公共池。通常做法是单独配置一个业务线程池，核心线程数10到20，最大线程数按压测结果浮动，队列用有界队列，拒绝策略选CallerRunsPolicy。CallerRunsPolicy的意思是线程池满的时候，任务不丢弃，而是回退到调用线程执行，这样既不会丢消息，又能通过调用方线程天然形成一种背压保护。
3.2 异常处理：exceptionally、handle、whenComplete有何不同
CompletableFuture的异常传播机制非常让人头疼，新手在这里非常容易踩坑。whenComplete和handle虽然都能拿到结果和异常，但两者最大的区别是：whenComplete不能改变结果，即使捕获了异常，返回给下游的依然是异常状态；而handle必须返回一个新值，用它就可以把异常“消化”掉，让链路继续往下走。
exceptionally是专门处理异常的，它返回一个替代结果。我的习惯是：如果某个异步任务失败后，希望后续链路继续执行，优先用exceptionally或handle；如果失败后想让链路立刻终止并向上抛错，就用whenComplete配合自定义异常处理，或者干脆不加处理让它自动传递。
这里说一个具体场景：我在排查线上问题时发现，一个异步任务里调用了远程服务，远程挂了抛了超时异常，因为代码里只写了thenApply没写任何异常处理，异常就顺着链路往下传，最终整个CompletableFuture完成时是异常状态，而主线程早就返回了，异常直接被吞掉。这个问题非常隐蔽——日志里看不到任何错误，但上游数据就是少了。排查了大半天才定位到是异步异常没处理。
3.3 实战踩坑：异常后不再执行其他异步任务
热搜词里有一条“completablefuture异常后不在执行其他的异步任务”，这正是一个实践中的高频需求。先解释现象：CompletableFuture的任务编排本质是树状依赖，一个节点抛异常，所有依赖它的后续节点都会变成异常完成状态，不再正常执行。很多同学以为是代码逻辑写错了，其实是框架本身的机制。
我遇到过最让人迷惑的场景是：任务A成功后要执行任务B和C，任务A失败了的话B不执行，但希望C里的兜底逻辑能跑起来，用于记录失败日志。直接写thenApply和thenAccept的话，A异常时B和C都会被短路。正确解法是给A先加exceptionally或handle，在异常分支里返回一个“哨兵值”，让后续节点以为A成功了，再在B和C里判断哨兵值做不同处理。这种写法虽然多了一步，但能把失败分支的动静全部收拢到可控的代码路径里。
3.4 配套使用的异步工具：whenComplete的幂等性保障
异步逻辑里最常见的并发问题是“回调重复执行”。网络的不可靠决定了客户端可能因为超时而重试，同一个回调可能在短时间内被触发多次。我处理这类问题时会很自然地用whenComplete配合一个分布式锁或者数据库唯一索引做幂等保护。也就是说，不管回调来了几次，业务侧只处理第一次，后面的直接忽略。这个设计思路和接口幂等性是同一个逻辑，放在异步场景下尤其关键。
4. 异步接口的落地链路：消息队列、状态机与幂等方案
接口选型不是写完一个异步方法就结束了。一旦决定走异步，后面整个系统链路都要跟着配套调整，否则异步就是失控的。我在项目里梳理了一条通用的异步接口落地链路：接收请求、记录任务、投递消息、异步消费、更新状态、结果通知。每一环都有对应技术选型，下面展开讲。
4.1 任务表设计：异步系统的地基
异步接口的第一步是先把请求的数据落库。比如用户提交了一个批量数据清洗任务，你可以在请求体里拿到任务ID、清洗类型、上传文件路径等基本信息。我会设计一张task表，核心字段包括任务ID、任务类型、状态、请求参数、错误信息、重试次数、创建时间、更新时间。
状态字段是重中之重，我一般用整数枚举定义：0初始化，1处理中，2成功，3失败。为什么用整数不用字符串？因为整数比较起来效率高，而且枚举状态可以玩状态机，你可以在代码里配置“允许从1流转到2或3，不允许从2流转到3”，在并发场景下这是最后一道防线。任务表建好后，接口接进来第一件事就是插入一条状态为0的任务记录，返回任务ID给调用方。
4.2 MQ与定时任务：两条不同的执行通道
任务存进数据库之后，怎么触发真正的处理逻辑？我见过两种主流方案。一种是生产者把任务ID投递到消息队列，消费者收到后更新任务状态为处理中并执行具体业务。另一种是定时任务每秒或每分钟扫一次任务表，把状态为0的捞出来执行。
两种方案我都落地过大项目，说下我的判断：如果异步任务的峰值量级在每秒几百笔以内，定时任务扫表完全够用，代码简单、链路短、排查问题省力。如果量级往上走，或者你需要延迟消息、死信队列这类高级特性，再上MQ不迟。Kafka适合吞吐量极大的日志流场景，但对于业务异步任务，我更推荐RocketMQ或RabbitMQ，它们的消息确认机制对业务开发更友好，使用成本也更低。
4.3 接口幂等性的完整实现方案与避坑清单
热搜词里有“接口幂等性”，这确实是一个绕不开的话题。先明确概念：幂等性就是指同一个请求被发送多次，对系统产生的影响跟发送一次是一样的。为什么同步接口也要考虑幂等？因为在网络环境里，客户端超时后会重试，网关也可能对上游请求做多次转发，如果不做幂等，用户明明只付了一笔钱，数据库里可能就有了两条支付流水。
常见的幂等实现方案有三种：第一种是在业务表中加唯一约束，比如支付流水号、订单号，插入重复数据时数据库报主键冲突，业务捕获异常直接返回成功。第二种是前置一张幂等表，请求进来先查幂等表，存在就直接返回旧结果，不存在则插入并继续处理。第三种是基于状态机的幂等，比如一笔订单只有待支付状态才能执行支付操作，已经支付成功的订单再次收到支付请求就返回成功，但是不改数据。
避坑清单里最重要的一条是：幂等表的插入操作必须放在事务里，并且利用数据库的唯一索引来保证并发安全。单独先查再插入会有并发窗口，两个请求同时查到不存在，同时插入，结果一个成功一个报错，表面看没问题，但如果业务没捕获报错就会暴露异常。我的做法是直接让插入幂等表成为整个业务事务的第一条语句，利用唯一索引保证同一时刻只有一个请求能成功插入，其他请求要么等待要么直接拿已有结果，安全又高效。
4.4 异步回调与状态通知机制
异步任务执行完，怎么通知调用方？这里我推荐“主动查询为主、回调为辅”的策略。主动查询是调用方拿着之前拿到的任务ID轮询你的查询接口，这个查询接口就是查任务表返回状态，实现很简单，适合绝大多数内部系统。回调是任务完成后你的服务主动调对方的接口，适合跨系统对接，但需要双方约定好鉴权、签名、超时和重试机制，复杂度上了一个档次。
轮询接口还有一个优化点：不要让客户端拿任务ID每次去全表扫描，任务表有主键ID，直接主键查询，数据库走聚簇索引，性能毫无压力。另外轮询频率要控制在合理范围，我一般建议前端每隔3到5秒查一次，既保证了状态更新的及时性，又不会给服务端造成无效压力。如果用SSE，则可以实现服务端主动推送，效果更实时，但对网关配置有要求，可以用Nginx或Spring WebFlux实现。
5. 选型决策速查表与常见坑排查实录
这是全文最值得收藏的部分，我把这些年经验沉淀成决策表和问题清单，你自己踩坑的时候拿出来比照，能省下大量排查时间。
5.1 同步异步选型决策速查表
| 场景特征 | 推荐方案 | 原因 |
|---|---|---|
| 用户登录、查询详情、提交订单 | 同步 | 用户需要即时反馈，等待时间可控 |
| 批量导出、批量导入、报表生成 | 异步 | 任务耗时长且有长尾分布 |
| 日志上报、埋点数据、行为采集 | 异步 | 写入量大，实时性要求低 |
| 支付回调、退款处理 | 同步 | 需要实时确认结果，且对一致性要求高 |
| 第三方系统交互（短信等） | 异步 | 外部接口不可控，需要重试缓冲 |
| 数据库大批量更新或同步 | 异步 | 避免长事务锁表和主库压力 |
| 新用户注册（含欢迎通知、初始化配置） | 同步+异步落库 | 主流程同步，附属操作异步，兼顾体验和性能 |
5.2 排查实录一：异步线程池耗尽导致的接口雪崩
有一次上线后，服务端突然大量超时，GC也频繁告警。排查时先看线程池监控，发现自定义的异步线程池队列被占满，拒绝策略是CallerRunsPolicy，也就是任务回退到Tomcat线程执行，这一下Tomcat线程也被占满，整个应用就雪崩了。
根因是异步任务里有一个第三方接口突然变慢，平均响应时间从200毫秒涨到10秒，大量异步任务被阻塞在线程池里，队列越堆越多，最终把调用方线程全部拖死。事后我加了三个防线：一是给所有异步任务里的远程调用设置超时，绝不无限等待；二是线程池的队列长度设置上限，超过就快速失败而不是无限堆积；三是增加线程池活跃线程数、队列深度等核心指标的监控告警。
5.3 排查实录二：异步任务失败但不报错的诡异现象
另一个印象深刻的案例是数据对账任务每天少算一部分数据，日志里没有任何异常信息。一开始以为是数据源问题，排查了很久才发现是CompletableFuture异步任务里有一个子任务抛了异常，而代码里既没有exceptionally也没有handle，异常被默认吞掉，整个异步链路静默失败。
从那以后我定了一个规矩：所有异步任务入口必须统一接收异常，要么记录error日志，要么写入任务失败表，两者必选其一。绝不允许把异步任务写成“生死不明”的野孩子。同时我在线程池里设置了UncaughtExceptionHandler，兜底捕捉所有线程未处理异常，保证任何漏网之鱼都有日志可查。
5.4 排查实录三：本地事务与异步任务的数据一致性问题
再分享一个典型的“同步事务内搞异步”的坑：在一个本地事务里，业务先更新了订单状态，然后发送一个MQ消息，事务提交前消息已经被消费者消费，消费者到数据库里去查订单却查不到，因为事务还没提交。数据库隔离级别是绝对看不到未提交数据的，于是消费者处理失败，消息重试了几次还是失败，最后进了死信队列。
解决方案有三个思路：一是事务提交后再发消息，用Spring的TransactionSynchronizationManager注册事务同步回调；二是引入本地消息表，事务里只插入一条待发送消息记录，事务提交后由定时任务扫表发送；三是直接用RocketMQ等支持事务消息的MQ，用半消息机制保证本地事务和消息发送的原子性。我一直觉得理解了这个坑，你就真正理解了异步系统的复杂度在哪里。
5.5 异步编程中关于超时与并发的小技巧
写异步代码还有个容易忘的环节：整体超时。CompletableFuture的每个子任务可以设置超时，但整个异步链路的总耗时是不受控的。比如三个子任务各自1秒超时，但它们是先后依赖的，总耗时可能3秒。要控制总时长，可以orTimeout加在最后一个任务上，超时后整个链路直接以TimeoutException结束。
还有一个并发控制技巧：whenComplete和join两个方法别搞混。whenComplete是异步回调，不会阻塞主线程，适合在异步任务完成后做标记或记录；join是同步等待，会阻塞当前线程直到任务完成，适合在需要统一收口结果的场景。如果用join，千万别在CompletableFuture回调线程里再调用别的任务的join，那样非常容易滑向死锁深渊，真实案例我见过不止一次。
6. 最后的实操心得：什么时候该坚持同步
这篇文章花了大量篇幅讲异步，但在最后的实际操作心得里，我还想强调一个反直觉的观点：能用同步就用同步。
我见过太多团队把简单业务硬生生改成异步，最后引入了一堆复杂度，收益却微乎其微。异步绝不是技术先进性的象征，它只是应对特定问题的工程手段。如果接口本身耗时几十毫秒，上下游都稳定，就用同步，代码可读性高，排查问题直接，日志链路清晰，对团队的整体效率最有利。
在我的项目里，每一个异步方案都要经过review追问：这个请求真的需要异步吗？用户能在3秒内接受吗？异步引入的额外开发和运维成本算过没有？很多同学一上来就写CompletableFuture、上MQ，实际上是没想清楚“异步做的是复杂度转移，而不是复杂度消除”这个根本逻辑。想通了这句，选型基本就成功了一半。