1樓：
這個叫做異構分布式事務，有乙個標準叫做xa，它是一種與協調者通訊的api. 有了這個api，其餘實現就和普通的分布式事務一樣了。
2樓：
一致性有很多種，比如：
read last write consistency 寫入後全域性立即可見
eventually consistency 最終達成一致要做到eventually consistency 很簡單，同步邏輯日誌即可，讓邏輯日誌（比如binlog）和資料保持強一致，很多資料庫都有這樣的特性，然後把邏輯日誌同步給其他的資料庫
要做到寫入後全域性可見，就會難很多，可以想到的辦法都是不再大規模的搞多個不同的資料庫儲存來做消費下游，因為不同的轉儲成本相當高昂，要做到一致寫入，會導致latency不可接受
3樓：程墨Morgan
方法很多，用什麼方法完全根據實際需求來決定。
如果要實現強一致性，那就要動用類似Paxos這樣的達成分布式一致的協議，這樣實現複雜，而且要多方資料儲存都遵守同乙個協議，對於絕大部分應用，真犯不著實現這樣的強一致性。
如果只要實現最終一致(eventual consistency)，事情就簡單多了。
最簡單的是Saga模式，也就是任何乙個動作，都要有乙個Undo的動作，比如給你扣了100塊錢，也可以給你補100塊錢，給了你10000積分，也可以有動作扣你10000積分，所有的操作有Do和Undo之後，分布式的動作抽象一點就是像下圖這樣：
1、2、3、4是Do的動作，1』、2『、3』、4『對應的是Undo的動作，如果一切順利，就和藍色箭頭標示的一樣，1、2、3、4依次做完，但1做完的時候，4還沒有做，如果1是扣款，4是增加積分，那就是有那麼一段時間錢扣了，但是積分沒有增加，但正常最終積分還是會到賬的，這就是『最終一致性』。
如果中間有乙個步驟失敗了，比如4號動作失敗了，那就走下面那一行，因為已經做了1、2、3了，先做3』，把3做的事情取消掉，然後把2『、1』的事情做了，把之前1、2、3做過的事情Undo掉，補償掉，給你扣了的錢補回來。
這就是Saga模式。
還有一種方式，就是TCC(Try-Commit-Cancel)，就是每個儲存服務都暴露三個介面Try、Commit和Cancel，比如對於扣款，Try只是把錢先凍結住，並不真的扣款，只有當Commit呼叫的時候才真的扣款，如果Cancel被呼叫或者長時間Commit不被呼叫而超時，就把凍結的扣款解封了。
如下圖，有乙個Transaction Manager是大Boss，它負責協調各個實現了TCC的儲存服務。
簡化一點，假設只有A和B兩個服務，正常呼叫順序是
Try A
Try B
Commit A
Commit B
如果中途發現有問題，比如Commit B失敗了，就呼叫Cancel A，這樣Try A的事情就取消掉了。
TCC和Saga有一點點類似，主要區別就是，Saga裡每個動作都是立竿見影的，而TCC不是，距離來說，Saga裡乙個動作扣了你的錢就是真的少了你的錢，TCC裡Try只是凍結你的錢，Commit之後才是真的扣你錢。
更進一步，如果有乙個大家都認可的可靠的Event Bus的話，而且幾個儲存之間的處理順序不重要的話，問題就更簡單了。
A發出乙個事件（比如乙個購買動作），這個事件放到乙個可靠的佇列中，B和C都信任這個佇列，B做扣款，C做增加積分，兩者先後關係不重要，而且一定能做完（假設B扣款可以欠款），那就只要B和C從佇列裡拿任務來做就行了，即使B和C中途崩潰了也沒問題，反正佇列裡還有訊息。
這個回答只是簡單介紹了一下分布式事務的方法，具體解法可要複雜得多哈:-)
4樓：by wang
有很多書講這一塊，分布式事務，實際上只能保證最終一致性。
實現方式主要有兩階段提交at模式和saga模式，具體的實現很多書有說。
阿里有個開源的庫叫seata，專門解決分布式事務問題，文件裡面就有簡單的介紹和一些實踐的建議。你提到的問題，文件裡面都有說明（具體到扣錢的業務，seata的文件裡也有說）。
Seata 快速開始
題主問題中所描述的高可用和負載均衡則跟分布式事務是不同的問題。不在這個回答的範圍內。
所謂的架構設計也就是權衡利弊，選擇最適合場景的方案。
5樓：
系統的目標是追求最終一致性，而不是強一致。
只要最終資料完成同步和閉環，中間一定的延時和重試都是可以忍受的。
而對於無關緊要的資料，可能最終一致都要放棄。
6樓：Ivony
其實數學基礎好的話很容易看出來強一致性和分布式是衝突的。
分布式要解決的問題無非兩個，高可用和高吞吐量，強一致性天然和這兩者衝突。
前者就是CAP不可能，後者你想一下，要保證強一致性就要確保所有節點都成功才能返回成功，吞吐量怎麼可能上得去？
所以通常做法就是放棄強一致性，用最終一致性就完了，這實在是很容易想到的事情。
不知道為什麼總有人喜歡把這些簡單的道理搞的神秘兮兮的……
什麼情況下，需要使用分布式資料庫？
NebulaGraph 首先，分布式資料庫的優勢大致上概括為三種 1，資料分布儲存在不同的節點上，解決了單機下資料量的限制問題 2，分布式計算，均衡了計算負載 3，從資料安全性考慮，分布式資料庫一般都有多副本機制，以此保證了某乙個節點資料壞掉後能正常提供服務。基於以上三點，我認為海量資料的高併發業務...
如何保證分布式系統metadata資料強一致性？
Tony 乙個現在比較好的解決方案是 將meta data存放在control plane，然後data plane通過control plane來統一。對於control plane，有兩種解決方案。第一，用cluster，這時，需要選用支援強一致的系統，比如etcd和ZooKeeper 還有一些...
分布式資料庫如何實現非主鍵列的唯一約束或唯一索引？
朱翀 可以為這個非主鍵列建立乙個分布式表，表名為主表名加該非主鍵列名 table colum 這個新錶的主鍵就是主表要建立唯一約束的非主鍵列，這樣每次往主表插入資料的時候，都先查詢這張新錶，如果新錶已經存在資料就說明違反唯一約束。唯一索引的話，就是這張新錶再加一列，這一列存得就是主表的主鍵。使用該唯...