問題描述

以 文件重命名 為例:

當完成重命名操作提交會到這個地址 https://pan.baidu.com/api/filemanager

返回如下結果

{ 'errno': 0, 'info': [], 'request_id': 88137407060055336, 'taskid': 307843054247316}

可以聯想到在server端建立了一個task, 并返回了taskid讓客戶端后續取狀態來更新ui

客戶端輪訓服務器的接口 https://pan.baidu.com/share/taskquery 來獲取狀態, 1秒一次請求, 服務器端返回結果如下: 分幾種情況我總結了一下

#進行中的返回值{ 'errno': 0, 'request_id': 88137707954758994, 'task_errno': 0, 'status': 'pending'}#進行中{ 'errno': 0, 'request_id': 88137707954758994, 'task_errno': 0, 'status': 'running'}#操作成功的返回值{ 'errno': 0, 'request_id': 88138584419582326, 'task_errno': 0, 'status': 'success', 'list': [ { 'from': '/test1/我的照片', 'to': '/test1/我的照片2' } ], 'total': 1}

當 status 為success時候, 則輪詢結束, 更新UI元素

問題: 直接訪問重命名接口不行嗎? 為什么要這么設計, 好處是什么?

問題解答

你已經說的很清楚了啊，還有什么不明白的？

第一次就是向服務器發起改名申請。服務器就開始任務。后面的輪詢都是在查詢任務是否完成，完成了前端做相應操作，萬一失敗了，前端還要做回滾操作。

猜一下原因:極端情況下, 操作可能會耗時很久, 無法立即返回. 在操作完成的時候, socket鏈接可能已經斷開, 無法獲取到最終的結果. 設計成任務隊列的方式, 能保證客戶端獲取到最終的結果.

除了上面的一些考慮，可能還有一個很重要的原因，那就是并發壓力。做成異步，能很好解決并發