回滾是指當程序或數(shù)據(jù)出錯時，將程序或數(shù)據(jù)恢復到最近的一個正確版本的行為。最常見的如事務回滾、代碼庫回滾、部署版本回滾、數(shù)據(jù)版本回滾、靜態(tài)資源版本回滾等。通過回滾機制可保證系統(tǒng)在某些場景下的高可用。

7.1 事務回滾

在執(zhí)行數(shù)據(jù)庫SQL時，如果我們檢測到事務提交沖突，那么事務中所有已執(zhí)行的SQL要進行回滾，目的是防止數(shù)據(jù)庫出現(xiàn)數(shù)據(jù)不一致。 對于單庫事務回滾直接使用相關(guān)SQL即可。如果涉及分布式數(shù)據(jù)庫,則要考慮使用分布式事務,最常見的如兩階段提交、三階段提交協(xié)議，這種方式實現(xiàn)事務回滾難度較低，但是對性能影響比較大，因為我們在大多數(shù)場景中需要的是最終-致性， 而不是強一一致性。 因此，可以考慮如事務表、消息隊列、補償機制(執(zhí)行/回滾)、TCC模式(預占/確認/取消)、Sagas 模式(拆分事務+補償機制)等實現(xiàn)最終一致性。 比如，電商中的單場景，會進行扣減優(yōu)惠券、預占庫存等操作，這涉及非常多的子系統(tǒng)，因此，很難使用分布式事務保證強一致性， 我們只要能保證最終一致性即可， 下面來看看結(jié)算下單序列圖。

?

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

7.2 代碼庫回滾

在開發(fā)項目時，一定要將代碼維護到代碼倉庫,從而進行版本管理。常見的有SVN.Git等，SVN是一款集中版本控制系統(tǒng)，而Git是- -款分布式版本控制系統(tǒng)。有了版本控制系統(tǒng)后就可以記錄代碼的歷史版本，在出問題后可以方便回滾。當某個代碼文件部署出現(xiàn)問題時,可以通過歷史版本查看是誰修改的、修改了什么，從而快速定位出BUG.另外，在實際開發(fā)過程中，可能存在多個版本并行開發(fā)，此時版本控制系統(tǒng)的分支功能就發(fā)揮大作用了，大家在各自分支上開發(fā)測試，相互不影響，開發(fā)完成后合并分支到主干即可。

7.3 部署版本回滾

代碼測試完成后，接下來就要進行系統(tǒng)的部署，在部署系統(tǒng)時，要考慮當代碼邏輯出現(xiàn)錯誤后如何快速恢復，總結(jié)為部署版本化、小版本增量發(fā)布、大版本灰度發(fā)布、架構(gòu)升級并發(fā)發(fā)布。

1.部署版本化

每次部署時，應該將上一版本的包記錄到部署系統(tǒng)中,在發(fā)布時應該采用全量發(fā)布，避免增量發(fā)布(只發(fā)布修改過的類或文件)。如有需要，全量版本可直接回滾，不會受到約束或限制。

2.小版本增量發(fā)布

比如修復BUG，添加一些簡單的業(yè)務邏輯，這些我們叫作小版本。增量發(fā)布的意思是比如我們有100臺服務器，先發(fā)布1臺驗證，如果沒問題，則接著發(fā)布10臺，最后全量發(fā)布。

3.大版本灰度發(fā)布

在頁面改版、添加新的功能時需要進行灰度發(fā)布，--般情況下是兩個版本并行跑一段時間，一些用戶訪問老版本，一些用戶訪問新版本，功能驗證成功后或者新版本效果不錯時，再全量發(fā)布。比如，我們可以通過類似如下帶有版本號的URL來區(qū)分新版本和老版本。

?

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

4.架構(gòu)升級并發(fā)發(fā)布

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

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

?

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

?

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

7.4 數(shù)據(jù)版本回滾

有些特定行業(yè)業(yè)務數(shù)據(jù)中的商品/價格數(shù)據(jù)需要進行版本化處理,一方面為了審計需要，另一方面為了出現(xiàn)問題時能及時回滾。版本化設計可以基于下圖的架構(gòu)。

?

設計版本化數(shù)據(jù)結(jié)構(gòu)時，有兩種思路:全量和增量。全量版本化是指即使只變更了其中一個字段也將整體記錄進行歷史版本化，保存的數(shù)據(jù)量比較多，但是回滾方便。而增量版本化是指只保存變化的字段，保存的數(shù)據(jù)量較少，但是回滾起來很麻煩，需要回溯。因此，為了簡單化處理--般采用全量版本化機制。另外，在設計消息隊列時，重要業(yè)務會對消息進行副本處理，以便萬一業(yè)務邏輯出現(xiàn)問題能進行歷史數(shù)據(jù)回滾，從而修復問題。

7.5 靜態(tài)資源版本回滾

在前端開發(fā)中，靜態(tài)資源版本也是會經(jīng)常變更的，如Js/CSS，而每次內(nèi)容變更時我們都會生成一個全量新版本放到項目的deploy 目錄中，從而保證版本可追溯，出現(xiàn)問題時能及時回滾。目錄結(jié)構(gòu)如下圖所示。

?

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

• 發(fā)布新的靜態(tài)資源到源服務器
• 清理CDN緩存，從而可以回源服務器獲取最新的靜態(tài)資源
• 在新的URL上添加隨機數(shù)并清理瀏覽器緩存，代碼如下

?

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

?

在當前發(fā)布版本出現(xiàn)問題時，只需要將版本號更改為上一個版本號即可，不需要清理CDN、不需要清理瀏覽器緩存。當然，這里要設置合理的服務器端頁面緩存時間，比如2分鐘，用戶看到錯誤的發(fā)布版本最多2分鐘時間。為了方便測試，可以在請求參數(shù)中加入版本號，如htt:tmijd.comc/1431.htm1?version=1.0.15.5方便驗證老版本或者測試新版本，使得測試或驗證多個版本時，不需要來回修改服務器端代碼。

總結(jié)

以上是生活随笔為你收集整理的回滚机制有多少种？它们的实现原理是什么？这些你确定都知道？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。