Sui 上的开发者现在可以利用 Sui grpc 流式传输功能，为实时区块链数据构建更快、更可靠的索引管道。
Sui区块链引入了gRPC 流式传输作为其索引基础设施的主要数据源，从而能够以极低的延迟实现实时检查点数据摄取。此外，这种设计旨在满足那些必须在数据最终确定后立即做出响应的应用需求。
该平台结合了流式传输功能和传统的轮询方法，以确保数据准确性和系统弹性。这种混合模型允许立即访问最终的检查点，同时保持与已部署在Sui上的现有自定义索引器的向后兼容性。
自定义索引框架为这种流式优先架构提供了基础，无需更改检查点处理逻辑。此外，团队仍然可以依赖现有的管道，并在能够带来切实好处的地方叠加流式处理功能。
新的 gRPC 流式传输功能从根本上改变了索引器在Sui上接收区块链数据的方式。现在，完整节点会在最终确定后立即将检查点数据直接推送给索引器，而无需等待预定的获取操作。
这种推送式模型消除了重复轮询周期，从而避免了以往在检查点创建和下游处理之间引入的延迟。因此，对延迟敏感的工具无需调整复杂的轮询间隔，即可实现更接近实时的响应。
根据文档，该系统能够“在检查点最终确定后立即提供实时数据”，并“提供更快的数据传输速度、更可靠的管道，减少在Sui服务器上的基础设施建设工作” 。尽管如此，运营商仍然可以配置安全措施，以防止连接问题和服务中断。
流式传输机制的运行方式非常简单，开发者只需添加一个指向完整节点端点的streaming-url参数即可。之后，索引器会以事件流的形式接收检查点，而不是按预定的时间间隔获取它们。
这种事件驱动模型对于监控系统、实时分析平台和其他对延迟敏感的应用尤为重要。此外，它还简化了基础设施，减少了对频繁轮询策略和相关运维调优的需求。
Sui 将流式传输与强制轮询的备用数据源相结合，以应对长连接固有的局限性。流式链路仅从建立之初开始传输数据，因此历史检查点仍然需要额外的机制。
通用索引器在生产环境中展示了这种混合设计。它以流式传输作为主要的数据摄取路径，同时保留轮询源作为历史数据和恢复场景的安全机制。
此配置可确保索引数据保持最新，同时支持干净重启和故障无缝恢复。但是，如果连接中断，系统可以使用轮询从上次已知的检查点恢复，并在链路稳定后恢复流式传输。
实际上，这种混合模式的功能类似于 SUI 检查点流式回退策略。开发人员既能获得推送更新的低延迟优势，又不会牺牲完整性或可靠性。
自定义索引框架将检查点处理与数据摄取分离。索引器通过统一的接口使用和转换检查点，而无需将逻辑耦合到特定数据源，例如 gRPC 流或 HTTP 轮询。
这种抽象方法允许团队根据需求变化调整数据摄取策略，而无需重写核心处理组件。此外，它将数据处理逻辑集中在一个层中，从而简化了代码库。
文档指出，使用 gRPC 流式传输， “无需轮询，无需猜测时间，也不会因获取间隔而引入人为延迟” 。也就是说，对于不需要超低延迟的工作负载，运维人员仍然可以选择轮询。
开发者可以根据具体的工作负载特性逐步启用 SUI gRPC 流式传输。那些优先考虑数据新鲜度和实时响应的应用，从立即采用流式传输中获益最大。
相比之下，专注于批量分析、离线处理或更简单工作流程的系统可以继续使用仅轮询配置。该框架在同一处理模型下支持这两种方法，从而简化了多应用环境。
基于官方框架构建的现有自定义索引器只需进行少量更改即可利用流式传输功能。添加 gRPC 功能需要在现有的remote-store-url配置值中添加streaming-url参数。
在此过渡期间，检查点处理逻辑保持不变。此外，该框架会在运行期间自动管理源切换，以确保索引器始终保持一致的网络状态视图。
这种设计有助于防止常见的故障模式，例如系统丢失数据或严重滞后于数据链。该框架协调流式传输和轮询之间的交互，从而在重启和网络中断后保持数据连续性。
总体而言，Sui 的混合流式和轮询架构为寻求低延迟摄取而不牺牲可靠性的索引器提供了实时检查点、弹性管道和清晰的迁移路径。