引子
媽媽要我的時候已經40歲了，她一定是下了很大的決定才決定終究還是想要個女孩，希望這個女孩可以解救她的孤獨，上高三的時候，有次又是因為哥哥的事情，媽媽把我從學校接回家，一個勁兒的問我怎么辦好，在我能和她一起思考前的50多年里，她該是多么無助，所以當我不斷看自己的掌紋，上面的起起伏伏，在想這一切解釋不通的苦難什么時候過去，在想是不是在天堂的媽媽安排了這一切，因為理解她的痛苦是我的使命，我錯了，她不是在天堂安排了這一切，是在我很小的時候，我為理解她而生，這是我的命運，命運并不是很深奧的東西，只是一個發展脈絡，好比做金融領域，和清算、結算、對賬打交道就是命運，對賬本來用在金融領域，逐漸擴大到資料一致性領域，好比彈性工程，本來是航天領域的術語，逐漸演變為構造高可用工程的方法，方法的核心是通過提出邊界場景（失敗、風險、意外事件）問題，然后從檢測、補救、預防幾個維度去思考答案，最終反哺到系統設計開發與流程改善上，倒逼架構和流程SOP改進，再結合預案演練達到扼殺故障和縮短故障時間的目的，概念
一致性分為強一致性和弱一致性，強一致性的協議和手段主要有：二階段提交(2PC)、三階段提交(3PC)、TCC(Try-Confirm-Cancel)補償型，這里面經常有人把兩階段提交和TCC補償型混淆，二階段提交實際上業務邏輯是在提交之前做的，兩階段只是事務控制的兩個階段，而TCC是將業務邏輯分為try、confirm和cancel三個階段，舉個例子：比如一個人要預售蘋果，有兩種銷售策略，一種讓用戶先付錢，根據用戶需求量準備足夠的蘋果，另一種是讓用戶先付錢同時宣告到時候先到先得，沒搶到的就退款，第一種就是二階段提交，第二種就是TCC，弱一致性在分布式系統中常用的是一種特例：最終一致性，在作業中，最終一致性通常通過補單和對賬來解決，補單主要指在運行時同時檢查回傳值，如果回傳值為失敗，會重新處理（補單處理），
對賬主要分為兩個階段：資料核對和差錯處理，資料核對就是對賬中的軋賬，注意「軋」這里念「ga」二聲，差錯處理就是對賬中的平賬，
應用
以秒殺場景為例說明一下對賬的常用流程，對賬依據和標準
對賬問題最先解決的問題是對賬依據和標準，比如秒殺場景，對賬依據就是訂單號，整個鏈路采用唯一內部訂單號，對賬標準可以設定為對用戶的承諾，就是說：一次秒殺活動結束，如果給用戶的結果是成功，那么實際上超賣了，那就自己補貨解決，如果給用戶結果是失敗了，實際上有很多沒賣出去，那就是沒賣出去放著，總之，我承諾給用戶的結果一定要履行，如果資料核對時，各個環節結果不一致，最終結果向用戶的承諾對齊，對賬梳理
可以從明細和總數兩個方面來做對賬，在秒殺場景中，明細是一條條請求訂單，總數是成功和失敗了多少個請求，買出多少庫存，明細對賬主要用于定位問題，總數對賬是兜底策略，用來解決「怎么證明自己是對的」的問題，對賬時機
分為在線對賬和離線對賬，在線對賬又分為實時對賬和準實時對賬，實時對賬就是比如秒殺成功了，那下游的每一步都需要是成功的，其他情況如超時等則采用重試來進行強一致性保證，準實時對賬通常用異步來實作，在秒殺的場景，如果訂單回傳失敗，可以異步發起一個任務進行退款，如果退款不成功則可以用多次重試進行補單，離線對賬就是平時所說的定時任務，這個對賬方法就比較多了，自由發揮空間比較大，特別是在軋賬場景中，因為不實際修改資料，風險低，很多新技術試用可以選擇在此模塊進行，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/42034.html
標籤：架構設計