分布式事務就是把乙個包含多個操作步驟的業務操作（這些操作往往是由不同的應用系統來完成的）作為乙個整體來對待，要麼都成功，要麼都失敗。問題是各個操作步驟在不同的業務系統中進行操作，網路速度，系統故障等各種因素都有可能影響操作結果，必須採取有效方法來達到事務的目的。
所謂的原子性就是說，在整個事務中的所有操作，要麼全部完成，要麼全部不做，沒有中間狀態。對於事務在執行中發生錯誤，所有的操作都會被回滾，整個事務就像從沒被執行過一樣。
事務的執行必須保證系統的一致性，就拿轉賬為例，a有500元，b有300元，如果在乙個事務裡a成功轉給b50元，那麼不管併發多少，不管發生什麼，只要事務執行成功了，那麼最後a賬戶一定是450元，b賬戶一定是350元。
所謂的隔離性就是說，事務與事務之間不會互相影響，乙個事務的中間狀態不會被其他事務感知。
所謂的永續性，就是說一單事務完成了，那麼事務對資料所做的變更就完全儲存在了資料庫中，即使發生停電，系統宕機也是如此。
分布式事務，本質上是對多個資料庫的事務進行統一控制，按照控制力度可以分為：不控制、部分控制和完全控制。不控制就是不引入分布式事務，部分控制就是各種變種的兩階段提交，包括上面提到的訊息事務+最終一致性、tcc模式，而完全控制就是完全實現兩階段提交。部分控制的好處是併發量和效能很好，缺點是資料一致性減弱了，完全控制則是犧牲了效能，保障了一致性，具體用哪種方式，最終還是取決於業務場景。作為技術人員，一定不能忘了技術是為業務服務的，不要為了技術而技術，針對不同業務進行技術選型也是一種很重要的能力
分布式事務的簡單理解
單獨的系統中，事務是本地事務。而在分布式系統中，乙個業務的完成需要及多個系統，需要涉及多個資料來源。比如訂單系統，下訂單這個業務需要涉及支付系統，庫存系統，物流系統等，假如庫存系統出現問題，事務回滾，那麼其他子系統的事務也必須回滾，否則就會出現事務不一致，導致下訂單操作出現錯誤。多個資料來源，就需要...
談談自己對分布式的理解
現在常用的開源分布式框架乙個是阿里開源的dubbo，還有乙個就是spring cloud 最初的服務化解決方案是 相同服務提供乙個統一的網域名稱，然後客戶端傳送http請求，由nginx負責請求分發和跳轉，耦合了服務呼叫邏輯，相當於乙個重量級的esb 有以下幾個缺點 1 作為消費者不知道由哪個服務例...
分布式事務的理解
當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務化。比如原來單機...