詳解服務器框架中的分布式緩存

2021-03-09    分類： 網(wǎng)站建設

概述

在分布式程序架構中，如果我們需要整個體系有更高的穩(wěn)定性，能夠對進程容災或者動態(tài)擴容提供支持，那么最難解決的問題，就是每個進程中的內存狀態(tài)。因為進程一旦毀滅，內存中的狀態(tài)會消失，這就很難不影響提供的服務。所以我們需要一種方法，讓進程的內存狀態(tài)，不太影響整體服務，甚至最好能變成“無狀態(tài)”的服務。當然“狀態(tài)”如果不寫入磁盤，始終還是需要某些進程來承載的。這個也是今天分享的主題--分布式緩存。

“分布式緩存”策略

在現(xiàn)在流行的WEB開發(fā)模式中，很多人會使用PHP+Memcached+MySQL這種模型，在這里，PHP就是無狀態(tài)的，因為狀態(tài)都是放在Memcached里面。這種做法對于PHP來說，是可以隨時動態(tài)的毀滅或者新建，但是Memcached進程就要保證穩(wěn)定才行；而且Memcached作為一個額外的進程，和它通信本身也會消耗更多的延遲時間。因此我們需要一種更靈活和通用的進程狀態(tài)保存方案，我們把這種任務叫做“分布式緩存”的策略。我們希望進程在讀取數(shù)據(jù)的時候，能有高的性能，最好能和在堆內存中讀寫類似，又希望這些緩存數(shù)據(jù)，能被放在多個進程內，以分布式的形態(tài)提供高吞吐的服務，其中最關鍵的問題，就是緩存數(shù)據(jù)的同步。

PHP常用Memached做緩存

為了解決這個問題，下面一步步來分解這個問題：

1、哈希表

首先緩存應該是某種特定形式的對象，而不應該是任意類型的變量。因為需要對這些緩存進行標準化的管理，盡管C++語言提供了運算重載，可以對“=”號的寫變量操作進行重新定義，但是現(xiàn)在基本沒有人推薦去做這樣的事。而哈希表剛好適合緩存這種概念的使用。

所有的哈希表（或者是Map接口），都是把數(shù)據(jù)的存放，分為key和value兩個部分，我們可以把想要緩存的數(shù)據(jù)，作為value存放到“表”當中，同時我們也可以用key把對應的數(shù)據(jù)取出來，而“表”對象就代表了緩存。

2、讓“表”在多個進程中都存在

其次需要讓這個“表”能在多個進程中都存在。如果每個進程中的數(shù)據(jù)都毫無關聯(lián)，那問題其實就非常簡單，但是如果從A進程把數(shù)據(jù)寫入緩存，然后在B進程把數(shù)據(jù)讀取出來，那么就比較復雜了?？傊氨怼币心馨褦?shù)據(jù)在A、B兩個進程間同步的能力。因此一般會用三種策略：租約清理、租約轉發(fā)、修改廣播。

租約清理

租約清理，一般是指，我們把存放某個key的緩存的進程，稱為持有這個key的數(shù)據(jù)的“租約”，這個租約要登記到一個所有進程都能訪問到的地方，比如是ZooKeeper集群進程。那么在讀、寫發(fā)生的時候，如果本進程沒有對應的緩存，就先去查詢一下對應的租約，如果被其他進程持有，則通知對方“清理”，所謂“清理”，往往是指刪除用來讀的數(shù)據(jù)，回寫用來寫的數(shù)據(jù)到數(shù)據(jù)庫等持久化設備，等清理完成后，在進行正常的讀寫操作，這些操作可能會重新在新的進程上建立緩存。這種策略在緩存命中率比較高的情況下，性能是最好的，因為一般無需查詢租約情況，就可以直接操作；但如果緩存命中率低，那么就會出現(xiàn)緩存反復在不同進程間“移動”，會嚴重降低系統(tǒng)的處理性能。

租約轉發(fā)

一般把存放某個KEY的緩存的進程，稱為持有這個KEY數(shù)據(jù)的“租約”，同時也要登記到集群的共享數(shù)據(jù)進程中。和上面租約清理不同的地方在于，如果發(fā)現(xiàn)持有租約的進程不是本次操作的進程，就會把整個數(shù)據(jù)的讀、寫請求，都通過網(wǎng)絡“轉發(fā)”個持有租約的進程，然后等待他的操作結果返回。這種做法由于每次操作都需要查詢租約，所以性能會稍微低一些；但如果緩存命中率不高，這種做法能把緩存的操作分擔到多個進程上，而且也無需清理緩存，這比租約清理的策略適應性更好。

修改廣播

上面兩種策略，都需要維護一份緩存數(shù)據(jù)的租約，但是本身對于租約的操作，就是一種比較耗費性能的事情。所以有時候可以采用一些更簡單，但可能承受一些不一致性的策略：對于讀操作，每個節(jié)點的讀都建立緩存，每次讀都判斷是否超過預設的讀冷卻時間x，超過則清理緩存從持久化重建；對于寫操作，每個節(jié)點上都判斷是否超過預設的寫冷卻時間y，超過則展開清理操作。

清理操作也分兩種，如果數(shù)據(jù)量小就廣播修改數(shù)據(jù)；如果數(shù)據(jù)量大就廣播清理通知回寫到持久化中。這樣雖然可能會有一定的不一致風險，但是如果數(shù)據(jù)不是那種要求太高的，而且緩存命中率又能比較有保障的話（比如根據(jù)KEY來進行一致性哈希訪問緩存進程），那么真正因為寫操作廣播不及時，導致數(shù)據(jù)不一致的情況還是會比較少的。這種策略實現(xiàn)起來非常簡單，無需一個中心節(jié)點進程維護數(shù)據(jù)租約，也無需復雜的判斷邏輯進行同步，只要有廣播的能力，加上對于寫操作的一些配置，就能實現(xiàn)高效的緩存服務。

所以“修改廣播”策略是在大多數(shù)需要實時同步，但數(shù)據(jù)一致性要求不高的領域最常見的手段。著名的DNS系統(tǒng)的緩存就是接近這種策略：我們要修改某個域名對應的IP，并不是立刻在全球所有的DNS服務器上生效，而是需要一定時間廣播修改給其他服務區(qū)。而我們每個DSN服務器，都具備了大量的其他域名的緩存數(shù)據(jù)。

總結

在高性能的服務器架構中，常用的緩存和分布兩種策略，往往是結合到一起使用的。雖然這兩種策略，都有無數(shù)種不同的表現(xiàn)形式，成為各種各樣的技術流派，但是只有清楚的理解這些技術的原理，并且和實際的業(yè)務場景結合起來，才能真正的做出滿足應用要求的高性能架構。

網(wǎng)站題目：詳解服務器框架中的分布式緩存
網(wǎng)址分享：http://www.bm7419.com/news/104900.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供響應式網(wǎng)站、域名注冊、網(wǎng)站制作、網(wǎng)站策劃、網(wǎng)站排名、網(wǎng)頁設計公司

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)

成都做網(wǎng)站