分布式系統(tǒng)中客戶訪問到不一致窗口的舊數(shù)據(jù)怎么處理？

分布式的系統(tǒng)有很多種，通常情況下，我們的業(yè)務(wù)系統(tǒng)有數(shù)據(jù)存儲(chǔ)分布式的，也有應(yīng)用程序分布式的，不同的場(chǎng)景會(huì)應(yīng)用到不同的分布式解決方案。

你這個(gè)問題提到了訪問到舊數(shù)據(jù)，感覺像是數(shù)據(jù)庫讀寫分離或者是主從機(jī)的場(chǎng)景。通常我們對(duì)于數(shù)據(jù)庫主從設(shè)計(jì)，都是設(shè)置一臺(tái)主庫數(shù)據(jù)庫服務(wù)器，一臺(tái)或多臺(tái)庫數(shù)據(jù)庫服務(wù)器，通過數(shù)據(jù)庫日志訂閱的模式進(jìn)行數(shù)據(jù)同步。我們的系統(tǒng)也是寫操作在主庫進(jìn)行，讀操作在從庫進(jìn)行。

而這種方式中，主庫和從庫之間的數(shù)據(jù)同步會(huì)需要一定的時(shí)間，所以很大概率會(huì)出現(xiàn)寫入主庫的數(shù)據(jù)還沒有同步到從庫，用戶就去讀數(shù)據(jù)了，往往讀出來的就是舊數(shù)據(jù)。

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

其實(shí)解決方案也有不少，主要看我們的場(chǎng)景是什么，然后考慮如何應(yīng)用。

最簡(jiǎn)單的就是半同步復(fù)制（semi-sync）

這種實(shí)現(xiàn)方式非常簡(jiǎn)單，我們的數(shù)據(jù)庫同步就自帶了此功能。當(dāng)我們的寫請(qǐng)求到主庫以后，主庫先自己把數(shù)據(jù)保存好，但是并不返回，而是等待從庫同步，從庫同步完成后，主庫再告訴我們的應(yīng)用程序數(shù)據(jù)保存成功。

使用這種方式的話，我們不需要修改任何的代碼，數(shù)據(jù)庫原本就帶有這樣的功能，配置也非常方便。但是不好的就是，我們的寫請(qǐng)求時(shí)間會(huì)變長(zhǎng)，鎖表的時(shí)間也會(huì)增加，這會(huì)導(dǎo)致數(shù)據(jù)執(zhí)行效率下降、吞吐量也就降低了。

如果我們對(duì)效率比較看重，那么可以使用這種方式——緩存

緩存是一個(gè)好東西，在我們的各個(gè)業(yè)務(wù)場(chǎng)景都大量的使用。而緩存也可以用來保證讀寫分離以后的數(shù)據(jù)一致性。

方法其實(shí)也比較簡(jiǎn)單，就是我們?cè)跀?shù)據(jù)Commit成功以后，讓緩存里面寫入一條數(shù)據(jù)，我們的讀并不直接作用到從庫，而是作用到緩存上，這樣就能夠保證用戶每次讀取出來的數(shù)據(jù)都是最新的了。

不過，這里有一個(gè)問題，就是如果我們?cè)谝粋€(gè)事務(wù)里面進(jìn)行了寫操作，事務(wù)提交之前去讀這個(gè)數(shù)據(jù)的話，如果去讀緩存，就會(huì)讀到舊的數(shù)據(jù)，可能導(dǎo)致我們的業(yè)務(wù)失敗。所以，我們這里需要做一個(gè)處理，如果在事務(wù)里面讀的話，我們需要讀寫庫。只有沒有事務(wù)的讀，才會(huì)讀緩存，這樣就可以防止這種情況了。

當(dāng)然，關(guān)于數(shù)據(jù)庫緩存的一致性保證，其實(shí)是一個(gè)比較復(fù)雜的場(chǎng)景，還有很多的問題在里面，也有很多的解決方案。不管如何，使用這種方式的話，首先是需要增加設(shè)備成本——緩存服務(wù)器，其次就是代碼需要進(jìn)行改動(dòng)，業(yè)務(wù)邏輯復(fù)雜度也會(huì)提高。