介绍
在消费流式数据时，尽可能延长连接时长并接收所有匹配的数据是基本目标。这意味着需要利用冗余连接、自动检测断线、快速重连，并制定丢失数据的恢复方案。 在本集成指南中，我们将讨论不同的恢复与冗余功能：冗余连接、回填和恢复。 冗余连接 冗余连接允许你同时与过滤的流建立多个连接。通过让你使用两个独立的消费者连接到同一 stream，并通过两条连接接收相同的 data，从而提供冗余。因此，你的应用在多种情况下都具备热备切换能力，例如当其中一个 stream 断开，或应用的主服务器发生故障时。 过滤的流目前仅允许具有 Enterprise 访问权限的 Project 最多建立两个冗余连接。要使用冗余的 stream，只需连接与你的主连接相同的 URL。你的 stream 的 data 将通过两条连接同时发送。断开连接后恢复遗漏数据：回填
检测到断开连接后，你的系统应能够自动重新连接到 stream。若可能，应记录断开持续时长，以便使用合适的恢复功能回填数据。 如果你使用具有 Enterprise 访问权限的 Project，并确认断开持续了五分钟或更短，可以使用回填参数 backfill_minutes。将此参数与 GET /tweets/search/stream 请求一起传递时，你将收到过去一到五分钟内与你的规则匹配的 Posts。通常我们会先交付这些较早的 Posts，再交付新匹配的 Posts，且不会对 Posts 进行去重。这意味着，如果你断开了 90 秒，但请求了两分钟的回填数据，你将收到 30 秒的重复 Posts，你的系统应能容忍这些重复。下面是一个携带回填参数的请求示例：curl 'https://api.x.com/2/tweets/search/stream?backfill_minutes=5' -H "Authorization: Bearer $ACCESS_TOKEN"
如果你没有 Enterprise 访问权限，或确认断开时间超过五分钟，可以使用 recent search endpoint 或恢复功能来请求遗漏的数据。但请注意，搜索 Posts 的 endpoints 不包含 sample:、bio:、bio_name: 或 bio_location: 操作符，并且在使用带重音与变音符号的关键字与 #hashtag 操作符时，匹配行为存在差异。这些差异可能导致你无法完全恢复通过 过滤的流 endpoints 本可接收的所有 Posts。
断开连接后恢复遗漏数据：Recovery
如果你使用具有 Enterprise 访问权限的 Project，当无法在 5 分钟回填窗口内重新连接时，可以使用 Recovery 功能在过去 24 小时内恢复遗漏的数据。
流式恢复功能允许你拥有 24 小时的扩展回填窗口。Recovery 使你能够“重放”遗漏数据的时间段。当你使用 ‘start_time’ 和 ‘end_time’ 请求参数发起连接请求时，将启动一个恢复 stream。连接后，Recovery 会重新传输所指定的时间段，然后断开连接。
你可以同时向恢复发起 2 个并发请求，即“两项恢复作业”。Recovery 在技术上与回填的工作方式相同，不同之处在于需要定义开始和结束时间。一次恢复周期对应单一的时间范围。
| 名称 | 类型 | 说明 |
| start_time | date (ISO 8601) | YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339)。 UTC 日期，表示要恢复的开始时间。 |
| end_time | date (ISO 8601) | YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339)。 UTC 日期，表示要恢复的结束时间。 |