不同場(chǎng)景下，用戶(hù)的核心訴求是不一樣的。因此，在產(chǎn)品方案的設(shè)計(jì)中，當(dāng)我們充分理解用戶(hù)的核心訴求，同、異步的處理方式，也就有了選擇。

案例引入：

公司的運(yùn)營(yíng)同事每個(gè)月都需要給大批量的指定用戶(hù)發(fā)送優(yōu)惠券，數(shù)量以萬(wàn)為單位。

這些指定的用戶(hù)因?yàn)闆](méi)有共性條件而無(wú)法在運(yùn)營(yíng)平臺(tái)直接篩選出來(lái)，只能將用戶(hù)數(shù)據(jù)整理成Excel表格，然后將表格內(nèi)的數(shù)據(jù)批量導(dǎo)入到運(yùn)營(yíng)平臺(tái)中。

然而，運(yùn)營(yíng)平臺(tái)的批量導(dǎo)入發(fā)送目標(biāo)數(shù)據(jù)的功能僅支持單次導(dǎo)入最多1000條，假設(shè)運(yùn)營(yíng)需要給15萬(wàn)的指定用戶(hù)發(fā)送優(yōu)惠券，意味著他需要在運(yùn)營(yíng)平臺(tái)批量導(dǎo)入分150次才能將所有發(fā)送目標(biāo)導(dǎo)入完畢；

150次啊，運(yùn)營(yíng)同學(xué)，已瘋。

批量導(dǎo)入支持單次最多導(dǎo)入1000條，為什么不能是1萬(wàn)，甚至是10萬(wàn)條？

從批量導(dǎo)入功能的操作中，請(qǐng)求的發(fā)起與響應(yīng)過(guò)程來(lái)看：

我們可以發(fā)現(xiàn)一點(diǎn)，用戶(hù)操作，前端會(huì)發(fā)起請(qǐng)求，要求后端即刻響應(yīng)，并在“一定時(shí)間”內(nèi)給出處理的結(jié)果。

這個(gè)“一定時(shí)間”是多長(zhǎng)？

我再次向研發(fā)的同事們確認(rèn)，目前運(yùn)營(yíng)平臺(tái)的架構(gòu)設(shè)計(jì)，支持一個(gè)請(qǐng)求的最大響應(yīng)時(shí)長(zhǎng)為8秒。如果8秒內(nèi)，批量導(dǎo)入的數(shù)據(jù)未能完成響應(yīng)的處理，那么請(qǐng)求將響應(yīng)超時(shí)，即刻返回處理失敗的結(jié)果。

這意味著，一批數(shù)據(jù)從上傳，到數(shù)據(jù)校驗(yàn)（上傳數(shù)據(jù)需與數(shù)據(jù)庫(kù)的百萬(wàn)條數(shù)據(jù)逐一對(duì)比，避免上傳了臟數(shù)據(jù)），到緩存在數(shù)據(jù)庫(kù)中，這一系列的操作必須在8秒內(nèi)完成。

所以，為了保證這一切都能在“一定時(shí)間內(nèi)”完成后正常返回給前端處理結(jié)果，單次批量導(dǎo)入的數(shù)據(jù)量只能限制在1000條左右。

如何才能將批量導(dǎo)入1000條的限制解開(kāi)呢？

1. 同步處理方式

顯然，案例中批量導(dǎo)入的功能便是基于同步處理的邏輯進(jìn)行設(shè)計(jì)的，用戶(hù)操作時(shí)，前端會(huì)發(fā)送請(qǐng)求，后端必須處理完請(qǐng)求的內(nèi)容，才會(huì)返回給前端結(jié)果。

在后端響應(yīng)請(qǐng)求期間，用戶(hù)如果關(guān)閉界面，處理就中斷了，這個(gè)過(guò)程中用戶(hù)只能被動(dòng)的等待，如果請(qǐng)求的響應(yīng)時(shí)間較長(zhǎng)，用戶(hù)就容易產(chǎn)生茫然感，甚至焦慮，這樣的用戶(hù)體驗(yàn)不夠友好。

因此，同步處理往往對(duì)應(yīng)著響應(yīng)超時(shí)的判斷機(jī)制，當(dāng)請(qǐng)求的響應(yīng)時(shí)間超出了設(shè)定的最大響應(yīng)時(shí)長(zhǎng)，即使請(qǐng)求并沒(méi)有被處理完，后端也會(huì)即刻返回一個(gè)處理結(jié)果（操作失敗等異常狀態(tài)），避免用戶(hù)長(zhǎng)時(shí)間等待。

