關于同步、異常處理的思考

2 評論 8614 瀏覽 51 收藏 8 分鐘

不同場景下,用戶的核心訴求是不一樣的。因此,在產品方案的設計中,當我們充分理解用戶的核心訴求,同、異步的處理方式,也就有了選擇。

案例引入:

公司的運營同事每個月都需要給大批量的指定用戶發送優惠券,數量以萬為單位。

這些指定的用戶因為沒有共性條件而無法在運營平臺直接篩選出來,只能將用戶數據整理成Excel表格,然后將表格內的數據批量導入到運營平臺中。

然而,運營平臺的批量導入發送目標數據的功能僅支持單次導入最多1000條,假設運營需要給15萬的指定用戶發送優惠券,意味著他需要在運營平臺批量導入分150次才能將所有發送目標導入完畢;

150次啊,運營同學,已瘋。

批量導入支持單次最多導入1000條,為什么不能是1萬,甚至是10萬條?

從批量導入功能的操作中,請求的發起與響應過程來看:

我們可以發現一點,用戶操作,前端會發起請求,要求后端即刻響應,并在“一定時間”內給出處理的結果。

這個“一定時間”是多長?

我再次向研發的同事們確認,目前運營平臺的架構設計,支持一個請求的最大響應時長為8秒。如果8秒內,批量導入的數據未能完成響應的處理,那么請求將響應超時,即刻返回處理失敗的結果。

這意味著,一批數據從上傳,到數據校驗(上傳數據需與數據庫的百萬條數據逐一對比,避免上傳了臟數據),到緩存在數據庫中,這一系列的操作必須在8秒內完成。

所以,為了保證這一切都能在“一定時間內”完成后正常返回給前端處理結果,單次批量導入的數據量只能限制在1000條左右。

如何才能將批量導入1000條的限制解開呢?

1. 同步處理方式

顯然,案例中批量導入的功能便是基于同步處理的邏輯進行設計的,用戶操作時,前端會發送請求,后端必須處理完請求的內容,才會返回給前端結果。

在后端響應請求期間,用戶如果關閉界面,處理就中斷了,這個過程中用戶只能被動的等待,如果請求的響應時間較長,用戶就容易產生茫然感,甚至焦慮,這樣的用戶體驗不夠友好。

因此,同步處理往往對應著響應超時的判斷機制,當請求的響應時間超出了設定的最大響應時長,即使請求并沒有被處理完,后端也會即刻返回一個處理結果(操作失敗等異常狀態),避免用戶長時間等待。

值得一提的是,當請求超時后,后端仍會繼續處理前端請求時導入的數據,但是能否正常處理完是不確定的,而且此時用戶也不再能知道他發起請求的實際處理結果了,因為在超時的那一刻,這個請求的處理結果已經被后端返回失敗而定性了。

不過,我們考慮用戶體驗的前提,是功能已經滿足了用戶的核心訴求(能夠更快的一次導入更多的數據量),因而批量導入這個功能,以同步處理的邏輯做處理就不太合適了。

2. 異步處理方式

什么是異步處理?當用戶在前端操作時,前端發送請求,后端收到請求后即刻給前端反饋“兄弟,你拜托的事兒我知道了,會進行處理,你該干嘛干嘛去吧”。

所以在后端處理請求的過程中,用戶通??梢躁P閉客戶端或退出當前頁面,去做其他的事情,無須在當前頁面等待,后端也就不必在一定時間內返回給前端處理結果。

沒有了“一定時間”的限制,1000條的限制問題自然迎刃而解。

事實上,采取異步處理邏輯設計的迭代方案,單次的批量導入數量可增加到5萬條,直接翻了50倍!

雖然異步處理的過程中,用戶發起請求后,即可退出當前頁面去做其他的事情,但用戶肯定是關注最終的結果的。因此,異步處理通常會搭配一個結果查詢功能:它可能是一個刷新當前頁的按鈕,也可能是一個查詢彈窗,便于用戶去查詢最后處理的結果,知曉請求的處理情況。

這樣,一個真實的,切合用戶使用場景的批量導入功能就完成了。

同步處理、異步處理這2種處理方式,從批量導入的案例來看,異步處理遠勝于同步處理。

但,異步處理總是優于同步處理嗎?

實際上,采用同步處理方式的產品方案也不在少數。

在我們常見的打車過程中,當到達目的地,司機會在app內滑動到達目的地,并確認附加費金額,然后司機端、乘客端APP便會自動展示出整段行程的費用,這個過程,便是采用同步處理的方式。

試想這個過程,采用異步處理的方式,這個場景會變成什么樣子?

司機到達了目的地,確認附加費金額后,需要通過刷新或點擊其他按鈕,才能獲取行程費用;乘客也需要通過刷新獲取到行程費用,然后才能去支付。

這樣的用戶操作流程,將導致大批量的乘客不會在第一時間去支付行程費用,直接影響了公司的壞賬率。

事實上,同步、異步的處理方式各有優劣,在合適的場景選擇對應的處理方式才能達到更好的效果。

同、異步處理方式在什么場景下采用更為合適呢?

從上述2個案例中,我們可以發現,不同場景下,用戶的核心訴求是不一樣的,對于批量導入,用戶更關注的是處理的性能,而行程費用的計算,用戶更關注的是結果的處理效率。

因此,在產品方案的設計中,當我們充分理解用戶的核心訴求,同、異步的處理方式,也就有了選擇。

 

作者:橙言,C端非資深產品經理,會一個人旅行,一個人吃火鍋,一個人看電影的一個懶人。學習交流可關注微信公眾號:橙言。

本文由 @橙言 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 文章名字寫錯了,異步寫成異常了

    來自廣東 回復
  2. 明白了,感謝?。?! ??

    來自北京 回復