Java用NIO实现支持限流降级的RPC客户端，核心是将阻塞I/O替换为非阻塞SocketChannel+Selector多路复用，并在请求入口嵌入令牌桶限流、超时检测触发fallback、基于错误计数的连接熔断及故障转移，同时需手动处理写未完成续写、读边界拆包等细节。
Java 用 NIO 实现支持限流降级的 RPC 客户端，核心是把传统阻塞 I/O 换成非阻塞通道（SocketChannel），配合 Selector 多路复用，再在请求生命周期中嵌入限流（如令牌桶）和降级（如快速失败、fallback）逻辑。不依赖 Netty 也能做，但需手动处理连接管理、编解码、超时、重试等细节——实际项目中更推荐基于 Netty 封装，本文聚焦“纯 NIO + 基础组件”的轻量实现思路。
1. 构建非阻塞通信骨架
用 SocketChannel 和 Selector 管理多个远程服务连接：
- 创建
SocketChannel并设为非阻塞模式：channel.configureBlocking(false) - 注册到共享
Selector，关注OP_CONNECT（连接就绪）、OP_READ（响应可读）、OP_WRITE（请求可写）事件 - 启动单个线程循环调用
selector.select()，分发就绪事件；避免为每个连接启线程 - 连接成功后，手动触发
finishConnect()，再注册OP_WRITE发送序列化后的 RPC 请求（如 JSON 或自定义二进制协议）
2. 在请求入口注入限流控制
限流放在发起调用前，防止打爆下游或耗尽本地连接/线程资源：
- 使用
RateLimiter（Guava）或手写令牌桶：每客户端实例持有一个，例如RateLimiter.create(100.0)表示 100 QPS - 调用
acquire()或tryAcquire()判断是否放行；若拒绝，直接走降级逻辑，不发网络请求 - 注意：限流粒度可按 method、service、host 维度隔离，用
ConcurrentHashMap<String, RateLimiter>管理多桶
3. 实现响应超时与自动降级
NIO 本身无内置超时，需结合时间轮或定时任务主动检测：
立即学习“Java免费学习笔记（深入）”；
- 发送请求时，记录当前时间戳 + 超时阈值（如 3s），存入待响应队列（如
ConcurrentHashMap<requestId, TimeoutEntry>） - 另起轻量调度线程（或复用
ScheduledExecutorService），定期扫描超时 entry，移除并触发 fallback - 收到响应后，根据
requestId从队列中移除对应 entry；匹配不上说明已超时或重复响应，丢弃 - 超时时，不再等待网络响应，直接回调 fallback 方法（如返回默认值、空对象、抛出
RpcTimeoutException）
4. 连接熔断与故障转移（基础降级）
对频繁失败的服务节点做临时屏蔽，避免雪崩：
- 维护每个远端地址（host:port）的状态：连续错误次数、最后失败时间、是否熔断中
- 每次请求失败（连接 refused、写异常、读超时），递增错误计数；达到阈值（如 5 次/分钟）则开启熔断，持续 30 秒
- 熔断期间所有对该地址的请求直接 fallback，不发网络包；到期后允许试探性放通 1–2 个请求验证恢复情况
- 若有多个可用实例，客户端应支持简单负载均衡（如轮询），故障时自动切到下一个健康节点
不复杂但容易忽略：NIO 下的写操作可能未一次性完成（write() 返回值小于缓冲区长度），需缓存剩余字节，等 OP_WRITE 就绪再续写；读响应也要循环 read() 直到无数据或消息边界完整。RPC 协议必须带长度头或分隔符，否则无法准确拆包。
