使用这些实践来组织和管理可靠、可扩展且可观察的数据，贯穿其生命周期。
组织您的数据
创建更少的数据存储
数据存储的行为类似于数据库中的表。使用一小组固定的数据存储，并通过键在其中组织记录。例如，将每个玩家的个人资料存储在一个 PlayerData 数据存储中，而不是为每个玩家创建一个数据存储。
每个玩家使用一个或少量键
当数据符合 4 MB 对象大小限制 时，将每个玩家的持久数据存储在一个键下。例如，在 PlayerData 数据存储中使用 User_123456 这样的键。此模式减少请求，使您能够原子性地更新相关值，并使回滚更易于推理。
如果玩家数据的不同部分具有不同的访问模式或接近每键大小或吞吐量限制，请将记录拆分为少量确定性键。将必须原子性更改的数据保留在同一个键中。
使用静态键模式和前缀
从稳定的标识符和静态模式构建键名，例如 User_{UserId}。不要使用显示名称或其他可能更改的值。静态模式使键在服务器和工具之间可预测。对于数据存储，它们还允许 自动化的被遗忘权处理 识别玩家数据。
使用 前缀 来分组相关键。例如，支持多个角色资料的体验可能使用 User_123456/Profile/Warrior 和 User_123456/Profile/Mage。然后，您可以将 User_123456/Profile 传递给 ListKeysAsync() 来列出该玩家的资料。
作用域 是细分数据存储的另一种方式。作用域在该数据存储实例中的每个键前添加一个字符串，默认值为 global。
评估数据存储模块
第三方数据存储模块始终是一个选项，在许多情况下，可能比从头构建系统更可取。在采用之前，请查看其所有权、维护状态和功能集。了解如何在没有模块的情况下访问和迁移您的数据。
DataStore2 是一个遗留的第三方库，您不应该在新的体验中使用它。如果您的体验当前使用 DataStore2，请使用 Roblox 的官方 beta DataStore2 迁移工具 从其每个玩家一个数据存储的模式迁移。
减少和分配请求
在内存中缓冲玩家数据
在会话开始时加载玩家的数据，并保持一个服务器本地副本以供游戏使用。更新本地副本，而不是为每个更改发送数据存储请求。定期保存它，当玩家离开时、服务器关闭时，以及在关键检查点（如购买处理）时保存。选择一个定期保存间隔，使其保持在您的请求限制内，并且短于任何会话锁定过期；玩家数据和购买示例 使用 180 秒。
错开重复请求
不要从每个服务器在相同的时间表上启动重复请求。在启动固定频率循环之前，为每个服务器或玩家分配一个随机的初始偏移量。对于不需要精确节奏的轮询或协调循环，在每个间隔中添加有界随机抖动。这些模式在时间上分配请求，减少同步流量峰值。
重试瞬态故障
将请求包装在 pcall() 中，并使用指数退避重试瞬态故障。为每个延迟添加随机抖动，以便服务器不会同时重试。限制延迟和尝试次数，并且不要重试由于无效请求或无法再提供有用结果的操作引起的错误。
按顺序处理每个键的数据存储重试。一个在较新请求成功后重试的旧请求可能会覆盖较新数据。还要考虑结果未知的写入：失败的调用意味着服务器没有收到成功的响应，但后端可能已完成写入。有关更多信息，请参见 数据存储错误代码和限制 和 重试。
优先使用 UpdateAsync 而不是 SetAsync
当写入依赖于当前值或多个服务器可能写入相同键时，优先使用 UpdateAsync()。UpdateAsync() 在写入之前将最新值读取到您的回调中，从而减少丢失更新的情况。SetAsync() 在未先读取的情况下覆盖键，如果两个服务器同时写入，可能会导致不一致。
在创建新键或替换不依赖于先前值的值时使用 SetAsync()。有关这两种方法的比较，请参见 Set 与 update。
分片热键
每个键都有 读取和写入吞吐量限制。如果一个逻辑记录在您减少不必要请求后持续达到这些限制，请将其分片到确定性键中。从标识符中选择一个稳定的分片，例如 User_{UserId}_Inventory_{ShardId}，以便每个服务器将相同的数据路由到相同的分片。
分片使维护一致性和执行未来迁移变得更加复杂。不要对适合一个键并保持在其吞吐量限制以下的数据进行分片。
构建操作工作流
结合使用可用工具：
- 观察。 使用 数据存储可观察性仪表板 跟踪请求、响应状态、吞吐量和存储。为重要的数据存储指标配置 自定义警报，以便您的团队能够对持续故障或意外增长做出响应。创作者中心通知还会让您知道存储接近或超过限制，并包括指导和仪表板链接。
- 有意扩展。 首先减少不必要的存储和请求。如果合法使用超过默认配额，请评估 扩展服务。
开放云和游戏服务器共享体验级请求预算。对操作性开放云脚本进行速率限制，以免干扰实时流量。
管理数据生命周期
使用数据存储版本，而不是为每个修订创建新键。只有键的最新版本计入存储使用情况，版本允许您检查或恢复早期值。
对于临时和快速变化的数据，使用 内存存储。内存存储数据会自动过期，不会增加持久数据存储的存储。
在测试结束时删除测试数据，并删除过期事件或退役功能的数据。在您标记数据存储以供删除后，有一个 30 天的缓冲期，在此期间您可以恢复它。在这 30 天之后，Roblox 会永久删除数据存储。有关更多信息，请参见 数据存储管理器。
设置被遗忘权处理
为遵循静态数据存储和键模式的玩家数据配置 自动化的被遗忘权 (RTBF) 处理。自动化 RTBF 是首选工作流，因为 Roblox 在处理符合条件的请求时会应用您的删除模板。
如果自动化 RTBF 不支持您的数据架构，请使用 被删除权网络钩子 运行自定义删除工作流。验证任一工作流是否删除所有匹配的玩家数据。