Skip to main content
在本教程中,我们将说明统计信息版本控制的概念。有多种情况下,我们希望 拥有给定统计信息的不同版本。例如,如果一款游戏有赛季概念,那么它很可能会在 新赛季开始时重置统计信息。 我们继续沿用 创建基本统计信息中的示例。假设我们的射击游戏正变得非常流行。因此,引入了赛季概念。每个月,游戏都会 向所有玩家群体发布一个新主题赛季。因此,我们希望按赛季保存独立的统计数据。

创建用于版本控制的统计定义

在上一个示例中创建统计定义时,我们提到了 VersionConfiguration 参数对版本控制的重要性。在这里,我们详细介绍如何使用它以及它是如何工作的。
此示例与基本统计信息相比,主要区别在于 VersionConfiguration 参数。此参数允许我们定义 MaxQueryableVersions 设置,指定可以查询同一统计信息的多少个版本。在此案例中,我们将其设置为可查询 12 个版本。 ResetInterval 参数定义了重置流程发生的频率。此过程涉及创建一个与之前相同配置的统计信息, 但没有任何值,而版本参数按如下方式更改:N = N + 1,其中在创建统计定义时 N = 0。 例如,假设我们有一个版本参数等于 2 的统计信息,其带有给定值。现在 我们递增该统计信息的版本,那么结果将是一个新的统计信息,其版本参数等于 3,但没有任何值。 同时,之前的统计信息仍会保留在系统中以供查询。 ResetInterval 可以以多种方式工作。在本示例中它是按月的,但可以根据开发者的需要进行更改。在此特定 情况下,它意味着排行榜将从其配置那一刻开始每月自动重置。我们支持以下重置策略:
  • Day(日)
  • Hour(小时)
  • Manual(手动)
  • Month(月)
  • Week(周)
创建统计信息的 API 参考

递增统计信息的版本

通过这种新配置,我们可以针对不同赛季保存同一统计信息的多个版本。 但是,如果我们因为某个问题需要手动重置排行榜并重新开始赛季,会发生什么呢? 在这种情况下,我们可以使用 API 执行手动重置。以下是使用 SDK 的示例:
现在,我们已经准备好处理统计信息版本控制方面的任何挑战了。这里一个重要的方面是,我们决定作为版本保留的 统计定义数量将被计量,因为它们会占用服务中的存储空间。有关这方面的更多信息,请参见此处:

结论

在本教程中,我们学习了如何执行以下操作:
  • 使用正确的重置策略创建统计信息
  • 递增统计信息的版本

另请参阅

最后修改于 2026年8月25日