值得一提的是，當(dāng)請(qǐng)求超時(shí)后，后端仍會(huì)繼續(xù)處理前端請(qǐng)求時(shí)導(dǎo)入的數(shù)據(jù)，但是能否正常處理完是不確定的，而且此時(shí)用戶(hù)也不再能知道他發(fā)起請(qǐng)求的實(shí)際處理結(jié)果了，因?yàn)樵诔瑫r(shí)的那一刻，這個(gè)請(qǐng)求的處理結(jié)果已經(jīng)被后端返回失敗而定性了。

不過(guò)，我們考慮用戶(hù)體驗(yàn)的前提，是功能已經(jīng)滿(mǎn)足了用戶(hù)的核心訴求（能夠更快的一次導(dǎo)入更多的數(shù)據(jù)量），因而批量導(dǎo)入這個(gè)功能，以同步處理的邏輯做處理就不太合適了。

2. 異步處理方式

什么是異步處理？當(dāng)用戶(hù)在前端操作時(shí)，前端發(fā)送請(qǐng)求，后端收到請(qǐng)求后即刻給前端反饋“兄弟，你拜托的事兒我知道了，會(huì)進(jìn)行處理，你該干嘛干嘛去吧”。

所以在后端處理請(qǐng)求的過(guò)程中，用戶(hù)通常可以關(guān)閉客戶(hù)端或退出當(dāng)前頁(yè)面，去做其他的事情，無(wú)須在當(dāng)前頁(yè)面等待，后端也就不必在一定時(shí)間內(nèi)返回給前端處理結(jié)果。

沒(méi)有了“一定時(shí)間”的限制，1000條的限制問(wèn)題自然迎刃而解。

事實(shí)上，采取異步處理邏輯設(shè)計(jì)的迭代方案，單次的批量導(dǎo)入數(shù)量可增加到5萬(wàn)條，直接翻了50倍！

雖然異步處理的過(guò)程中，用戶(hù)發(fā)起請(qǐng)求后，即可退出當(dāng)前頁(yè)面去做其他的事情，但用戶(hù)肯定是關(guān)注最終的結(jié)果的。因此，異步處理通常會(huì)搭配一個(gè)結(jié)果查詢(xún)功能：它可能是一個(gè)刷新當(dāng)前頁(yè)的按鈕，也可能是一個(gè)查詢(xún)彈窗，便于用戶(hù)去查詢(xún)最后處理的結(jié)果，知曉請(qǐng)求的處理情況。

這樣，一個(gè)真實(shí)的，切合用戶(hù)使用場(chǎng)景的批量導(dǎo)入功能就完成了。

同步處理、異步處理這2種處理方式，從批量導(dǎo)入的案例來(lái)看，異步處理遠(yuǎn)勝于同步處理。

但，異步處理總是優(yōu)于同步處理嗎？

實(shí)際上，采用同步處理方式的產(chǎn)品方案也不在少數(shù)。

在我們常見(jiàn)的打車(chē)過(guò)程中，當(dāng)?shù)竭_(dá)目的地，司機(jī)會(huì)在app內(nèi)滑動(dòng)到達(dá)目的地，并確認(rèn)附加費(fèi)金額，然后司機(jī)端、乘客端APP便會(huì)自動(dòng)展示出整段行程的費(fèi)用，這個(gè)過(guò)程，便是采用同步處理的方式。

試想這個(gè)過(guò)程，采用異步處理的方式，這個(gè)場(chǎng)景會(huì)變成什么樣子？

司機(jī)到達(dá)了目的地，確認(rèn)附加費(fèi)金額后，需要通過(guò)刷新或點(diǎn)擊其他按鈕，才能獲取行程費(fèi)用；乘客也需要通過(guò)刷新獲取到行程費(fèi)用，然后才能去支付。

這樣的用戶(hù)操作流程，將導(dǎo)致大批量的乘客不會(huì)在第一時(shí)間去支付行程費(fèi)用，直接影響了公司的壞賬率。

事實(shí)上，同步、異步的處理方式各有優(yōu)劣，在合適的場(chǎng)景選擇對(duì)應(yīng)的處理方式才能達(dá)到更好的效果。

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

從上述2個(gè)案例中，我們可以發(fā)現(xiàn)，不同場(chǎng)景下，用戶(hù)的核心訴求是不一樣的，對(duì)于批量導(dǎo)入，用戶(hù)更關(guān)注的是處理的性能，而行程費(fèi)用的計(jì)算，用戶(hù)更關(guān)注的是結(jié)果的處理效率。

因此，在產(chǎn)品方案的設(shè)計(jì)中，當(dāng)我們充分理解用戶(hù)的核心訴求，同、異步的處理方式，也就有了選擇。

作者：橙言，C端非資深產(chǎn)品經(jīng)理，會(huì)一個(gè)人旅行，一個(gè)人吃火鍋，一個(gè)人看電影的一個(gè)懶人。學(xué)習(xí)交流可關(guān)注微信公眾號(hào)：橙言。

本文由 @橙言 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載
題圖來(lái)自Unsplash，基于CC0協(xié)議