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 的混合流式和輪詢架構爲尋求低延遲攝取而不犧牲可靠性的索引器提供了即時檢查點、彈性管道和清晰的遷移路徑。