Reactor 响应式编程

概述

响应式编程用数据流 + 异步非阻塞处理高并发 IO：少量线程扛海量请求，靠背压控制流量。Reactor 是 JVM 上的反应流实现，Spring WebFlux 基于它构建。对游戏服务器而言，响应式最适合网关层（高吞吐、无状态转发），逻辑层仍需有状态处理。本文介绍 Reactor/WebFlux 的网关应用、背压控制与 Netty EventLoop 的整合。

---

一、响应式基础

1.1 核心概念

响应式三要素：
  Publisher（发布者）：数据流来源
  Subscriber（订阅者）：消费数据
  Subscription（订阅关系）：连接与背压

编程模型：
  Flux：0..N 个元素流
  Mono：0..1 个元素（类似异步 Optional）
  操作符：map/filter/flatMap 组合数据流

// Reactor 示例
Mono<PlayerInfo> player = playerService.find(playerId)
    .map(this::toDto)
    .timeout(Duration.ofSeconds(3));

1.2 为什么适合网关

非阻塞 IO：
  少量线程处理海量连接（与 Netty 同源）
  线程不被阻塞等待（无 Blocking IO）

游戏网关场景：
  高并发连接（万人在线）
  请求转发（无状态，响应式天然适合）
  协议代理（WS → 逻辑服）

---

二、WebFlux 在网关层应用

2.1 网关模型

Spring Cloud Gateway + WebFlux：
  路由：路径/参数 → 目标服务
  过滤器：鉴权、限流、日志（WebFlux 响应式过滤器）
  转发：HTTP 转发到逻辑服

游戏场景适配：
  WebSocket 长连接网关（HTTP 不适用时用 Netty WS）
  HTTP 接口（公告/排行榜查询/登录）

// WebFlux 过滤器示例（响应式，非阻塞）
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
    // 校验 Token（异步查 Redis）
    return authService.verify(token)
        .flatMap(ok -> ok
            ? chain.filter(exchange)
            : reject(exchange));
}

2.2 网关职责划分

响应式网关适合：
  短请求转发（登录、查询、REST）
  协议校验与限流（前置过滤）
  结果聚合（并行调用多个服务）

不适合：
  长连接游戏主通道（用 Netty WS，见网关章节）
  高吞吐低延迟自定义协议（Netty 更贴合）
  结论：WebFlux 与 Netty 各司其职

---

三、背压 Backpressure

3.1 背压原理

背压问题：
  生产快、消费慢 → 队列积压 → 内存爆炸

背压解决：
  消费者主动请求数量（request(n)）
  生产者按需生产（不超量）
  可选策略：缓冲/丢弃/错误

游戏网关应用：
  消息推送风暴 → 背压保护
  客户端慢 → 缓冲或丢弃（丢非关键消息）

// 背压示例：按需拉取
Flux<PushMsg> pushes = messageSource.pushes();
pushes
    .onBackpressureBuffer(1000)      // 限缓冲
    .subscribe(new BaseSubscriber<>() {
        @Override
        protected void hookOnSubscribe(Subscription s) {
            request(64);              // 每次拉 64 条
        }
        @Override
        protected void hookOnNext(PushMsg m) {
            handle(m);
            request(64);              // 处理完继续拉
        }
    });

3.2 游戏场景背压

场景：全服广播 → 慢客户端
  对策：按客户端能力分档（缓冲上限/丢弃）
  关键消息（对局）优先，非关键（播报）可丢

场景：排行榜投影消费
  事件生产快 → 消费跟不上 → 背压/批量消费

策略选择：
  有界缓冲 + 丢弃最旧（实时场景）
  无限缓冲 + 落库（可延迟处理）
  直接错误（客户端可重试）

---

四、与 Netty EventLoop 整合

4.1 同源架构

Reactor 与 Netty 的关系：
  Reactor Netty（WebFlux 底层）基于 Netty
  Netty EventLoop 驱动反应流调度
  两者共享非阻塞 IO 理念

线程模型：
  Reactor 的调度器（Schedulers）可绑定 Netty EventLoop
  数据流处理在 EventLoop 线程（不阻塞）

// 在 Netty Handler 中集成响应式（伪代码）
public class ReactiveHandler extends SimpleChannelInboundHandler<Msg> {
    @Override
    protected void channelRead0(ChannelHandlerContext ctx, Msg msg) {
        Mono.fromCallable(() -> bizService.handle(msg))   // 异步业务
            .subscribeOn(Schedulers.boundedElastic())
            .subscribe(result -> ctx.writeAndFlush(result));
    }
}

4.2 阻塞操作隔离

响应式红线：EventLoop 线程不能阻塞
  数据库/IO 操作必须异步或切调度器
  阻塞操作 → 丢到独立线程池（boundedElastic）
  否则阻塞整个 EventLoop → 所有连接受影响

// 阻塞操作切调度器（关键）
Mono.fromCallable(() -> jdbcTemplate.queryForObject(...))
    .subscribeOn(Schedulers.boundedElastic());  // 独立线程

4.3 游戏逻辑层使用注意

响应式 + 有状态逻辑的冲突：
  有状态玩家数据需要串行（Actor/分区）
  响应式并发模型是并行的 → 状态共享需谨慎

建议：
  网关层 → 响应式（无状态转发）
  逻辑层 → Actor/分区串行（有状态）
  响应式结果回写 → 需回到所属线程/Channel

---

五、实现要点

设计清单：
  网关层用 WebFlux（HTTP/短请求）
  长连接主通道用 Netty WS（分工明确）
  背压保护（有界缓冲/丢弃策略）
  EventLoop 线程不阻塞（异步/切调度器）
  逻辑层保持串行模型

工程注意：
  响应式链路要全程响应式（勿混入阻塞）
  超时控制（timeout 防止悬挂）
  错误处理（onErrorResume 兜底）
  监控（背压丢弃计数、队列长度）

常见坑：
  EventLoop 阻塞 → 全局卡顿
  背压策略误用 → 丢关键消息
  响应式与阻塞混用 → 线程池耗尽
  调试困难 → 日志 + 响应式调试钩子

与其他系统衔接：
  网关层 → 网关章节
  Netty EventLoop → 网络层章节
  线程模型 → 并发挑战章节
  队列削峰 → 消息队列章节