不同場景下，使用者的核心訴求是不一樣的。因此，在產品方案的設計中，當我們充分理解使用者的核心訴求，同、非同步的處理方式，也就有了選擇。
案例引入：
公司的運營同事每個月都需要給大批次的指定使用者傳送優惠券，數量以萬為單位。
這些指定的使用者因為沒有共性條件而無法在運營平臺直接篩選出來，只能將使用者資料整理成Excel表格，然後將表格內的資料批次匯入到運營平臺中。
然而，運營平臺的批次匯入傳送目標資料的功能僅支援單次匯入最多1000條，假設運營需要給15萬的指定使用者傳送優惠券，意味著他需要在運營平臺批次匯入分150次才能將所有傳送目標匯入完畢；
150次啊，運營同學，已瘋。
批次匯入支援單次最多匯入1000條，為什麼不能是1萬，甚至是10萬條？
從批次匯入功能的操作中，請求的發起與響應過程來看：
我們可以發現一點，使用者操作，前端會發起請求，要求後端即刻響應，並在“一定時間”內給出處理的結果。
這個“一定時間”是多長？
我再次向研發的同事們確認，目前運營平臺的架構設計，支援一個請求的最大響應時長為8秒。如果8秒內，批次匯入的資料未能完成響應的處理，那麼請求將響應超時，即刻返回處理失敗的結果。
這意味著，一批資料從上傳，到資料校驗（上傳資料需與資料庫的百萬條資料逐一對比，避免上傳了髒資料），到快取在資料庫中，這一系列的操作必須在8秒內完成。
所以，為了保證這一切都能在“一定時間內”完成後正常返回給前端處理結果，單次批次匯入的資料量只能限制在1000條左右。
如何才能將批次匯入1000條的限制解開呢？
1。 同步處理方式
顯然，案例中批次匯入的功能便是基於同步處理的邏輯進行設計的，使用者操作時，
前端會發送請求，後端必須處理完請求的內容，才會返回給前端結果。
在後端響應請求期間，使用者如果關閉介面，處理就中斷了，這個過程中使用者只能被動的等待，如果請求的響應時間較長，使用者就容易產生茫然感，甚至焦慮，這樣的使用者體驗不夠友好。
因此，同步處理往往對應著響應超時的判斷機制，當請求的響應時間超出了設定的最大響應時長，即使請求並沒有被處理完，後端也會即刻返回一個處理結果（操作失敗等異常狀態），避免使用者長時間等待。
值得一提的是，當請求超時後，後端仍會繼續處理前端請求時匯入的資料，但是能否正常處理完是不確定的，而且此時使用者也不再能知道他發起請求的實際處理結果了，因為在超時的那一刻，這個請求的處理結果已經被後端返回失敗而定性了。
不過，我們考慮使用者體驗的前提，是功能已經滿足了使用者的核心訴求（能夠更快的一次匯入更多的資料量），因而批次匯入這個功能，以同步處理的邏輯做處理就不太合適了。
2。 非同步處理方式
什麼是非同步處理？當用戶在前端操作時，
前端傳送請求，後端收到請求後即刻給前端反饋“兄弟，你拜託的事兒我知道了，會進行處理，你該幹嘛幹嘛去吧”。
所以在後端處理請求的過程中，使用者通常可以關閉客戶端或退出當前頁面，去做其他的事情，無須在當前頁面等待，後端也就不必在一定時間內返回給前端處理結果。
沒有了“一定時間”的限制，1000條的限制問題自然迎刃而解。
事實上，採取非同步處理邏輯設計的迭代方案，單次的批次匯入數量可增加到5萬條，直接翻了50倍！
雖然非同步處理的過程中，使用者發起請求後，即可退出當前頁面去做其他的事情，但使用者肯定是關注最終的結果的。因此，非同步處理通常會搭配一個結果查詢功能：它可能是一個重新整理當前頁的按鈕，也可能是一個查詢彈窗，便於使用者去查詢最後處理的結果，知曉請求的處理情況。
這樣，一個真實的，切合使用者使用場景的批次匯入功能就完成了。
同步處理、非同步處理這2種處理方式，從批次匯入的案例來看，非同步處理遠勝於同步處理。
但，非同步處理總是優於同步處理嗎？
實際上，採用同步處理方式的產品方案也不在少數。
在我們常見的打車過程中，當到達目的地，司機會在app內滑動到達目的地，並確認附加費金額，然後司機端、乘客端APP便會自動展示出整段行程的費用，這個過程，便是採用同步處理的方式。
試想這個過程，採用非同步處理的方式，這個場景會變成什麼樣子？
司機到達了目的地，確認附加費金額後，需要透過重新整理或點選其他按鈕，才能獲取行程費用；乘客也需要透過重新整理獲取到行程費用，然後才能去支付。
這樣的使用者操作流程，將導致大批次的乘客不會在第一時間去支付行程費用，直接影響了公司的壞賬率。
事實上，同步、非同步的處理方式各有優劣，在合適的場景選擇對應的處理方式才能達到更好的效果。
同、非同步處理方式在什麼場景下采用更為合適呢？
從上述2個案例中，我們可以發現，不同場景下，使用者的核心訴求是不一樣的，對於批次匯入，使用者更關注的是處理的效能，而行程費用的計算，使用者更關注的是結果的處理效率。
因此，在產品方案的設計中，當我們充分理解使用者的核心訴求，同、非同步的處理方式，也就有了選擇。
