剛做後端大概10個月，從遊戲前端開發轉向後端，看似熟悉的程式語言，在不同的領域內實際上要考慮的事情也是全然不同的。
當我們談論後端開發，自然而然聯想到，後端是服務於前端的，也是承載、服務於業務的乙個重要組成部分。系統的穩定性，正確性以及可用性都是需要考慮的問題。
做後端，說簡單也簡單，說難也很難，簡單是因為你只需要對資料進行增刪查改，聚合統計就完事了，說難是因為一旦涉及到可用性，必然離不開分布式，然而我們知道，由分布式而引出的一系列問題才是最為棘手的，更不用說系統安全、部署、監控等一些列的落地措施。
你需要確保多個系統的業務資料不混亂，在某些跨服務功能的呼叫鏈中保持一致性，當某乙個服務呼叫失敗之後進行重試或者回滾。
重試需要你的服務具備冪等性，也就是說，當引入重試機制之後，你需要確保乙個服務在同乙個業務上下文中多次呼叫而不會產生額外的影響，例如銀行轉賬，如果多扣幾次錢或者多加了幾次錢對於公司的業務以及信譽來說都是無法接受的，解決這個問題的辦法需要引入類似流水號的關聯標識，在不同的服務裡面形成乙個標識上下文。
當我們的整個後端系統根據業務領域分割為不同的服務獨立成型時，多個服務之間相互呼叫往往會因為網路原因而失敗。硬體損壞、宕機、自然災害等一些列不可抗力因素告訴我們，任何事情都有可能失敗，當你的系統規模超過閾值之後，偶然將會轉變為必然。我們要的做的，不應該是想出乙個萬全之策強力約束保證我們的系統一定會成功，或者懷著僥倖的心理上線然後惶惶不安的等待系統出現問題。反而更應該思考一下，當系統出現問題之後，如何快速有效的修復失敗所帶來的影響。因為我們知道，既然我們無法保證100%成功，那唯一的出路便想出乙個補救措施來預防失敗，這往往會更令人更有安全感。
在討論如何解決分布式一致性之前，我們更應該反過頭來看一下，什麼是事務，它在單機模式下是如何保證業務的原子性的。我們往往將業務事務和資料庫的事務混為一談，通常來說這是沒問題的，因為後端做的不就是資料的儲存麼。但當我們把這兩個進行區分的時候，會發現大多數的時候，我們所說的事務，僅僅是通過資料庫提供的acid來實現的。當你要對資料庫的多個表進行操作的時候，開啟乙個事務，並且進行相應的更新，然後提交事務，此時要麼成功，要麼回滾撤銷變更，通過資料庫提供的acid保證我們的資料不會因為受到中斷的影響而產生混亂。
但如果我們分布式之後呢？每乙個業務子系統擁有自己的資料庫，你如何保證乙個業務流程，在跨子系統呼叫時保證原子性呢？
如果我們把希望繼續寄託於資料庫，多個業務子系統使用同乙個資料庫，資料庫本身將會成為瓶頸，這樣便失去了一開始設計分布式系統的初衷。
如果某乙個子系統失敗之後，造成了資料的不一致，此時，要麼回滾之前的操作，要麼就想辦法讓這個失敗的呼叫變為成功。
a作為業務發起者呼叫b和c，b成功，c失敗，a知道c失敗之後該怎麼做呢？是重新呼叫一次c還是通知b回滾呢？如果通知b回滾的時候也失敗了呢？
答案往往是不統一的，每乙個業務領域都有根據自身情況進行處理的方式。有很多分布式事務協議能夠解決些許問題，但是這往往會造成複雜度的提公升，導致將來的維護以及拓展變得舉步維艱。
cap定理相信大家都有了解，在任何時候我們要麼取cp要麼取ap，cp的問題在於複雜、可用性以及可維護性差，ap的問題在於一定的時間內，資料會存在不一致性。如果選擇cp，是時候考慮一下業務的分割是否合理，只有極少的情況我們才需要保證強一致性。
我們需要一種更為聰明的方法，一種機制來保證我們的系統能夠達成最終一致性，這才是分布式系統需要解決問題的根本之道，並且已經有很多模式方法來幫助我們達成我們想要的結果。
換乙個角度來講，分布式事務，本身就是乙個偽命題，因為系統是脆弱的，有太多太多的因素會造成事情不可控。
我們要做對的事情，讓系統能夠根據業務需求變更逐步演進，形成乙個良性迴圈，根據業務需求、目標領域來設計系統，合理的進行分割才是王道。
如果你的系統本身不匹配業務領域，而又把不合理、生搬硬套的架構應用於它，就會出現各種各樣的問題，這些問題在某些時候甚至是不可能解決的。
在我看來，有關於解決分布式事務的技術，無非是在為糟糕的設計進行彌補，導致系統到最後臃腫不堪。那麼什麼是好的設計呢？簡單的來說，它應該符合你所處領域的業務知識，技術是不能解決所有問題的，因為只有當你的業務邏輯說得通，領域模型設計的清晰，巧妙之後，才能夠解決那些看似不可能解決的問題。
不要妄想用一套通用的模式去套每乙個專案需求，這樣永遠不會擺脫問題。
分布式系統在絕大多數時候，反脆弱、最終一致性才是我們真正需要去解決的問題。
ps：你的系統究竟有多大才會導致最終一致性會被人為的察覺出來？但我們知道資料最終將會一致不是嗎？:)
分布式系統中的分布式事務
分布式事務中可以借助mq訊息系統來進行事務控制，這一點與可靠訊息最終一致方案一樣。看來mq中介軟體確實在乙個分布式系統架構中，扮演者重要的角色。最大努力通知方案是比較簡單的分布式事務方案，它本質上就是通過定期校對，實現資料一致性。中介軟體如何保證訊息的一致性 問題的問法多種多樣，怎麼保證兩個伺服器的...
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...
事務,分布式系統實現事務
1.事務概念 事務是指邏輯上的一組操作,組成該操作的各個單元,要麼全部執行成功,要麼全部執行失敗 只有全部執行成功後,事務才會提交,若有乙個單元執行失敗,那麼所有資料都會通過回滾自動恢復.回滾機制 當事務內部有乙個操作執行失敗後,那麼將會撤銷所有已完成的更新操作 2.事務的四大特性 1 原子性 即不...