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