有關目前執行 Streaming 服務的區域清單,請參閱說明文件。
OCI Streaming 提供從基礎架構到佈建、部署、維護、安全性修補程式、複寫和使用者群組的完整代管服務,讓應用程式開發變得更容易。
在 OCI Streaming 中建立串流時,Oracle 會自動建立和管理分布在 3 個不同可用性網域 (或單一可用性網域區域的故障網域) 中的 3 個串流節點,進而確保串流具有高可用性,且資料具有高度持久性。
透過 OCI Streaming,您可以幾近即時地發送和擷取資料。從傳訊到複雜的資料串流處理,使用情境數量幾乎無上限。
以下是部分 Streaming 的眾多可能用途:
您可以透過以下方式開始使用 OCI Streaming:
總體而言,您可以存取的輸送量無上限。您只需要主動設計串流並搭配正確數量的分割區。
串流系統的固定限制包含:
在我們的 API 中,分割區以字串表示。
如果建立具有五個分割區的串流,則可以使用字串「0」、「1」、「2」、「3」或「4」來進行存取。
請勿依賴分割區識別碼會以數值表示。
位移並不密集。預期會看到訊息位移量總是在增加,但有時不會增加 1。請勿依此來進行將來的位移量計算。
例如:如果在同一分割區上發布兩則訊息,第一則訊息的位移可能為 42,而第二則訊息的位移則可能為 45 (不存在偏移 43 和 44。
串流可視為包含訊息的僅附加記錄檔案。
串流被劃分為多個分割區,以實現延展性。透過分割區,您可以將訊息拆分到多個節點 (或代理) 上,以分配串流。每個分割區可放置在單獨的機器上,以便多個使用者同時讀取主題。
您發送到主題的內容是 64 位元編碼訊息。
分割區中的每個訊息都有一個識別碼,稱為其位移。使用者可以從一個特定的位移開始讀取訊息,亦可以從他們選擇的任何位移點進行讀取。使用者還可以提交最新處理的位移,以便在停止工作,然後重新啟動時,可以接續工作,不會重播或遺失訊息。
金鑰是用於對相關訊息進行分組的識別碼。
您可以使用我們的 Console 或 API 建立新串流。請參閱此處的 API。
您的串流是針對特定區域和租戶建立,也可以選擇針對專用區間建立。串流的資料可在整個區域內複寫,在可用性網域遺失或網路分離時不會中斷服務,並在一個區域內提供內建高可用性。
佈建時間取決於分割區數量。建立新分割區最多需要 10 秒鐘。
串流的分割區數量取決於應用程式的預期輸送量 (預期輸送量 = 平均記錄大小 x 每秒寫入的最多記錄數)。
Oracle Cloud Infrastructure 串流的輸送量由分割區定義。分割區提供每秒 1MB 的資料輸入和每秒 2MB 的資料輸出。
每秒可向分割區發送 1,000 個請求。
Streaming SDK 將支援與其他 OCI SDK 實作相同的語言,不會提供 特別支援 Streaming 服務的其他語言。
建立串流並啟用後,您便可以發布訊息。針對發布,您可以使用寫入 API (putMessages)。訊息將發布到串流中的分割區。如果有多個分割區,則會使用訊息的索引鍵來計算將要發布訊息的分割區。
如果索引鍵為 Null,則將使用值的子集計算分割區。針對具有 Null 索引鍵的訊息,具有相同值的訊息可能不會在同一分割區上,因為分割區配置可能會有所改變;傳送 Null 索引鍵將有效地將訊息放在隨機分割區中。
如果要確保具有相同值的訊息進入相同的分割區,則應對這些訊息使用相同的索引鍵。
一旦 OCI Streaming API 確認您的 putMessage 沒有錯誤,訊息便會持久。
guaranteesOCI Streaming 線性讀取和寫入分割鍵。
當用戶端請求超出限制時,OCI Streaming 會拒絕請求並發出錯誤例外狀況訊息。
當您超過以下臨界值時,節流機制便會啟動:
我們建議訊息批次處理的原因如下:
一批訊息的大小不應超過 1 MB。如果超出此限制,則會觸發節流機制。
您可以使用下列其中一種方法:透過 Object Storage 區塊化或發送訊息。
大型裝載內容可以分成 Streaming 服務可以接受的多個較小區塊。
區塊以與儲存普通 (非區塊化) 訊息相同的方式儲存在服務中。唯一的區別是,使用者必須保留這些區塊,並在收集完所有區塊後將它們組合為真實訊息。
分割區中的區塊可以與普通訊息交互編排。
大型裝載內容會放在 Object Storage 中,並且僅會傳輸指向該資料的指標。接收器識別出這種類型的指標裝載內容,以透明的方式從 Object Storage 中讀取資料,並將其提供給終端使用者。
一個常見的錯誤是提供錯誤的日期格式。
Streaming 服務支援 ISO-8601,包含所有日期的時區。
PutMessagesResultsEntry 類別提供以下方法:
目前,如果您未發布訊息,則無法查看最新發布的訊息。
有一種機制可以查看每個群組或分割區最新提交的位移。研究 getGroup 端點。
如欲使用訊息,您需要:
有關使用串流中資料的逐步指南,請參閱技術說明文件。
OCI Streaming 提供兩種使用 API 的方式:
可以將使用者配置為群組的一部分,以便使用訊息。串流分割區在群組成員之間分佈,因此來自任何單一分割區的訊息將僅發送到單一使用者。
當使用者加入或離開群組時,將重新平衡分割區指派。
我們建議您透過使用者應用程式處理重複訊息。
如果您想知道使用者是否訊息落後 (製作速度比使用速度快),則可以使用訊息時間戳和目前時間之間的差值。如果差值增加,您可能要建置一個新的使用者來接管第一個使用者的某些分割區。
單一使用者是從一個或多個串流中讀取訊息的實體。
該實體可以單獨存在,也可以屬於某個使用者群組。
指向串流中某個位置的指標。該位置可以是指向分割區中特定位移或時間,或群組目前位置的指標。
您可以使用下列游標類型:TRIM_HORIZON、AT_OFFSET、AFTER_OFFSET、AT_TIME 和 LATEST。有關詳細資訊,請參閱說明文件。
不需要,游標應該在迴圈之外建立。建立游標後,您可以使用 GetMessages 方法開始使用訊息。每次對 GetMessages 的呼叫都會傳回要在下一個 GetMessages 呼叫中使用的游標。
傳回的游標不是 Null,將在 5 分鐘後到期。只要繼續使用,您永遠不必重新建立游標。
GetMessages、Commit 和 Heartbeat 皆會傳回一個新游標,用於後續呼叫。
有關 Java 程式碼片段,請參閱說明文件。
在幾種錯誤的情況下,有必要建立新游標。我們建議您將此情形納入故障策略進行處理。
可以。請參閱原則。租戶 A 必須建立一個原則,給予租戶 B 串流提取存取權
當您不使用群組游標時,必須由使用者管理儲存的位移。
當您使用使用者群組時,可以在發生故障的情況下提交已處理的位移。
建立游標時,請指定欲使用的游標類型。當應用程式開始使用訊息時,需要儲存達成/停止的位移。
當進行演示或概念驗證時,每個串流僅使用一個分割區,這種情形很實用。在具有多個分割區的生產環境中,我們建議您使用使用者群組。
GetMessageRequest 類別的 getLimit( ) 方法會傳回最多訊息數。您最多可以指定 10,000 則訊息。依預設,此服務會傳回盡可能多的訊息。
請考量您的平均訊息大小,以避免超出串流的輸送量。
串流服務 getMessage 批次處理大小視發布到特定串流的平均訊息大小而定。
有關詳細說明,請參閱說明文件。
使用者群組提供以下優勢:
執行個體是使用者群組的成員。執行個體是在建立群組游標時定義的。
使用者群組中執行個體之間的分割區讀取是互相平衡的。
執行個體名稱會識別群組中與位移管理操作相關的成員。
我們建議您為使用者群組的每個成員使用唯一的執行個體名稱。
最佳做法是使用一系列實用的資訊。
Streaming 服務的以下元件具有逾時:
使用者群組中的每個執行個體皆需要在 30 秒逾時之前產生活動訊號。例如:如果訊息處理時間太長,我們建議執行個體發送活動訊號。
達到 30 秒逾時的時候,執行個體將從使用者群組中移除,且其分割區將重新指派給另一個執行個體 (如果可能)。此操作稱為重新平衡。
重新平衡是一個過程,其中一組執行個體 (屬於同一個使用者群組) 進行協調,以擁有屬於特定串流的一組互斥分割區。
使用者群組成功完成重新平衡操作時,串流中的每個分割區均由群組中的單一或多個使用者執行個體擁有。
為了確保分布均勻,您需要為訊息索引鍵建立一個好的值。為此,請考量串流資料的選擇性和基數。
實現高基數和低選擇性。
在 Streaming 服務中,索引鍵進行雜湊後,會用於確定分割區。具有相同索引鍵的訊息將進入同一個分割區。具有不同索引鍵的訊息可能會傳到不同或相同的分割區。
身為製作者,您無法明確控制訊息進入的分割區。
如果使用索引鍵發送資料,則製作者無法將訊息強制傳到特定分割區。
可以,StreamClient 為安全執行緒。
當一個物件無狀態時,在調用之間不必保留任何資料。因為沒有狀態可以修改,所以一個執行緒不會影響另一個調用物件操作的執行緒結果。因此,無狀態類別在本質上是安全執行緒。
使用者延遲尚未實作在 Streaming 服務中。
每個成功的 putMessage 呼叫後,將傳回每個訊息產生的位移。
訊息位移包含在 getMessage 呼叫傳回的每則訊息中。
您可以按分割區追蹤產生的位移與使用的位移之間的差異,以確定延遲。
如欲確定您的使用者是否訊息落後 (製作速度快於使用速度),您可以使用訊息的時間戳。如果使用者落後,請考慮建置一個新使用者來接管第一個使用者的某些分割區。如果在單一分割區上落後,則無法復原。
請考慮下列選項:
如果您想知道在特定分割區中還有多少訊息要使用,請使用類型的游標,取得下一個最新發布訊息的位移,並以目前使用的位移來計算差異。
因為我們沒有密集的位移,所以您會得到一個。然而,如果您的製作者停止製作,則您將無法僅憑粗略估計獲取該資訊 (因為您將永遠無法獲得下一則已發布訊息的位移)。
重新指派僅會在提交和逾時時發生。如果 commitOnGet=trueprocessing 花費的時間超過 30 秒,我們建議您使用並依賴活動訊號。
編寫自訂提交邏輯非常複雜,且涉及各種競爭條件和注意事項。在許多情況下,某些內部狀態會發生變化,需要由用戶端來處理這種情況。
可以,StreamClient 為安全執行緒。
如果使用者群組的執行個體在超過 30 秒內未發送活動訊號,或者該過程終止,則視執行個體為停止活動。
發生這種情況時,使用者群組內將發生重新平衡,以處理先前由停止活動的執行個體使用的分割區。
這類執行個體視為新的執行個體。將觸發重新平衡,並為執行個體指派一個分割區,以開始使用訊息。
Streaming 服務不保證會將相同的分割區 (終止之前指派的分割區) 重新指派給這類執行個體。
Streaming 服務透過使用者群組提供「至少一次」的語意。請考量何時在訊息迴圈中提交位移。如果使用者在提交一批訊息之前終止,則該批次將可能分配給另一個使用者。當分割區分配給另一個使用者時,該使用者會用最新提交的位移,以開始使用。使用者在提交的位移之前未收到訓息。
當 getCommitOnGet 設定為 true 時,Streaming 服務將自動為使用者群組處理位移提交。
我們建議您使用此方法,以降低應用程式的複雜性;亦即,應用程式不應實作任何提交機制。
如欲覆寫此設定並實作自訂位移提交機制,請在建立使用者群組時,將 getCommitOnGetto 設定為 false。
CommitOnGet 代表的是提交上一個請求的位移。為了說明此功能,請考慮以下範例:
針對使用者 A:
協調作業系統啟動新的使用者 B:
在此範例中,沒有訊息遺失,但是位移 101 - 115 至少處理了一次,這說明位移可能已被處理了多次。
在此範例中,訊息的一部分 (15) 可能已被處理,且可能在 Bevent 故障之後重新交付給新的使用者,但是沒有遺失資料。
目前,無法更新使用者群組中的單一分割區。
updateGroup 呼叫的目前表示方式是為所有分割區重設 committedOffset,將不必要的舊訊息擷取指派給其他正常使用者的分割區。
在使用者群組中,正在使用訊息的執行個體需要在達到 30 秒逾時之前發送活動訊號。如果執行個體無法發送活動訊號,則 Streaming 服務會將執行個體視為停止活動,並觸發其分割區的重新指派作業。
從已提交的呼叫中擷取的游標應該沒有位移。活動訊號會延長游標中分割區的逾時。
對空游標產生活動訊號不具任何效用。先前提交的游標可能會觸發重新平衡。
如果提交了一個游標,接著對該游標產生活動訊號 (而非自提交呼叫中傳回),則將更新所包含位移的逾時。
如欲從故障中復原,您必須儲存 (針對每個分割區) 最後處理訊息的位移,以便在需要重新啟動使用者時可以從該訊息開始使用。
請注意:請勿儲存游標,因為游標會在 5 分鐘後到期。
針對儲存最後處理訊息的位移,我們未提供任何指引,所以您可以使用任何方法 (例如:另一個串流、Kiev、機器上的檔案或 Object Storage)。
當您的使用者重新啟動時,請閱讀您處理的最後一則訊息的位移,接著建立一個游標,類型為 AFTER_OFFSET,指定您剛剛獲得的位移。
我們建議客戶配置的分割區略高於其最大輸送量。這將幫助他們管理應用程式暴增。一旦建立串流後,我們目前不支援更改分割區數量。
依預設,我們儲存資料達 24 小時。建立串流時,您最多可以設定 7 天的保留期間。保留期間一經定義,便無法進行編輯。
OCI Streaming 主控台提供操作和效能指標,例如:資料輸入和輸出的輸送量。OCI Streaming 還與 OCI Telemetry 整合,以便您收集、查看和分析串流的遙測指標。
同一租戶中的所有串流都具有唯一的固定名稱。每個串流皆指派一個區間。因此,Oracle Cloud Infrastructure 存取控制原則的所有功能皆可以用於描述租戶、區間或單一串流層級的精細規則。
存取原則以「允許在何處」的形式指定。
我們的網際網路 API 使用 Oracle Identity 服務。透過 Oracle Identity Service,您可以輕鬆驗證使用者身分,並授權從瀏覽器 (使用者名稱/密碼) 和程式碼 (API 金鑰) 對此類 API 進行存取。
請參閱此處的說明文件。
依預設,OCI Streaming 處於安全狀態 - 靜態和動態使用者資料均已加密。只有帳戶和資料流所有者可以存取他們建立的串流資源。OCI Streaming 支援使用者驗證,以控制對資料的存取。您可以使用 Oracle Cloud Infrastructure IAM 原則,選擇性地對使用者和使用者群組授予權限。您可以使用 HTTPS 通訊協定透過 SSL 端點從 OCI Streaming 安全地放置和取得資料。
您擁有自己發送的資料;您可以在將資料發送到 OSS 之前對其進行加密。
擷取 (您的製作者 - Streaming 閘道):由於 SSL (HTTPS) 而動態加密的資料。
串流服務內:SSL 在閘道上終止,資料在抵達時即已使用每個串流 AES-128 金鑰加密,接著傳送到儲存層,以維持持續性。
關於使用:加密的資料從 OSS 中讀取,由閘道節點解密,接著透過 SSL 發送給使用者。
關於使用:加密的資料從 OCI Streaming 中讀取,由閘道節點解密,接著透過 SSL 發送給使用者。
OCI Streaming 使用 AES-GCM 128 演算法進行加密。
串流與 OCI Monitoring 服務完全整合。請到這裡參閱 Streaming 指標說明。
Streaming 服務中的監控著重於製作者和使用者。有關 Streaming 服務發出的指標清單,請參閱說明文件。
Console 中可用的每個指標均提供下列統計資料:
這些統計資料提供四個時間間隔
針對製作者,請考慮根據下列指標設定警報:
對於使用者,請考慮根據下列指標設定相同的警報:
觸發警報後,負責的團隊成員需要調查警報並評估情況。
如果問題與用戶端 (製作者或使用者) 有關,則團隊成員需要解決該問題或與開發團隊進行進一步調查。
如果問題與伺服器有關,則團隊成員應聯絡 Streaming 服務支援。
狀況良好的串流指的是活動中的串流:訊息已成功接收且成功使用。
寫入服務是持久的。如果您可以製作自己的串流,並且獲得成功的回應,那麼串流便是狀況良好的。
擷取資料後,使用者可以在配置的保留期間內對其進行存取。
如果 Get Messages API 呼叫傳回更高層級的內部伺服器錯誤,則該服務的狀況不良好。
狀況良好的串流也具有正常的指標:
有關 API 錯誤的詳細資訊,請參閱說明文件。
Streaming 服務支援每個分割區由於節流而導致的部分失敗。在部分失敗的情況下,服務將傳回 200 狀態程式碼,並在回應裝載內容中指示失敗。
如果整個請求經過節流,您將獲得 429 狀態程式碼。
請與 Oracle Streaming Service 聯絡,以增加您的租戶限制。
OCI Streaming 使用簡單的隨用隨付定價。沒有預付費用或最低費用,您僅需為使用的資源付費。
有關 OCI Streaming 的實際定價,請參閱定價指南。
試想一個情境,資料製作者每秒總共放置 500 條記錄,每條記錄為 2kB。客戶希望以輸入的兩倍速率輸出/擷取資料。客戶還希望儲存該資料 7 天。
每日價格計算 (僅供參考)
每個記錄大小 = 4kB (小於 4kB 的任何記錄將四捨五入為 4kB)
自選項:
OCI Streaming 沒有免費層。