分佈式事務介紹

公司創立之初，一個web服務和一個數據庫實例便可知足戶需求。隨着業務量的增加，性能問題就會愈來愈突出。架構因而變成了多個web服務，和一個讀寫分離的數據庫羣( 主多從)，這種架構或許也能 撐上千萬的用戶。但隨着進一步發展，會發現業務複雜度愈來愈高 ，耦合也比較嚴重，並且數據庫也成了性能瓶頸。這時就不得不面臨分佈式改造。將相關業務抽取成獨 的服務和獨立的數據庫。數據量的業務還要進行分庫分表的改造。這就是分佈式系統架構。

 

在分佈式系統架構中，就不得不面臨分佈式事務這一巨大挑戰。 什麼是分佈式事務?通俗點說，就是一個大的操做，調用了多個分佈在不一樣機器上的小的服務。事務要保證這些小的服務，要麼所有執行成功，要麼所有回滾。本質上來講，分佈式事務就是爲了保證不一樣數據庫的數據一致性。

 

分佈式系統的事務一致性自己就是一個讓人頭疼的難題，沒有一個簡單完美的解決方案可以適 於全部業務場景。在一致性，高性能和易用性方面 ，每每三者很難兼得。

 

首先，一致性，一個大的操做結束，保證全部小的操做數據協同一致。這裏說的是一致指的是強一致性。目前大部分互聯網公司的分佈式事務解決方案，採用的是最終一致性。大都是經過結合消息中間件來實現。好比說，A、B在一個操做事務裏，A調用成功後發送一個消息到消息隊列，另外一個消費任務負責消費消息，而後執行B操做。這裏有個問題就是，消息可能被重複消費，因此B操做須要支持冪等性調用，消費任務會一直調用B，直到成功爲止，必要時候還須要人工介入。不得不認可，最終一致性是由於解決不了高性能強一致的無奈之舉。

 

其次，高性能。性能不好，天然就沒有實用價值。業界也有像兩步提交這樣的解決方案，如XA。可是並無什麼知名互聯網公司在使用 ，究其緣由仍是性能問題嚴重，多數企業沒法接受。因此他們更願意轉而求其次，使用最終一致性解決方案，或者放棄事務人工訂正。

 

最後，易用性。若是非要追求強一致性和高性能，就不得不進行特殊場景特殊處理。但一般會要求業務開發者遵照必定的規則，對業務侵入性很強，也帶來了很大的開發成本。好比有的 案要求數據庫操做必須寫成存儲過程，有的方案要求必須實現它的一堆接口，有的方案必須侵 入業務按照它的套路改造，等等。這都給產品開發、升級、運維帶來困難。理想的方案是對業務無侵入，業務與事務分離，用戶開發僅須要關注於業務自己，事務方面須要作的只是界定事務邊界，事務一致性交給事務中間件處理。

 

看到這裏，你確定知道：什麼是分佈式事務，分佈式事務爲何那麼難解決。因此，若是初入職場者，面試中被問到分佈式事務時，不用慌張，這原本就是個世界難題，答不上來也沒必要灰心，甚至你還能夠反問面試官:大家是怎麼解決的。