探討篇（四）：分布式數(shù)據(jù)訪問解決方案

背景

如果數(shù)據(jù)在同一個服務(wù)的同一個數(shù)據(jù)庫，通過SQL即可查詢相對比較簡單，但當數(shù)據(jù)被分布到不同服務(wù)不同的數(shù)據(jù)庫中時，訪問組合數(shù)據(jù)的操作就變的比較困難。針對這個問題，本文描述了服務(wù)讀取不同服務(wù)的數(shù)據(jù)庫的幾種方法：服務(wù)間通信模式、數(shù)據(jù)緩存模式、數(shù)據(jù)復(fù)制模式、數(shù)據(jù)共享模式

本文的觀點源自我在日常學(xué)習(xí)與實踐過程中的思考，尚處于不斷探索和驗證的階段。希望能“拋磚引玉”，激發(fā)更多的討論與交流。讓我們共同進步，在探討與實證中尋求真知。

一、服務(wù)通信模式

如果一個服務(wù)需要讀取它無法直接訪問的數(shù)據(jù)庫，只需要使用遠程調(diào)用比如RPC協(xié)議訪問另外一個服務(wù)即可，這也是很多團隊采用的一種方式，如下圖：

這看起來很簡單，但技術(shù)充滿挑戰(zhàn)問題

?首先是數(shù)據(jù)網(wǎng)絡(luò)延遲導(dǎo)致服務(wù)A性能下降。

?服務(wù)之間的耦合，為了滿足服務(wù)A的訪問量，B服務(wù)必須隨著A服務(wù)的流量規(guī)模變化而變化。

二、數(shù)據(jù)緩存模式

在上面服務(wù)通信的基礎(chǔ)上加上緩存，這是很多團隊使用的第二種方式。數(shù)據(jù)保存在每個服務(wù)的內(nèi)存中并持續(xù)同步，因此服務(wù)擁有完全相同的數(shù)據(jù)。緩存又分為本地緩存+分布式緩存的組合關(guān)系。

1.單機本地緩存，每個服務(wù)都包含自己的數(shù)據(jù)。這種模式對應(yīng)服務(wù)之間無法共享，比如服務(wù)啟動加載數(shù)據(jù)到本地緩存。

2.分布式緩存：數(shù)據(jù)服務(wù)之間共享。但這種模式不是有效的復(fù)制緩存模式，因為它不能解決服務(wù)間通信模式下存在的容錯性問題，獲取數(shù)據(jù)從服務(wù)調(diào)用變成了緩存服務(wù)。其次由于緩存數(shù)據(jù)是中心化及共享的，打破數(shù)據(jù)所有權(quán)，并且可能導(dǎo)致緩存和數(shù)據(jù)庫數(shù)據(jù)不一致。

以下是每種實現(xiàn)方式優(yōu)缺點如下：

實現(xiàn)方式一：本地緩存/分布式緩存+RPC遠程調(diào)用

實現(xiàn)方式二：通過RPC服務(wù)通訊同步推送數(shù)據(jù)+本地緩存

實現(xiàn)方式三：通過定時任務(wù)worker，服務(wù)A通過RPC調(diào)用服務(wù)B拉數(shù)據(jù)

實現(xiàn)方式四：通過異步MQ獲取數(shù)據(jù)

緩存模式優(yōu)缺點：

三、數(shù)據(jù)復(fù)制模式

在數(shù)據(jù)復(fù)制模式中，表之間會進行數(shù)據(jù)復(fù)制，也就是在數(shù)據(jù)庫A冗余數(shù)據(jù)庫B數(shù)據(jù)。這樣可以確保服務(wù)A直接訪問數(shù)據(jù)庫A獲取到數(shù)據(jù)庫B的數(shù)據(jù)?？梢酝ㄟ^很多種實現(xiàn)方式：

但這同樣存在如下問題:如何管理數(shù)據(jù)所有權(quán)？到處都有這種數(shù)據(jù)，數(shù)據(jù)一致性問題

這種方案改善了上面服務(wù)通信的性能，容錯性，可伸縮性問題。某些場景可用，比如聚合，報表或者其他不適合高性能需求，高容錯性的時候

四、數(shù)據(jù)共享模式

如果上面的3種方式都不行，那可以用兜底方式，用創(chuàng)建數(shù)據(jù)領(lǐng)域，把數(shù)據(jù)組合到共享的數(shù)據(jù)庫，讓服務(wù)A和服務(wù)B都能訪問。

服務(wù)之間完全解耦，解決了可用性依賴，響應(yīng)性，吞吐量和可伸縮性問題

總結(jié)

1.通過本文的探討，大家可以更全面地了解分布式數(shù)據(jù)訪問的挑戰(zhàn)和可能的解決方案

2.每種模式都有其優(yōu)勢和不足以及應(yīng)用場景，本文旨在通過對比分析，為實際應(yīng)用中的選擇提供指導(dǎo)。

3.如果以上文案有問題或者還有更好的方案，歡迎評論區(qū)留言補充完善，謝謝

審核編輯 黃宇