@kevinjaz http 现在很多为了避免开销都会用到 keepAlive，会维持连接存活一段时间，这段时间就比较尴尬。

看业务的场景吧，你如果只是保证简单的调用某个服务最终是成功的，简单的重试就可以了，无论是同步还是异步，次数到了之后把上下文记下来事后处理就行了。退避间隔较短的话同步，否则就 mq 异步，因为要维护上下文较长时间，消息队列天然具有数据库的能力。如果是分布式事务的场景异步做补偿比较好，因为重试补偿的逻辑通常与业务强相关，坐在同步流程里太重了。

tomcat nio 或者 arp 都是这样的协议，如果你的服务需要处理大量连接，但是每个连接的的负载很小，通过 IO 多路复用的方式，acceptor 线程绑定端口获取新的连接，然后将连接注册到一个或几个 selector 上，selector 通过 poll 或者 epoll 的方式管理多个连接，当 IO 事件到达时，将从连接中拿到实际的请求分配给实际的工作线程处理。这样连接和线程不是绑定。一个 http 请求肯定需要通过一个工作线程去处理，问题在于是在请求到达时分配工作线程还是连接建立时分配。BIO 的方式在连接到达时分配，每个线程管理一个连接，连接不关闭且负载不高时，这部分资源就是浪费的。NIO 是用少量的线程管理大量的连接。负载取决与实际的 http 请求而非连接数。

老哥 邮件发了一个星期了，一直没收到反馈，能帮忙看一下吗？

已发邮件，多谢楼主推荐。

@lovelife1994 1.0 之后的幂等 producer 支持在单个 producer session 单分区内有序？之前配置 in-flight request 为 1