Apache Spark 实时模式助力游戏实时会话化：更高效的亚秒级会话管理

在游戏行业，每一毫秒都至关重要。为了驱动游戏内个性化、为推荐引擎提供动力并做出动态内容调度决策，平台必须以亚秒级延迟处理全球数百万玩家的会话数据。

如今，满足这些超低延迟要求不再需要依赖多个引擎的割裂架构。在本文中，我们将探讨 Apache Spark Real-Time Mode 的实际应用。通过利用新的 transformWithState 操作符处理复杂的有状态逻辑，我们展示了 Spark 如何实现端到端的毫秒级性能。了解您的团队如何利用熟悉的 Structured Streaming 生态系统加速开发，构建关键的运营型应用。

用例概述

从游戏开始到游戏结束——为何会话追踪如此重要

对于游戏平台而言，了解哪些设备处于活跃状态以及活跃时长不仅仅是基础设施问题——它直接驱动业务。实时会话数据为个性化游戏体验提供支持，为推荐引擎提供动力，为内容调度决策提供依据，并在数百万台游戏主机和 PC 上提供设备健康信号。运维团队利用这些数据执行家长控制并检测异常会话模式。

会话事件基础

来自游戏主机和 PC 的会话事件流入 Kafka 主题。每个事件包含设备 ID 和会话 ID。设备 ID 用于标识主机或 PC；会话 ID 用于标识游戏会话。同一设备在任何时刻只能有一个会话处于活动状态。

该管道处理四种场景：

• 会话开始（GameStart）：开始事件到达。管道存储会话 ID 和开始时间，发出 SessionActive 事件，并注册一个 30 秒的处理时间定时器。如果该设备已有活动会话，会先结束旧会话。
• 会话心跳（Active）：定时器每 30 秒触发一次。管道计算 now - start_time，发出包含当前时长的 SessionActive 心跳，并重新注册定时器。
• 会话结束（GameEnd）：与活动会话匹配的结束事件到达。管道发出包含最终时长的 SessionEnd，并清除状态。
• 会话超时（GameSessionTimeout）：定时器触发且计算的时长超过可配置的最大值。管道不发出心跳，而是发出带有超时原因的 SessionEnd，并清理状态。

为何 Real-Time Mode 下的 Spark 是游戏变革者

微批模式下的 Spark Structured Streaming 可以处理有状态的会话化，但当用例要求输入处理和定时器驱动输出都达到亚秒级精度时，微批模式就力不从心了。过去，这一差距迫使团队转向管理额外的专用引擎或构建自定义解决方案。

使用 Apache Flink：可以实现状态管理和定时器，但采用 Flink 意味着要采用一个完全并行的生态系统：独立集群、状态后端、部署模型、监控堆栈和代码库，所有这些都与 Databricks 平台并存。结果是基础设施碎片化、运维复杂度提升，以及运营和人员配备第二个流引擎的成本。

使用自研方案：有些团队会构建自己的会话化服务——例如基于 Akka 的 actor 系统，每个设备都有一个 actor 来管理会话状态、定时器和心跳。这些方案与 Flink 面临相同的基础设施和运维负担，还多了一个挑战：它们不具备可扩展性。将数百万个有状态 actor 分布到节点上需要自行工程化。这些系统初期运行良好，但随着时间推移会陷入维护模式——运行稳定但难以扩展。

如今，Real-Time Mode 为用户填补了这一空白——在使用团队熟悉的 Spark API 的同时，提供亚秒级精度，并且仅需一个统一的引擎。

Real-Time Mode 与 transformWithState

transformWithState 是 Spark Structured Streaming 的下一代操作符，使复杂的有状态处理更加灵活和可扩展。其关键特性包括面向对象的状态管理、复合数据类型、定时器驱动逻辑、自动 TTL 支持和模式演进。与 Real-Time Mode 结合，它为输入处理和定时器驱动输出都提供了亚秒级精度。

游戏会话化用例需要两点：

• 响应式处理：在事件到达时处理会话开始和结束。
• 主动输出：按计划为每个活动会话生成心跳，与新数据是否到达无关。

transformWithState 通过一个 StatefulProcessor 类中的两个专用方法同时实现这两点。

handleInputRows() 响应传入的 Kafka 事件——处理会话开始和结束，随着事件到达维护会话化状态。

handleExpiredTimer() 处理事件之间的所有操作——触发以生成心跳和超时等主动输出，与是否收到新数据无关。

实现原理：构建实时游戏会话化管道

管道架构概览

• 事件摄入：来自控制台和 PC 的会话事件（开始和结束）到达 Kafka 主题。每个事件都会被解析，并从设备特定标识符中提取出 deviceId。
• 有状态分组：数据流按 deviceId 进行分组，确保给定设备的所有事件都路由到同一个有状态处理器实例。
• 处理：transformWithState 应用会话化处理器，该处理器使用以会话 ID 为键的 MapState 来跟踪每个设备的活动会话。当会话开始事件到达时，handleInputRows() 会存储会话状态，发出 SessionActive 事件，并注册第一个 30 秒定时器。从那时起，handleExpiredTimer() 接管——每隔 30 秒发出一次心跳并检查超时。当会话结束事件到达时，handleInputRows() 再次接手——发出包含最终时长的 SessionEnd，清除状态并停止定时器循环。
• 输出：处理后的会话事件（开始、心跳、结束和超时）以 JSON 格式写入输出 Kafka 主题，供下游消费。

实现深入解析

要详细了解架构、代码实现和生产考虑，请参阅这篇配套博客——其中我们逐步讲解 StatefulProcessor 代码、定时器生命周期、状态管理模式以及使用 StreamingQueryListener 进行监控。以下结果展示了管道的吞吐量和延迟特性，突出了微批处理模式（MBM）与实时模式（RTM）之间的显著延迟差异：

#### 吞吐量

为在真实负载下验证管道，我们进行了以下持续吞吐量测试：

指标（每分钟）值 输入事件（会话开始 + 结束）~500K 活动会话数量~4M 发出的心跳记录~8M 输入到输出的放大倍数~16x

绝大多数输出并非由传入数据触发——而是由 handleExpiredTimer() 完全按计划主动生成心跳。

#### 延迟

延迟为端到端测量——从 Kafka 输入主题时间戳到输出主题时间戳。使用实时模式，管道实现 432ms 的 p99 延迟——比微批处理模式快 20 倍。

结论

像游戏会话化这样的用例需要超越仅处理传入事件的管道——按计划主动发出心跳，跟踪数百万并发会话并高效管理状态。这种模式不仅限于游戏。任何需要定时器驱动输出的工作负载——IoT 心跳、会话跟踪、实时告警、设备监控——都可以用相同方式构建。

transformWithState 中的定时器使这一切成为可能。一个 StatefulProcessor 类即可处理整个会话生命周期——响应式输入处理和主动的定时器驱动输出。与实时模式配合，输入记录被处理且定时器以亚秒级精度触发——不是在下一个批处理间隔，而是在当下。这一切都在 Databricks 内完成，无需第二套引擎。

如果您已经在微批处理模式下运行 Structured Streaming 管道，并为了更低延迟而考虑引入第二套引擎，请先尝试实时模式。切换只需更改一个触发器——无需重写，无需迁移平台：

亲自试一试：

• 配套笔记本及数据生成器：运行完整的游戏会话化管道，并自行比较 MBM 与 RTM 的延迟。
• transformWithState API 指南：状态变量、定时器、TTL 和模式演进
• 实时模式参考：支持的算子、执行模式、数据源、接收器和语言支持

实时模式现已正式发布。