跳转到主要内容

​
介绍

在消费流式数据时，尽可能延长连接时长并完整接收所有匹配的数据是核心目标。这意味着要善用冗余连接、自动检测断线、快速重连，并制定丢失数据的恢复方案。 在本集成指南中，我们将讨论不同的恢复与冗余功能：冗余连接、回填和恢复。   冗余连接 冗余连接指允许你同时与筛选流建立多个并发连接。这样可通过让两个独立的消费者连接到同一条流，在两条连接上接收相同数据来实现冗余。因此，你的应用在多种情况下都具备热备切换能力，例如某条流断开或应用的主服务器发生故障。 目前，筛选流仅允许具有企业版访问权限的项目最多建立两条冗余连接。要使用冗余流，只需连接与你的主连接相同的 URL。你的流数据将通过两条连接同时发送。

​
断开连接后恢复遗漏的数据：回填

在检测到断开连接后，您的系统应能够智能地重新连接到流。如果可能，系统应记录断开持续时间，以便使用合适的恢复功能进行回填。 如果您使用的是具有企业版访问权限的 Project，并确认断开时间为五分钟或更短，则可以使用回填参数 backfill_minutes。将此参数与 GET /tweets/search/stream 请求一同传递时，您将收到过去一至五分钟内与您的规则匹配的 Post。我们通常会先投递这些较早的 Post，再投递任何新近匹配的 Post，同时不会对 Post 去重。这意味着如果您断开了 90 秒，但请求了两分钟的回填数据，您将收到 30 秒的重复 Post，您的系统应能容忍这一情况。以下是包含回填参数的请求示例： curl 'https://api.x.com/2/tweets/search/stream?backfill_minutes=5' -H "Authorization: Bearer $ACCESS_TOKEN" 如果您没有企业版访问权限，或者确认断开时间超过五分钟，则可以使用 recent search endpoint 或恢复功能来请求遗漏的数据。但请注意，搜索 Post 的端点不包含 sample:、bio:、bio_name: 或 bio_location: 运算符，并且在使用包含重音和变音符号的关键字与 #hashtag 运算符时，匹配行为存在一些差异。这些差异可能导致您无法完全恢复通过过滤流端点本应接收到的所有 Post。 断开连接后恢复遗漏的数据：恢复 如果您使用的是具有企业版访问权限的 Project，且无法在 5 分钟回填窗口内重新连接，则可以使用恢复功能在过去 24 小时内找回遗漏的数据。 流式恢复功能允许将回填窗口扩展至 24 小时。恢复使您能够“重放”遗漏数据的时间段。当您使用 ‘start_time’ 和 ‘end_time’ 请求参数发起连接请求时，将启动恢复流。连接后，恢复将按所指示的时间段重新流式传输，然后断开连接。 您可以同时向恢复发起 2 个并发请求，即“两个恢复作业”。从技术上讲，恢复的工作方式与回填相同，只是需要定义开始和结束时间。一次恢复对应单个时间范围。
名称类型描述
start_timedate (ISO 8601)YYYY-MM-DDTHH:mm:ssZ（ISO 8601/RFC 3339）。

UTC 时间，表示恢复的起始时间。
end_timedate (ISO 8601)YYYY-MM-DDTHH:mm:ssZ（ISO 8601/RFC 3339）。

UTC 时间，表示恢复的结束时间。
示例请求 URL：https://api.x.com/2/tweets/search/stream?start_time=2022-07-12T15:10:00Z&end_time=2022-07-12T15:20:00Z