IMM支援多種資料輸出,其中有些處理時間會比較長,無法在一次同步請求中返回。因此IMM提供了一類API來非同步處理這種請求,這類API通常以CreateXXXTask
命名,同時提供了結果擷取的訊息通知方式。
IMM提供的非同步任務API適用於那些處理時間較長、無法在一次同步請求中返回的情境。通過非同步處理方式,可以避免阻塞主線程,提高系統效能,並在後台完成資料處理、計算量大的操作,或者定時任務,而不影響使用者體驗。
任務處理流程
開發人員上傳來源資料至阿里雲Object Storage Service。
開發人員調用IMM API介面
CreateXXXTask
發起非同步任務處理請求。IMM從開發人員指定的OSS地址擷取來源資料進行資料處理。
IMM將資料處理結果寫回開發人員指定的OSS地址。
IMM處理完資料後,將任務狀態發送至開發人員指定的MNS或RocketMQ。
MNS或RocketMQ將訊息推送至開發人員的服務中。
任務輸入輸出
輸入資料參數一般以Source命名,包括如下參數:
SourceURI:資料來源地址,目前僅支援OSS URI。
Sources:多個輸入URI地址數組。
Source:多個輸入URI對象。
輸出資料參數一般以Target命名,包括如下參數:
TargetURI:目標地址,該地址支援模板文法。
TargetURIPrefix:目標地址首碼。
Target:多個輸出URI對象。
輸入資料和輸出資料需要和IMM在同一個地區。
OSS URI
OSS URI是用來定位唯一的一個OSS資源,其格式為oss://<bucket>/<object>
,例如oss://test-bucket/test-object/test.docx
。
Bucket為和當前專案處於同一地區的OSS Bucket名稱,Object為包含副檔名的檔案完整路徑。
常見的錯誤輸入格式:
http://bucket.oss-cn-hangzhou.aliyuncs.com/test-object/test.docx
oss://bucket.oss-cn-hangzhou.aliyuncs.com/test-object/test.docx
TargetURI模板
TargetURI模板是在URI提供一些預留位置,使用時用實際的值去替換預留位置,從而動態產生實際的URI地址。例如oss://{bucket}/{tags.custom}/{dirname}/{barename}.{autoext}
。
關於TargetURI的更多資訊,請參見TargetURI 模板。
授權機制
非同步任務處理的輸入資料和輸出資料均為開發人員提供的地址,需要授權IMM服務輸入資料的讀許可權和輸出資料的寫入權限。這些許可權來自於ProjectName參數,在CreateProject - 建立專案介面中,通過參數ServiceRole指定了一個授權給IMM的服務角色(預設為AliyunIMMDefaultRole,開通服務時自動建立),IMM在非同步任務處理中會通過扮演這個服務角色擷取和上傳資料。
擷取任務狀態
通過MNS或RocketMQ擷取任務狀態
如任務處理流程中所述,開發人員可以通過設定MNS或RocketMQ來接收IMM的任務處理狀態,這也是IMM推薦的使用方式。MNS通知訊息格式請參見非同步通知訊息格式。
MNS或RocketMQ需要和IMM在同一個地區。
通過Notification參數指定MNS或RocketMQ配置接收非同步訊息通知(推薦)
MNS:通過Notification參數中的MNS參數指定MNS通知地址和主題接收非同步訊息通知。
{ "Notification": { "MNS": { "Endpoint": "MNS訊息通知地址", "TopicName": "MNS訊息通知主題" } } }
RocketMQ:通過Notification參數中的RocketMQ參數指定RocketMQ通知地址、主題和執行個體ID接收非同步訊息通知。
{ "Notification": { "RocketMQ": { "Endpoint": "RocketMQ訊息通知地址", "TopicName": "RocketMQ訊息通知主題", "InstanceId": "RocketMQ訊息通知執行個體Id" } } }
通過NotifyEndpoint和NotifyTopicName兩個參數指定MNS接收地址和主題接收非同步訊息通知
NotifyEndpoint:MNS訊息通知地址,預設為調用者的MNS地址。
NotifyTopicName:MNS訊息通知主題,為空白則不會發送訊息通知。
通過GetTask介面擷取任務狀態
IMM同樣也提供GetTask - 擷取任務資訊介面來查詢任務狀態。
通過輪詢GetTask - 擷取任務資訊直到任務完成同樣可以擷取到任務狀態,但這種方式的效率很低,在任務處理時間比較長的情境中,需要大量的GetTask - 擷取任務資訊調用,如果堆積的任務比較多,可能會觸發全域限流,影響其他介面的調用。此外,輪詢有時間間隔,而任務完成可能在間隔中的任意一個時間,平均需要延遲半個時間的時間間隔才能擷取到任務狀態。因此不建議在實際生產中使用該介面來擷取任務狀態。
任務開始執行後,任務資訊只儲存7天,超過7天則無法再擷取。
標籤機制
請求參數中的Tags參數提供了一種標籤機制,此參數可以在以下情境中使用:
開發人員可以設定自訂資料,這些資料會在MNS訊息中返回。
Tags可以作為搜尋任務的條件。
Tags可以作為變數在TargetURI中使用。