張開濤：回滾機制詳解
回滾是指當程序或數據出錯時，將程序或數據恢復到最近一個正確版本的行為。最常見的如事務回滾、代碼庫回滾、部署版本回滾、數據版本回滾、靜態資源版本回滾等。通過回滾機制保證系統某些場景下的高可用。
一、事務回滾
在執行數據庫SQL時，如果我們檢測到事務提交沖突，那么事務中的所有已執行的SQL要進行回滾，目的是防止數據庫出現數據不一致。對于單庫事務回滾直接使用相關SQL即可。如果涉及到分布式數據庫，則要考慮使用分布式事務，最常見的如兩階段提交、三階段提交協議，這種方式實現事務難度較低，但是，對性能影響比較大，因為我們大多數場景需要的是最終一致性，而不是強一致性。因此，可以考慮如事務表、消息隊列、補償機制(執行/回滾)、TCC模式(預占/確認/取消)、Sagas模式(拆分事務+補償機制)等實現最終一致性。比如，電商下單場景，會進行扣減優惠券、預占庫存等操作，這涉及到非常多的子系統，因此，很難使用分布式事務保證強一致性，我們只要能保證最終一致性即可，來看下結算下單序列圖。
一種情況是當訂單出錯后，要把之前扣減的優惠券和庫存回滾。但是，當保存訂單出錯時，JVM實例掛掉了，那么之前扣減的優惠券和庫存就沒有回滾，這種情況可以考慮在本地記錄事務日志，當JVM實例重啟后，分析事務日志重新回滾，當然也可以記錄事務日志表，或者通過補償機制，定期掃描優惠券和庫存使用表，回滾沒有關聯訂單的或者已取消訂單的記錄。還有一種情況是下單后一直沒有支付，比如6小時，沒有支付訂單要取消訂單，此時就要定期掃描訂單表，然后取消訂單并回滾優惠券和庫存。不管用什么方式，只要保證最終一致性即可。
二、代碼庫回滾
在開發項目時，一定要將代碼維護到代碼倉庫，從而能進行版本管理。常見的有SVN、GIT等，SVN是一款集中版本控制系統，而GIT是一款分布式版本控制系統。有了版本控制系統后就可以記錄代碼的歷史版本，從而出問題后可以方便回滾。當某個代碼文件部署出現問題時，可以通過歷史版本查看是誰修改的、修改了什么，從而快速定位出BUG。另外，在實際開發過程中，可能存在多個版本并行開發，此時版本控制系統的分支功能就發揮大作用了，大家在各自分支上開發測試，相互不影響，開發完成后合并分支到主干即可。
三、部署版本回滾
代碼測試完成后，接下來就要進行系統的部署，在部署系統時，要考慮當代碼邏輯出現錯誤后如何快速恢復，總結為部署版本化，小版本增量發布，大版本灰度發布，架構升級并發發布。
1. 部署版本化
每次部署時，應該將上一版本的包記錄到部署系統中，在發布時應該采用全量發布，避免增量發布(只發布修改過的類或文件)，全量版本后回滾直接回滾即可，不會受到一些約束或限制。
2. 小版本增量發
比如修復BUG，添加一些簡單的業務邏輯，這些我們叫做小版本。增量發的意思是比如我們有100臺服務器，先發1臺驗證，如果沒問題，則接著發10臺，***全量發。
3.大版本灰度發
比如頁面改版，添加新的功能此時需要灰度發布，一般情況下是兩個版本并行跑一段時間，一些用戶訪問老版本，一些用戶訪問新版本，功能驗證成功后或者新版效果不錯再全量發布。比如，我們可以通過類似于如下URL中帶有版本號來區分新版還是老版。
https://cd.jd.com/yanbao/v3?skuId=854073&cat=652,654,832&brandId=8983&area=1_2810_51081_0&callback=yanbao_jsonp_callback
不同版本其實就是不同的服務，在一套集群部署即可，出問題時要能非常快速地切換回老版本。
4. 架構升級并發發布
架構升級后，我們不太清楚新版本是否功能正常，因此，新老版部署集群會同時存在一段時間。然后，等所有流量遷移到新版本集群后，老版本集群就可以下線了。
一般前端應用我們會采用Nginx作為接入層，通過AB方式慢慢將流量引入到新版本集群，比如1%、10%、50%、100%。如果新版本集群處理出現問題，那么要自動降級到老版本集群繼續服務，當新版本出現大面積故障，要將所有流量引入到老版本集群。因此，接入層要能靈活控制流量方向。
失敗降級我們可以借助Nginx的error_page。
- proxy_intercept_errors on;
- recursive_error_pages on;
- location ~* "^/(\d+)\.html$" {
- proxy_pass http://new_version/$1.html;
- error_page 500 502 503 504 =200 /fallback_version/$1.html;
- }
失敗降級是很重要的特性，關鍵時候不至于用戶不能訪問或者看到白屏，如果有CDN時，則切換版本時一定記得去掉CDN。
四、數據版本回滾
有些特定行業業務數據中的商品/價格數據需要進行版本化處理，一方面為了審計需要，另一方面為了出現問題時能及時回滾。版本化設計時可以基于下圖架構。
版本化數據結構設計時，有兩種思路：全量和增量。全量版本化是指即使只變更了其中一個字段也將整體記錄進行歷史版本化，保持的數據量比較多，但是回滾方便。而增量是指只保存變化的字段，保存的數據量較少，但是回滾起來很麻煩，需要回溯。因此，為了簡單化處理一般采用全量版本化機制。
另外，在設計消息隊列時，重要業務會對消息進行副本處理，以便萬一業務邏輯出現問題能進行歷史數據回放，從而修復問題。
五、靜態資源版本回滾
在前端開發時，靜態資源版本也是會經常變更的，如JS/CSS，而每次內容變更時我們都會生成一個全量新版本放到項目的deploy目錄中，從而能保證版本可追溯，出現問題時能及時回滾。
因為靜態資源一般放在CDN上緩存時間設置的比較長，比如1個月。這樣假設發布的版本有問題，需要清理CDN緩存，并且也需要清理瀏覽器緩存，而且因為存在版本覆蓋的問題，即使覆蓋了也不一定保證是操作正確了。
● 發布新的靜態資源到源服務器。
● 清理CDN緩存，從而可以回源取到***的靜態資源。
● 在新的URL上添加隨機數清理瀏覽器緩存，如
- <script type="text/javascript"src="/js/index.js?time=201610231111"></ script>。
當當前發布版本出現問題時，只需要將版本號更改為上一個版本即可，不需要清理CDN、不需要清理瀏覽器緩存。
當然，這里要設置合理的服務端頁面緩存時間，比如2分鐘，用戶看到發布錯誤的版本最多2分鐘時間。為了方便測試，可以在請求參數中加入版本號，如http://item.jd.com/2381431.html?version=1.0.15，方便驗證老版本或者測試新版本，使得測試或驗證多個版本時，不需要來回修改服務端代碼。
【本文是51CTO專欄作者張開濤的原創文章，作者微信公眾號：開濤的博客( kaitao-1234567)】
