最近看到一篇分布式事務解決方案文章
柔性事務，要求最終一致性，允許中間狀態短期不一致。相對于強一致性事務（剛性事務）而言，它鎖定的資源範圍小，阻塞性弱，更為高效。
柔性事務有多種實現方式，包括tcc、saga、事務訊息、最大努力通知等，本文將重點介紹通過事務訊息實現柔性事務。
以下為部分正文
針對搶購類業務在技術上帶來的挑戰，業界有一系列解決方案，通過不同維度來提公升系統的效能與穩定性，包括動靜分離、定時上架、非同步處理、令牌佇列、多級快取、作弊行為偵測、流量防護、全鏈路壓測等。
本文重點聚焦在如何確保搶購類業務的一致性上，分布式事務一直是it界老大難的問題，而搶購業務所具備的高併發、大流量特徵，更是成倍增加了分布式一致性的實現難度。以下將介紹如何通過事務訊息構建滿足搶購類業務要求的高效能高可用分布式一致性機制。
事務是應用程式中一系列嚴密的操作，這一系列操作是乙個不可分割的工作單位，它們要麼全部執行成功，要麼乙個都不做。事務具有四個特徵：原子性（ atomicity ）、一致性（ consistency ）、隔離性（ isolation ）和持續性（ durability ），這四個特性簡稱為 acid 特性。
在非併發狀態下，保證事務的 acid 特性是輕而易舉的事情，如果某乙個操作執行不成功，把前面的操作全部回滾就 ok 了。而在併發狀態下，由於有多個事務同時操作同乙個資源，對於事務 acid 特性的保證就會困難一些，如果考慮得不周全，就會遇到如下幾個問題：
髒讀：事務 a 讀到了事務 b 還沒有提交的資料。
不可重複讀：在乙個事務裡面對某個資料讀取了兩次，讀出來的資料不一致。
幻讀：在乙個事務對某個資料集用同樣的方式讀取了兩次，資料集的條目數量不一致。
為了應對上述併發情況下出現的問題，就需要通過一定的事務隔離級別來解決。當事務的隔離級別越高的時候，上述問題發生的機會就越小，但是效能消耗也會越大。所以在實際生產過程中，要根據實際需求去確定隔離級別：
關係型資料庫提供了對於事務的支援，能夠通過不同隔離級別的設定，確保併發狀態下事務的acid特性。但關係型資料庫提供的能力是基於單機事務的，一旦遇到分布式事務場景，就需要通過更多其他技術手段來解決問題。
有如下三種情況可能會產生分布式事務：
1、乙個事務操作包含對兩個資料庫的操作：資料庫所提供的事務保證僅能侷限在對於自身的操作上，無法跨越到其他資料庫。
2、乙個事務包含對多個資料分片的操作：具體的分片規則由分庫分表中介軟體或者分庫分表 sdk 來實現，有可能跨越多個資料庫或同乙個資料庫的多個表。對於業務邏輯而言，底層的資料分片情況是不透明的，因此也沒有辦法依賴於資料庫提供的單機事務機制。
3、乙個事務包括對多個服務的呼叫：在微服務領域，這是極為常見的場景，不同的服務使用不同的資料資源，甚至涉及到更為複雜的呼叫鏈路。在這種情況下，資料庫提供的單機事務機制，僅僅能保證其中單一環節的 acid 特性，沒有辦法延伸到全域性。
微服務技術在電商領域的普及程度是非常高的，比較大型的電商應用還會通過中臺思想將共性業務能力進行沉澱，因此搶購業務中的很多環境都屬於跨服務的分布式呼叫，會涉及到上述第三種分布式事務形態。比如在訂單支付成功後，交易中心會呼叫訂單中心的服務把訂單狀態更新，並呼叫物流中心的服務通知商品發貨，同時還要呼叫積分中心的服務為使用者增加相應的積分。如何保障分布式事務一致性，成為了確保搶購業務穩定執行的核心訴求之一。
RocketMq分布式事務
先丟擲問題 老生常談的問題 就是a，b在不同的伺服器，然後a賬戶減錢，b賬戶加錢。因為他們不在同乙個事務下，所以，就會出現a減錢，b加錢沒成，然後就導致資料不完整。那麼rocketmq是如何解決這問題呢 採用 最終一致性 核心思路就是 狀態回查 也就是rocketmq會定時遍歷commitlog中的...
分布式系統原理 之7 基於MVCC的分布式事務
實現分布式事務除了使用類似 兩階段提交 協議等方式外，另一種簡單高效的方式就是使用mvcc multi version cocurrent control，多版本併發控制 技術 3 5 顧名思義，mvcc 即多個不同版本的資料實現併發控制的技術，其基本思想是為每次事務生成乙個新版本的資料，在讀資料時...
TransactionScope 分布式事務
transactionscope是.net framework 2.0滯後，新增了乙個命名空間。它的用途是為資料庫訪問提供了乙個 輕量級 區別於 sqltransaction 的事物。使用之前必須新增對 system.transactions.dll 的引用。下列 就是乙個正在建立的事務，這個事務自...