圖解 JavaScript 競態處理

前言

最近被公司安排分享一些主題，思來想去，以爲仍是想分享關於 JavaScript 競態相關的知識。因而總結成此文。

這篇博客的目標主要以圖例的方式帶你們瞭解 JavaScript 併發與競態，若有疏漏，歡迎你們指正。

如下正文。

競態致使的錯誤

經驗較爲豐富的開發者，可能會感觸於異步代碼的確較比同步代碼難以理解和編寫、維護。「時間是程序裏最複雜的因素」。一個現代的 Web 應用沒法避免異步的處理。如何更好的意識到異步中的併發與競態的存在，這是第一步。好比看下圖：

假設咱們有三個異步請求：A1 -> A2 -> A3，按時間觸發，每個請求通過服務器後，再響應返回，會對應用產生一些反作用 (Effect)。

同時咱們假設，每個請求受網絡因素影響，響應返回的時間不定。如上圖，實際響應返回順序是：A3 -> A1 -> A2。所以儘管咱們指望的是對應用產生效果的正確請求應該是 A3。最終實際生效的是 A2。因而在實際環境中，最終或許致使一個致命的錯誤。

那麼如何避免這種狀況呢？

策略一 —— 去舊迎新

用過 redux-saga 的同窗可能知道有個 API 叫作「takeLatest」。rxjs 裏也有個操做符叫作「takeLast(1)」。前端可經過狀態控制，管理多個請求。

實現思路主要爲，每當觸發最新的請求時，則取消前置的請求，使得永遠只有最新的請求能夠最終生效。

備註，取消請求的方法，在原生的 XHR 對象裏方法爲：XMLHttpRequest.abort()。在 axios 裏有 cancelToken 的 API 提供完成。

策略二 —— 控制回調

一樣咱們也能夠任由請求發生，由於咱們須要保證的實際上，是 Web 應用最終能以服務器最終的數據產生做用（也便是最新的一個請求所能獲取的數據）。

所以，咱們實際上或許無需阻止請求的發生，咱們控制住請求的前端響應回調執行順序便可。在此基礎上作一個防抖控制，亦能夠達到預期中比較良好的體驗效果。

策略三 —— 隊列

第三種策略，能夠將全部發起請求放在前端的一個隊列裏，逐個發送，在一個請求響應回來後，才發射下一個請求。因爲直接將請求從拍成了一條線，也就徹底避免了競態的場景問題發生。

相比於策略1、策略二，這種方法也許看上去是最笨和最慢的一個方法了。可是這個方法是能夠在某些場景下，是比前兩者更好的選擇。

GET or POST 請求場景

以上策略都知足於 GET 請求的場景。

然而，讓咱們考慮如下場景：

咱們的請求不是簡單的 GET 請求，而是會對服務器數據庫進行操做的 POST 請求，且服務器依賴於 POST 請求操做的執行順序，從而返回正確的響應。

策略一的弊端在於，即便取消了請求，只是保證了在前端不執行響應回調，但前端實際上也沒法控制該請求是否已經到達服務器。也就是說。那實際上服務器數據操做也可能會形成紊亂。

策略二的弊端也同上，因爲甚至沒有取消請求，若是在一樣上述場景下，請求到達服務器的順序錯誤，服務器數據庫的數據紊亂甚至是必然發生的。

以下圖，咱們假設服務器數據庫 A、B 分別表明用戶的兩種權限，A+請求會增長數據庫 A 值，A-操做會減小數據庫 A 值，B 操做同 A，而服務權限不可能爲負值，以下圖：

所以錯誤的請求到達順序致使了數據庫數據的錯誤。

而策略三雖然沒有充分利用請求併發的優點，可是經過在前端隊列控制發送請求上，就已經徹底避免了上述的問題。

關於時序控制

因而基於策略三，亦能夠細分爲前端的隊列控制和後端的時序控制。

前端控制

如圖所示，多個請求拍成一個隊列，逐個發送，實現後可參見控制檯網絡面板的瀑布流。

後端控制

有同事提醒我，其實服務器也能夠實現這個需求。前端正常發送全部請求，服務器維護多個請求的狀態，動態控制請求生效響應順序。

關於實現

實現方面，我以前已經寫過一篇博客。可是主要都是示例代碼。參見 關於 JavaScript 併發、競態場景下的一些思考和解決方案

小結

固然，指望知作別的方法的同窗能夠不吝指教。

以上，對你們若有助益，不勝榮幸。