網際網路行業是大勢所趨,從招聘工資水平即可看出,那麼如何提升自我技能,滿足網際網路行業技能要求?需要以目標為導向,進行技能提升,本文主要針對高併發分散式系統設計、架構(資料一致性)做了分析,祝各位早日走上屬於自己的"成金之路"。.
目錄:
問題分析
概念解讀
Most Simple原理解讀
eBey、去哪兒、蘑菇街分散式事務案例分析
參考資料

1.問題解析    
要想做架構,必須識別出問題,即是誰的問題,什麼問題。
明顯的,分散式架構解決的是高併發的問題,高併發下服務高可用和資料一致性問題問題;當規模規模較小時,單庫HA即可滿足請求,當業務規模持續增加,單庫已經無法滿足業務需求,業界主流做法,是對業務進行分表、分庫,那麼原來的有些業務,現在則要在一個事務中,保證兩個庫同時操作成功或操作不成功(一個庫成功,一個庫失敗,要麼重新嘗試失敗庫操作直到成功,要麼回滾成功庫)。隨之而來的問題既是如何保證分庫時業務操作的資料一致性。理解高併發分散式架構、分散式系統資料一致性的問題、起源是第一步。
這裡多囉嗦一點,分庫後,每個庫可以採取不同的語言,以時下很流行的微服務向外提供服務;但是業務量不大的情況下,使用微服務到增加了複雜性及技術成本。明白技術的起源,針對不同的業務量,採取適當的架構、以最恰當的方式承載業務,是架構師必須具備的能力。
2.常見概念解讀:
a.關係型資料庫通常具有ACID特性:原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、永續性(Durability)。
b.Base(basically available, soft state, eventually consistent):一種 Acid 的替代方案,BASE 的可用性是通過支援區域性故障而不是系統全域性故障來實現的。化學理論中ACID是酸、Base恰好是鹼。
c.CAP定律:在分散式系統中,同時滿足"CAP定律"中的"一致性"、"可用性"和"分割槽容錯性"三者是不可能的。
d.強一致:當更新操作完成之後,任何多個後續程序或者執行緒的訪問都會返回最新的更新過的值。這種是對使用者最友好的,就是使用者上一次寫什麼,下一次就保證能讀到什麼。根據 CAP 理論,這種實現需要犧牲可用性,常見的RDBMS。
e.弱一致性:系統並不保證續程序或者執行緒的訪問都會返回最新的更新過的值。系統在資料寫入成功之後,不承諾立即可以讀到最新寫入的值,也不會具體的承諾多久之後可以讀到。
f.最終一致性:弱一致性的特定形式。系統保證在沒有後續更新的前提下,系統最終返回上一次更新操作的值。在沒有故障發生的前提下,不一致視窗的時間主要受通訊延遲,系統負載和複製副本的個數影響。DNS 是一個典型的最終一致性系統。
為保證可用性,網際網路分散式架構將強一致性需求轉換成最終一致性的需求,並通過系統執行冪等性的保證,保證資料的最終一致性。
冪等性(Idempotence):分散式架構的基石,即同一個操作無論請求多少次,其結果都相同。
典型的是HTTP,Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.
每個概念實際所解決的是人遇到的某個特定的問題,發現其背後所代表的問題,是理解高併發分散式架構、分散式系統資料一致性第二步。
3.Most Simple原理解讀
假設有一個從賬戶取錢的遠端API(可以是HTTP的,也可以不是),我們暫時用類函式的方式記為:

bool withdraw(account_id, amount)
withdraw的語義是從account_id對應的賬戶中扣除amount數額的錢;如果扣除成功則返回true,賬戶餘額減少amount;如果扣除失敗則返回false,賬戶餘額不變。
值得注意的是:和本地環境相比,我們不能輕易假設環境的可靠性
一種典型的場景是withdraw請求已經被伺服器端正確處理,但伺服器端的返回結果由於網路等原因被掉丟了,導致客戶端無法得知處理結果。如果是在網頁上,一些不恰當的設計可能會使使用者認為上一次操作失敗了,然後重新整理頁面,這就導致了withdraw被呼叫兩次,賬戶也被多扣了一次錢。如圖1所示:

non-idempotent

一種更輕量級的解決方案是冪等設計。我們可以通過一些技巧把withdraw變成冪等的,比如:

int create_ticket() 
bool idempotent_withdraw(ticket_id, account_id, amount)
create_ticket的語義是獲取一個伺服器端生成的唯一的處理號ticket_id,它將用於標識後續的操作。idempotent_withdraw和withdraw的區別在於關聯了一個ticket_id,一個ticket_id表示的操作至多隻會被處理一次,每次呼叫都將返回第一次呼叫時的處理結果。這樣,idempotent_withdraw就符合冪等性了,客戶端就可以放心地多次呼叫。

