在分布式系統中，如何基于業務方面的考量、將RESTful與MQ(消息中間件)結合、解決事務完整性/數據一致性問題的架構設計。

一、面向業務考量的最終一致性方案考慮

這里先舉兩個例子。

1、支付寶的“WS Transaction標準”嘗試：

支付寶在他們的分布式系統中為解決事務完整性的問題，曾經嘗試過WS Transaction標準，但是經過實際做測試，最后發現成本實在是太高了。完成一個事務，為確保事務完整性，20多條的消息的交互，其中只有1條是業務消息，其他都是系統之間的協議消息。這就會導致客戶端響應太慢，客戶無法承受這樣的性能。

2、Ebay架構師的最終一致性方案：

來自Ebay的架構師根據他們的最佳實踐給出過解決方案。就是關于數據一致性的，比如他們的分布式存儲如何保持數據一致性。其中探討了“實時一致”與“嚴格事務”之間的悖論，他們采用了局部實時一致、全局最終一致的解決方案。在這里就需要從業務上辨別哪些操作是可以放寬的(允許不在一個事務中)，哪些操作必須是原子性的?，F在Ebay的整個架構就是基于“最終一致性”的，支付寶也從中受到啟發，沿用該設計思路解決了“客戶端迅速響應”和“服務端數據一致”的矛盾。

故考慮系統架構設計的時候，不僅僅考慮技術，也把業務因素考慮進來，面向業務考量進行系統設計，會讓我們在技術上做出更合理的抉擇?；跇I務考慮，有利于得出事務的優先級別，也有利于作出架構設計上的最佳取舍。通常來說銀行、證券系統的事務完整性(或者說數據一致性)具有絕對優先級，也就要求絕對嚴格的實時保證。而通訊系統在事務完整性(或者說數據一致性上)的優先級別上甚至沒有支付寶和Ebay高，這兩者都有復雜的帳務交易。如果他們也認為局部實時一致、全局最終一致就能夠滿足業務的要求，那么自然在通訊系統中也有其可行性。

二、Restful與MQ技術適用場景分析

一般而言Restful技術架構為對客戶端開放的一組資源服務。在分布式系統中既有客戶端與服務器之間的交互，又有服務器與服務器之間的交互。比如說XCAP協議就是標準的Restful風格的接口，提供客戶端遠程操作XML文檔的服務，而“運營管理系統”調用其他業務系統接口，用以管理用戶可被分配的服務以及權限等，則是服務器之間的信息交互。前者當然適合Restful風格的技術接口，后者個人更傾向于異步的、基于消息的通信方式。因為客戶端與服務器通常是跨越互聯網的，而服務器與服務器之間可能位于一個局域網內，甚至可能被安放在同一個機房。

我們知道Restful風格的技術架構通常是通過JSON或者XML等進行信息的傳遞，總之都是通過“字符串格式”的封裝進行信息傳遞。通過字符格式交互信息在使用上帶來簡便的同時，因為封裝、解析、轉換等過程使其在性能自然要付出一些代價，如果是服務器之間在更底層同類協議之間的數據交互性能就要高的多。這里順便提到信息交互在不同場景下的性能順序，按照從快到慢排序：

1、同一進程之間的信息交互；

2、同一機器兩個進程之間的信息交互；

3、兩個分布機器之間的信息交互。

因為HTTP是在TCP/IP協議之上的包裝，WebService是在HTTP協議之上的包裝，根據越低層協議之間的信息交互越高效的特征，從協議級由快到慢排序：

1、基于TCP/IP協議的信息交互；

2、基于HTTP協議的信息交互；

3、基于WebService協議的信息交互。

另外，因為“運營管理系統”與其他系統之間是直接交互的，比如運營要給某個用戶開通某些特定服務，那就要分別調用提供這幾個服務的業務系統的“細粒度”接口。一旦增加新的服務，也勢必影響到運營管理系統的修改。我們說在分布式系統中有個原則，盡可能設計“粗粒度”接口，以減少系統之間的網絡交互。如果在運營管理系統與其他業務系統之間由“消息中間件”來進行信息交互，那么：

1、運營管理系統可以設計面向服務的“粗粒度”接口，開通幾個服務只需要把幾種類型的數據封裝在一起，一次性傳遞給MQ。增加服務也只不過增加一種數據類型而已；

2、MQ可以保證消息最終一定會被接收、處理。因為MQ可以實現基于“訂閱-通知”的Event-Driven機制，業務系統只要在MQ中注冊自己，就可以實時收到來自MQ的消息。即使出現系統或者網絡異常，消息也會被MQ中間件持久化，一旦業務系統恢復，消息馬上會被發往業務系統，這顯然比目前采用的每隔一段時間掃描一次數據庫要高效的多。

三、MQ與最終一致性

MQ消息隊列技術是分布式應用間交換信息的一種技術。消息隊列可駐留在內存或磁盤上，隊列存儲消息直到它們被應用程序讀走。通過消息隊列，應用程序可獨立地執行——它們不需要知道彼此的位置、或在繼續執行前不需要等待接收程序接收此消息。它為構造異步方式實現的分布式應用提供了松耦合方法，在應用中以執行多種功能，比如要求服務、交換信息或異步處理等。

在分布式系統中，尤其是不同語言的分布式系統中，如果沒有消息中間件完成信息交換，應用開發者為了高效傳輸數據，就要編寫相應語言的應用程序來發送和接收信息，且交換信息沒有標準方法，每個應用必須進行特定的編程從而和多平臺、不同環境下的一個或多個應用通信。

假如系統可以采用數據“局部實時一致、全局最終一致”的方案，就可以選擇不需要支持事務的MQ中間件，因為其可以保證：即使在系統異常、網絡異常等特殊情況下，消息也會被持久化，當系統恢復，消息馬上會被處理，也即最終一定會被接受處理，也就是最終一致。而不需要支持事務的MQ性能及吞吐率都會很高。

總之，個人傾向于用 Restful對客戶端提供服務，服務器之間引入MQ服務，建立異步的、基于消息的信息交互方式，并基于數據局部實時一致、全局最終一致的原則，來解決事務問題

總結

以上是生活随笔為你收集整理的php分布式数据一致性,如何解决分布式系统数据事务一致性问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。