微服務的架構模式中，資料庫如何規劃？如果採用獨享資料庫，如何解決事務處理和聯合查詢？

01-13

以微服務為代表的分散式系統上，不適合事務性操作，因為分散式事務的效率非常的差。所以現在最終一致性的概念越來越受到關注。當然，最終一致性與事務操作相比，效率上有優勢，但不能時刻保持數據一致性。總體來說是為了效率，做出了一定的妥協。

簡單來說，要是對效率要求較低，可以使用兩階段提交協議，來保證分散式事務一致性。但是性能較差，不能滿足高並發場景。要是可以接受短時間的數據不一致，只要最終保證數據一致性，那就可以利用MQ等技術來提高系統的吞吐量。要是又想高效，又想分散式事務一致性，暫時沒有解決方案。

我也是剛接觸到這一塊的內容，只能分享一下我收藏的相關文章。

分散式事務？No, 最終一致性

最終一致性的另一種選擇

分散式系統事務一致性解決方案

一致性與可用性：Werner Vogels談最終一致性

消息「時序」與「一致性」為何這麼難？

如果採用微服務，那每個微服務應該有獨立的存儲方式，如果代碼邏輯分開存儲卻共享，遲早要亂套，因為誰也說不準不同服務會怎麼操作同一個存儲，而且這樣把服務耦合在一起，也失去了微服務的意義。

正因為微服務互相分割的這個特點，要實現事務，不可能再在資料庫一層實現，需要上層（應用層或者框架層）實現，比如，傳統但好使的TCC模式，每個微服務實現一個Try、一個Commit、一個Cancel介面，讓一個中控服務協調多個微服務之間的事務，通過調用Try/Commit完成事件完成，通過調用Cancel回滾事務。

差不多就是這樣。

了解更多開發知識請關注@程墨Morgan

1.為什麼採用微服務架構？

2.微服務架構強調垂直劃分優先，業務完整性。多數分散式事務問題可以繞過。

3.就算出現了這個問題，一致性包括：強一致性，弱一致性，最終一致性，最終一致性又包括了順序一致性（例如微博、微信），讀寫一致性等等...你的場景未必是強一致性。例如銀行轉賬是強一致性嗎？其實是最終一致性，中間有不一致的時間窗口。

4.如果出現了要求強一致性的地方，可以2pc，tcc。問題是有鎖，性能低，沒有大規模成功案例。成本高。

本質上，還是要看業務場景，綜合權衡！

首先微服務不是碎服務

別什麼都拆開

真的有需要分散式事務的一般是2/3pc

這裡假設你是mysql

聯合查詢在互分散式資料庫裡面本來就很難做

互聯網服務幾乎不會使用聯合查詢