基於冪等性的解決方案中一個完整的取錢流程被分解成了兩個步驟:1.呼叫create_ticket()獲取ticket_id;2.呼叫idempotent_withdraw(ticket_id, account_id, amount)。雖然create_ticket不是冪等的,但在這種設計下,它對系統狀態的影響可以忽略,加上idempotent_withdraw是冪等的,所以任何一步由於網路等原因失敗或超時,客戶端都可以重試,直到獲得結果。如圖所示:

idempotent

和分散式事務相比,冪等設計的優勢在於它的輕量級,容易適應異構環境,以及效能和可用性方面。在某些效能要求比較高的應用,冪等設計往往是唯一的選擇。
冪等性是高併發分散式架構、分散式系統資料一致性的底層基本原理,理解這一步,是走上"成金之路"的關鍵。
4.案例分析
a.eBay經典的BASE模式
一個最常見的場景,如果產生了一筆交易,需要在交易表增加記錄,同時還要修改使用者表的金額。這兩個表屬於不同的庫及遠端服務,所以就涉及到分散式事務一致性的問題。
核心思想是用兩個事務來保證一致性,同時用非同步保證了可用性:一個事務處理主要操作"增加交易表記錄"與非同步訊息構建,另外一個事務用來處理構建的非同步訊息;第一個事務即處理主要業務又記錄次要業務,同時還能快速返回,保證了高可用性,第二個事務則用來保證資料的一致性。(即將buyer和seller表更新的處理轉為"線下"處理,訊息日誌可以儲存到本地文字、資料庫或訊息佇列,再通過業務規則自動或人工發起重試。人工重試更多的是應用於支付場景,通過對賬系統對事後問題的處理,類似與淘寶雙11重複支付後續退款)
一個經典的解決方法,將主要修改操作以及更新使用者表的"非同步訊息"放在一個本地事務來完成。同時為了達到多次重試的冪等性,避免重複消費使用者表訊息帶來的問題,增加一個更新記錄表 updates_applied 來記錄已經處理過的訊息。
在第一事務中,通過本地的資料庫的事務保障,保證"增加交易表記錄"、"增加兩條非同步訊息佇列記錄(一條處理buyer表、一條處理seller表)",同時成功或同時失敗。
在第二事務中,分別讀出訊息佇列(但不刪除),通過判斷更新記錄表 updates_applied 來檢測相關訊息是否被執行,如沒執行,則執行相關業務邏輯(保證冪等性,保證即使執行過程中異常,重複執行沒有任何問題),執行完所有訊息後然後增加一條操作記錄到updates_applied,事務到此結束。用事務保證兩個非同步訊息執行及updates_applied的一致性操作(又稱為分散式事務框架)。最後刪除佇列。
b.去哪兒網分散式事務方案
i.優先使用非同步方案,原理和"a.eBay經典的BASE模式"類似,對業務邏輯處理不能保證"冪等性"的,增加去重表(即a中的updates_applied) 來處理
ii.對於不適合非同步訊息處理的業務,如A、B、C三方需要同步處理才能返回:在A、B、C三個庫中分別維護一個事務記錄表recorda/recordb/recordc,當A、B、C業務事務處理完,將結果存到對應的recordx中,由一箇中心服務對比查詢三方的事物記錄表,有如下兩種處理方式:
    第一種:A、B成功,C失敗了,重試C,知道C成功;
    第二種:C不可能成功時,回滾A、B,如C為扣庫存,當庫存為0時,則不能成功(不考慮補庫存)。
另,這種recordx表由RPC框架層進行維護,對業務是透明的。
c.蘑菇街交易建立過程
場景:將下單功能拆分為12個子業務(見參考資料b),對於非實時、非強一致性的關聯業務,使用"eBay經典的BASE模式"思想,第一個本地事務執行成功後,以發訊息通知、關聯事務非同步化執行方案,來避免a中第二個事務的"分散式事務框架"對業務帶來的侵入和複雜性,具體方案是基於DB事件變化通知給MQ,而MQ消費者通過ACK,保證訊息一定消費成功,完成強一致性(訊息可能會被重發,所以訊息消費方要保證冪等性)。
而對要求同步做、強一致性要求的場景(和b的ii相同場景),如優惠券和優惠券減庫存:可以引入"a.eBay經典的BASE模式"的第二個事務(分散式事務框架)來處理,但是複雜性會急劇上升;
另一種方式是建立一個不可見訂單,然後在同步呼叫鎖券和扣減庫存時,針對呼叫異常(失敗或者超時),發出廢單訊息到MQ。如果訊息傳送失敗,本地會做時間階梯式的非同步重試;優惠券系統和庫存系統收到訊息後,會進行判斷是否需要做業務回滾,這樣就準實時地保證了多個本地事務的最終一致性。
根據業務進行不同的方案處理,解決了高併發分散式架構、分散式系統的資料一致性問題。
 
整體來說,蘑菇街的案例可遷移性強,可移植性好,可以嘗試模擬下實際場景,駕馭分散式架構、分散式系統資料一致性方案,祝大家早日走上"成金之路",看到這裡,煩請不吝"推薦",謝謝!
5.參考資料: