資料親和架構強調資料和應用的繫結，這意味著，同一份資料是分佈在多個服務的記憶體中，因此係統是分散式架構。關於分散式系統中，如何管理資料一致性的討論和文章已經夠多了，在此沒有必要花太多文字複述一遍。這裡更多的是從實踐的角度來分析資料一致性問題。

        在一個程序中，多個執行緒對同一個資料修改，順序不同，會導致最終結果的不同。鎖的機制實際上就確保執行緒按照順序對資料進行修改，使得結果符合預期，但不能確保最終結果是一致的。如果將這些修改操作序列化，除非資料與時間、順序有關，則結果將最終一致。

        分散式系統的一致性在技術上遠比多執行緒複雜，跨程序跨網路操作遠端資料，失敗是常態，因此要確保修改成功，需要引入多次確認。根據CAP原則，最終一致性是分散式系統的普遍選擇，因為從業務角度來看，只要在需要的時候，資料是一致就可以了，必須強一致性的應用場景實際上並沒有那麼普遍。

操作序列化，對確保最終一致性，甚至強一致性，是基本手段，而訊息佇列則是這種系統設計的最佳實踐。但我們也要注意到，並不是所有的操作都需要序列化，比如心跳，只要最後一個心跳到達，之前的所有心跳都可以忽略。

        強一致性在特定業務場景是需要的，比如常常提到的轉賬，就像資料庫提供事務，在分散式系統中，通常以分散式事務來解決。從DTS衍生出多種解決方案不再贅述。而在我看來，這種模式實在難以處理，系統也難以維護。我不反對這些理論，也贊成這些技術的發展，只是認為在工程實踐中，可以採用更簡單的方式來完成，規避這些通用解決方案帶來的技術風險。

        每個賬號天生就是分佈的，因此將對一個賬號的修改和讀寫，歸於同一服務來完成，就能夠避免分散式的難題。剩下的問題就是一個事務會被劃分到多個步驟，每個步驟由不同服務來完成，這是分散式事務要解決的問題。我們知道，影響一致性的原因在於資料的修改，以及之後的讀取。將這些操作集中在一個服務中，則這些分散式事務的難以將不復存在。

        簡單的說，對單個物件的操作事務集中在一個服務中，實現CA；而將不同物件分散在多個服務，實現分佈P。對於整個系統來看，這個方案存在通用性缺陷，但並不違反CAP原則，還帶來了強一致性和效能，具有很高的實踐價值。