存储 rrweb 事件数据

rrweb 发出有序的事件流。库本身不会替你选择数据库、上传传输方式、保留策略或访问控制模型；这些存储与交付决策由你的应用负责。

保持事件顺序

存储每个事件时带上它的 rrweb 时间戳，并保持录制器发出事件的顺序。时间戳驱动回放时机，而当多个事件共享同一时间戳或批次乱序到达时，稳定的序列号会很有用。不要只按上传时间排序。

分批上传且不丢失事件

批量发送可以减少请求开销，但失败的批次必须在不丢失事件的情况下重试。为批次或单个事件提供稳定标识符，以便接收方让重试幂等。重试应该是无损的：重复接受同一批次不得产生重复事件，并且确认一个批次必须意味着它已被持久存储。

从最小的存储结构开始

使用能让接收方保持顺序并识别重试的信封格式发送批次：

type EventBatch = {
  recordingId: string;
  batchId: string;
  sequenceStart: number;
  events: unknown[];
};

在服务器端，将 recordingId、batchId、sequenceStart 和事件载荷存储在一个持久事务中。在 (recordingId, batchId) 上添加唯一约束，仅在事务提交后才确认，并在同一批次重试时返回已有的确认。按 sequenceStart 加载批次，然后直接拼接其中的事件，而不要在批次内部重新排序。

这是传输与持久化契约，而不是完整的生产级 schema。你的应用仍然需要经过身份验证的写入与读取、请求大小限制、压缩、配额、保留任务，以及覆盖载荷、索引和备份的删除。

保留完整快照

回放不能仅从增量事件开始；每个可回放片段都需要开启它的那个完整快照。

如果将长录制拆分为多个片段，请记录每个可回放片段由哪个完整快照开始。回放器的检查点（checkout）同样依赖于在所请求时间点之前存在合适的完整快照，因此独立地删除或换出快照可能使后续事件无法使用。

压缩录制

压缩整个会话的载荷通常比单独压缩每个事件获得更好的压缩率，因为压缩器可以跨录制复用模式。当事件需要保持可单独寻址时，rrweb 的逐事件打包器很有用，但它不能替代传输压缩或整会话压缩。请参阅库的权威配方优化存储。

规划保留与删除

根据数据的用途和隐私要求定义保留策略，然后一起删除过期的录制以及相关的索引、元数据、快照和备份。对存储的事件和检索端点应用相同的访问控制模型，并使用户请求的删除可审计，从而让录制无法从被遗忘的副本中重建。

加载录制以供回放

按原始顺序返回事件，包括初始化所请求范围所需的完整快照。

检索是回放问题，而不仅仅是存储查询。同时要在新数据到达时保持分页边界稳定。分页配方介绍如何向正在运行的回放器追加后续事件批次。

改用 rrweb Cloud

当你不想自行设计和运维摄取、存储、保留、访问控制和回放交付时，rrweb Cloud 是托管的替代方案。