回滾是指當程式或資料出錯時，將程式或資料恢復到最近的一個正確版本的行為。最常見的如事務回滾、程式碼庫回滾、部署版本回滾、資料版本回滾、靜態資源版本回滾等。透過回滾機制可保證系統在某些場景下的高可用。

7。1 事務回滾

在執行資料庫SQL時，如果我們檢測到事務提交衝突，那麼事務中所有已執行的SQL要進行回滾，目的是防止資料庫出現數據不一致。 對於單庫事務回滾直接使用相關SQL即可。如果涉及分散式資料庫，則要考慮使用分散式事務，最常見的如兩階段提交、三階段提交協議，這種方式實現事務回滾難度較低，但是對效能影響比較大，因為我們在大多數場景中需要的是最終-致性， 而不是強一一致性。 因此，可以考慮如事務表、訊息佇列、補償機制（執行/回滾）、TCC模式（預佔/確認/取消）、Sagas 模式（拆分事務+補償機制）等實現最終一致性。 比如，電商中的單場景，會進行扣減優惠券、預佔庫存等操作，這涉及非常多的子系統，因此，很難使用分散式事務保證強一致性， 我們只要能保證最終一致性即可， 下面來看看結算下單序列圖。

一種情況是當訂單出錯後，要把之前扣減的優惠券和庫存回滾。但是，當儲存訂單出錯時，JVM例項掛掉了，那麼之前扣減的優惠券和庫存就沒有回滾，這種情況可以考慮在本地記錄事務日誌，當JVM例項重啟後，分析事務日誌重新回滾，當然也可以記錄事務日誌表，或者透過補償機制，定期掃描優惠券和庫存使用表，回滾沒有關聯訂單的或者已取消訂單的記錄。還有-種情況是下單後一直沒有支付， 比如6小時，沒有支付的訂單要取消，此時就要定期掃描訂單表，然後取消訂單並回滾優惠券和庫存。不管用什麼方式，只要保證最終一致性即可。

7。2 程式碼庫回滾

在開發專案時，一定要將程式碼維護到程式碼倉庫，從而進行版本管理。常見的有SVN。Git等，SVN是一款集中版本控制系統，而Git是- -款分散式版本控制系統。有了版本控制系統後就可以記錄程式碼的歷史版本，在出問題後可以方便回滾。當某個程式碼檔案部署出現問題時，可以通過歷史版本檢視是誰修改的、修改了什麼，從而快速定位出BUG。另外，在實際開發過程中，可能存在多個版本並行開發，此時版本控制系統的分支功能就發揮大作用了，大家在各自分支上開發測試，相互不影響，開發完成後合併分支到主幹即可。

7。3 部署版本回滾

程式碼測試完成後，接下來就要進行系統的部署，在部署系統時，要考慮當代碼邏輯出現錯誤後如何快速恢復，總結為部署版本化、小版本增量釋出、大版本灰度釋出、架構升級併發釋出。

1.部署版本化

每次部署時，應該將上一版本的包記錄到部署系統中，在釋出時應該採用全量釋出，避免增量釋出（只發布修改過的類或檔案）。如有需要，全量版本可直接回滾，不會受到約束或限制。

2.小版本增量釋出

比如修復BUG，新增一些簡單的業務邏輯，這些我們叫作小版本。增量釋出的意思是比如我們有100臺伺服器，先發布1臺驗證，如果沒問題，則接著釋出10臺，最後全量釋出。

3.大版本灰度釋出

在頁面改版、新增新的功能時需要進行灰度釋出，——般情況下是兩個版本並行跑一段時間，一些使用者訪問老版本，一些使用者訪問新版本，功能驗證成功後或者新版本效果不錯時，再全量釋出。比如，我們可以透過類似如下帶有版本號的URL來區分新版本和老版本。

不同版本其實就是不同的服務，在一套叢集部署即可，出問題時要能非常快速地切換回老版本。

4.架構升級併發釋出

架構升級後，我們不太清楚新版本是否功能正常，因此，新老版本部署叢集會同時存在一段時間。然後，等所有流量遷移到新版本集群后，老版本叢集就可以下線了。

一般前端應用我們會採用Nginx作為接入層，透過A/B方式慢慢地將流量引入到新版本叢集，比如1%→10%→50%-→100%。如果新版本叢集處理出現問題，那麼要自動降級到老版本叢集繼續服務。若新版本出現大面積故障，則要將所有流量引入到老版本叢集。因此，接入層要能靈活控制流量方向。示意圖如下圖所示。

失敗降級我們可以藉助Nginx的error-page。

失敗降級是很重要的特性，關鍵時候不至於讓使用者不能訪問或者看到白屏，如果有CDN，則切換版本時一定要記得去掉CDN。

7。4 資料版本回滾

有些特定行業業務資料中的商品/價格資料需要進行版本化處理，一方面為了審計需要，另一方面為了出現問題時能及時回滾。版本化設計可以基於下圖的架構。

設計版本化資料結構時，有兩種思路：全量和增量。全量版本化是指即使只變更了其中一個欄位也將整體記錄進行歷史版本化，儲存的資料量比較多，但是回滾方便。而增量版本化是指只儲存變化的欄位，儲存的資料量較少，但是回滾起來很麻煩，需要回溯。因此，為了簡單化處理——般採用全量版本化機制。另外，在設計訊息佇列時，重要業務會對訊息進行副本處理，以便萬一業務邏輯出現問題能進行歷史資料回滾，從而修復問題。

7。5 靜態資源版本回滾

在前端開發中，靜態資源版本也是會經常變更的，如Js/CSS，而每次內容變更時我們都會生成一個全量新版本放到專案的deploy 目錄中，從而保證版本可追溯，出現問題時能及時回滾。目錄結構如下圖所示。

因為靜態資源一般放在CDN上，所以快取時間設定得比較長，比如1個月。這樣若釋出的版本有問題，則需要清理CDN快取，也需要清理瀏覽器快取，而且因為存在版本覆蓋的問題，所以即使覆蓋了也不一定保證操作正確。

釋出新的靜態資源到源伺服器

清理CDN快取，從而可以回源伺服器獲取最新的靜態資源

在新的URL上新增隨機數並清理瀏覽器快取，程式碼如下

而全量版本機制是最可靠的方式，我們先部署全量版本，然後透過如下方式引用。

在當前釋出版本出現問題時，只需要將版本號更改為上一個版本號即可，不需要清理CDN、不需要清理瀏覽器快取。當然，這裡要設定合理的伺服器端頁面快取時間，比如2分鐘，使用者看到錯誤的釋出版本最多2分鐘時間。為了方便測試，可以在請求引數中加入版本號，如htt：tmijd。comc/1431。htm1？version=1。0。15。5方便驗證老版本或者測試新版本，使得測試或驗證多個版本時，不需要來回修改伺服器端程式碼。