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

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

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

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

批量導入支持單次最多導入1000條，爲什麼不能是1萬，甚至是10萬條？

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

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

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

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

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

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

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

同步處理方式

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

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

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

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

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

異步處理方式

什麼是異步處理？當用戶在前端操作時，前端發送請求，後端收到請求後即刻給前端反饋“兄弟，你拜託的事兒我知道了，會進行處理，你該幹嘛幹嘛去吧”。

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

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

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

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

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

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

但，異步處理總是優於同步處理嗎？

實際上，採用同步處理方式的產品方案也不在少數；

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

試想這個過程，採用異步處理的方式，這個場景會變成什麼樣子？

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

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

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

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

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

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

相關文章