分散式的系統有很多種，通常情況下，我們的業務系統有資料儲存分散式的，也有應用程式分散式的，不同的場景會應用到不同的分散式解決方案。

你這個問題提到了訪問到舊資料，感覺像是資料庫讀寫分離或者是主從機的場景。通常我們對於資料庫主從設計，都是設定一臺主庫資料庫伺服器，一臺或多臺庫資料庫伺服器，透過資料庫日誌訂閱的模式進行資料同步。我們的系統也是寫操作在主庫進行，讀操作在從庫進行。

而這種方式中，主庫和從庫之間的資料同步會需要一定的時間，所以很大機率會出現寫入主庫的資料還沒有同步到從庫，使用者就去讀資料了，往往讀出來的就是舊資料。

那麼這種情況怎麼來避免呢？

其實解決方案也有不少，主要看我們的場景是什麼，然後考慮如何應用。

這種實現方式非常簡單，我們的資料庫同步就自帶了此功能。當我們的寫請求到主庫以後，主庫先自己把資料儲存好，但是並不返回，而是等待從庫同步，從庫同步完成後，主庫再告訴我們的應用程式資料儲存成功。

使用這種方式的話，我們不需要修改任何的程式碼，資料庫原本就帶有這樣的功能，配置也非常方便。但是不好的就是，我們的寫請求時間會變長，鎖表的時間也會增加，這會導致資料執行效率下降、吞吐量也就降低了。

快取是一個好東西，在我們的各個業務場景都大量的使用。而快取也可以用來保證讀寫分離以後的資料一致性。

方法其實也比較簡單，就是我們在資料Commit成功以後，讓快取裡面寫入一條資料，我們的讀並不直接作用到從庫，而是作用到快取上，這樣就能夠保證使用者每次讀取出來的資料都是最新的了。

不過，這裡有一個問題，就是如果我們在一個事務裡面進行了寫操作，事務提交之前去讀這個資料的話，如果去讀快取，就會讀到舊的資料，可能導致我們的業務失敗。所以，我們這裡需要做一個處理，如果在事務裡面讀的話，我們需要讀寫庫。只有沒有事務的讀，才會讀快取，這樣就可以防止這種情況了。

當然，關於資料庫快取的一致性保證，其實是一個比較複雜的場景，還有很多的問題在裡面，也有很多的解決方案。不管如何，使用這種方式的話，首先是需要增加裝置成本——快取伺服器，其次就是程式碼需要進行改動，業務邏輯複雜度也會提高。