公司創立之初，一個web服務和一個資料庫實例即可滿足戶需求。隨著業務量的增長，性能問題就會越來越突出。架構於是變成了多個web服務，和一個讀寫分離的資料庫群( 主多從)，這種架構或許也能 撐上千萬的用戶。但隨著進一步發展，會發現業務複雜度越來越高 ，耦合也比較嚴重，而且資料庫也成了性能瓶頸。這時就不 ...
公司創立之初，一個web服務和一個資料庫實例即可滿足戶需求。隨著業務量的增長，性能問題就會越來越突出。架構於是變成了多個web服務，和一個讀寫分離的資料庫群( 主多從)，這種架構或許也能 撐上千萬的用戶。但隨著進一步發展，會發現業務複雜度越來越高 ，耦合也比較嚴重，而且資料庫也成了性能瓶頸。這時就不得不面臨分散式改造。將相關業務抽取成獨 的服務和獨立的資料庫。數據量的業務還要進行分庫分表的改造。這就是分散式系統架構。
在分散式系統架構中，就不得不面臨分散式事務這一巨大挑戰。 什麼是分散式事務?通俗點說，就是一個大的操作，調用了多個分佈在不同機器上的小的服務。事務要保證這些小的服務，要麼全部執行成功，要麼全部回滾。本質上來說，分散式事務就是為了保證不同資料庫的數據一致性。
分散式系統的事務一致性本身就是一個讓人頭疼的難題，沒有一個簡單完美的解決方案能夠適 於所有業務場景。在一致性，高性能和易用性方面 ，往往三者很難兼得。
首先，一致性，一個大的操作結束，保證所有小的操作數據協同一致。這裡說的是一致指的是強一致性。目前大部分互聯網公司的分散式事務解決方案，採用的是最終一致性。大都是通過結合消息中間件來實現。比如說，A、B在一個操作事務里，A調用成功後發送一個消息到消息隊列，另一個消費任務負責消費消息，然後執行B操作。這裡有個問題就是，消息可能被重覆消費，所以B操作需要支持冪等性調用，消費任務會一直調用B，直到成功為止，必要時候還需要人工介入。不得不承認，最終一致性是因為解決不了高性能強一致的無奈之舉。
其次，高性能。性能很差，自然就沒有實用價值。業界也有像兩步提交這樣的解決方案，如XA。但是並沒有什麼知名互聯網公司在使用 ，究其原因還是性能問題嚴重，多數企業無法接受。所以他們更願意轉而求其次，使用最終一致性解決方案，或者放棄事務人工訂正。
最後，易用性。如果非要追求強一致性和高性能，就不得不進行特殊場景特殊處理。但通常會要求業務開發者遵守一定的規則，對業務侵入性很強，也帶來了很大的開發成本。比如有的 案要求資料庫操作必須寫成存儲過程，有的方案要求必須實現它的一堆介面，有的方案必須侵 入業務按照它的套路改造，等等。這都給產品開發、升級、運維帶來困難。理想的方案是對業務無侵入，業務與事務分離，用戶開發僅需要關註於業務本身，事務方面需要做的只是界定事務邊界，事務一致性交給事務中間件處理。
看到這裡，你肯定知道：什麼是分散式事務，分散式事務為什麼那麼難解決。所以，如果初入職場者，面試中被問到分散式事務時，不用慌張，這本來就是個世界難題，答不上來也不必灰心，甚至你還可以反問面試官:你們是怎麼解決的。
