數據一致性-對帳

概念

一致性分爲強一致性和弱一致性。
強一致性的協議和手段主要有：二階段提交(2PC)、三階段提交(3PC)、TCC(Try-Confirm-Cancel)補償型。這裏面常常有人把兩階段提交和TCC補償型混淆。二階段提交實際上業務邏輯是在提交以前作的，兩階段只是事務控制的兩個階段。而TCC是將業務邏輯分爲try、confirm和cancel三個階段。舉個例子：好比一我的要預售蘋果，有兩種銷售策略。一種讓用戶先付錢，根據用戶需求量準備足夠的蘋果。另外一種是讓用戶先付錢同時聲明到時候先到先得，沒搶到的就退款。第一種就是二階段提交，第二種就是TCC。弱一致性在分佈式系統中經常使用的是一種特例：最終一致性。在工做中，最終一致性一般經過補單和對帳來解決。補單主要指在運行時同時檢查返回值，若是返回值爲失敗，會從新處理（補單處理）。
對帳主要分爲兩個階段：數據覈對和差錯處理。數據覈對就是對帳中的軋帳。注意「軋」這裏念「ga」二聲。差錯處理就是對帳中的平帳。

 

應用

以秒殺場景爲例說明一下對帳的經常使用流程。

對帳依據和標準

對帳問題最早解決的問題是對帳依據和標準。好比秒殺場景，對帳依據就是訂單號，整個鏈路採用惟一內部訂單號。對帳標準能夠設定爲對用戶的承諾。就是說：一次秒殺活動結束，若是給用戶的結果是成功，那麼實際上超賣了，那就本身補貨解決。若是給用戶結果是失敗了，實際上有不少沒賣出去，那就是沒賣出去放着。總之，我承諾給用戶的結果必定要履行。若是數據覈對時，各個環節結果不一致，最終結果向用戶的承諾對齊。

對帳梳理

能夠從明細和總數兩個方面來作對帳。在秒殺場景中，明細是一條條請求訂單。總數是成功和失敗了多少個請求，買出多少庫存。明細對帳主要用於定位問題。總數對帳是兜底策略，用來解決「怎麼證實本身是對的」的問題。

對帳時機

分爲在線對帳和離線對帳。在線對帳又分爲實時對帳和準實時對帳。實時對帳就是好比秒殺成功了，那下游的每一步都須要是成功的，其餘狀況如超時等則採用重試來進行強一致性保證。準實時對帳一般用異步來實現。在秒殺的場景，若是訂單返回失敗，能夠異步發起一個任務進行退款，若是退款不成功則能夠用屢次重試進行補單。
離線對帳就是平時所說的定時任務。這個對帳方法就比較多了，自由發揮空間比較大。特別是在軋帳場景中，由於不實際修改數據，風險低，不少新技術試用能夠選擇在此模塊進行。