在這一講，我將為你講解分布式存儲(chǔ)中“貨架”的關(guān)鍵技術(shù)——緩存技術(shù)。

[[324176]]

在計(jì)算機(jī)領(lǐng)域的各個(gè)方面，緩存都非常重要，是提升訪問性能的一個(gè)重要技術(shù)。為什么這么說(shuō)呢?

從單個(gè)計(jì)算機(jī)的體系結(jié)構(gòu)來(lái)看，內(nèi)存和處理器速度差異很大，如果不采用緩存技術(shù)，處理器的性能會(huì)受到很大的限制。

再看計(jì)算機(jī)應(yīng)用，如果不采用緩存技術(shù)，對(duì)于每個(gè)請(qǐng)求，應(yīng)用都要與后臺(tái)數(shù)據(jù)庫(kù)做一次交互，而數(shù)據(jù)庫(kù)中的數(shù)據(jù)存儲(chǔ)在磁盤上，因此每次請(qǐng)求都要和磁盤做交互，而磁盤訪問的性能很低，造成訪問延遲。

除此之外，還有網(wǎng)絡(luò)訪問，如果沒有緩存機(jī)制，每次訪問主機(jī)都要與遠(yuǎn)程機(jī)器做交互，速度又可想而知。

接下來(lái)，我們就一起打卡分布式緩存技術(shù)吧。

什么是分布式緩存?

打比方來(lái)說(shuō)，緩存技術(shù)其實(shí)就像一個(gè)水缸，平時(shí)它會(huì)存儲(chǔ)一定的水，而這些水就來(lái)自深井。如果每次都去深井打水，一方面井口比較小，導(dǎo)致一次能接收的用水請(qǐng)求有限;另一方面，井比較深，打水的工序比較復(fù)雜，導(dǎo)致所需時(shí)間比較長(zhǎng)。

而有了這個(gè)水缸，我們就不需要去深井里打水，當(dāng)水缸里沒水時(shí)，水泵會(huì)將深井里的水抽到水缸中暫時(shí)存儲(chǔ)起來(lái)。也就是說(shuō)，“緩存技術(shù)”存儲(chǔ)了滿足人們一定時(shí)間內(nèi)常用的“水量”，以提高用水效率。

在計(jì)算機(jī)領(lǐng)域，緩存技術(shù)一般是指，用一個(gè)更快的存儲(chǔ)設(shè)備存儲(chǔ)一些經(jīng)常用到的數(shù)據(jù)，供用戶快速訪問。用戶不需要每次都與慢設(shè)備去做交互，因此可以提高訪問效率。

分布式緩存就是指在分布式環(huán)境或系統(tǒng)下，把一些熱門數(shù)據(jù)存儲(chǔ)到離用戶近、離應(yīng)用近的位置，并盡量存儲(chǔ)到更快的設(shè)備，以減少遠(yuǎn)程數(shù)據(jù)傳輸?shù)难舆t，讓用戶和應(yīng)用可以很快訪問到想要的數(shù)據(jù)。這，是不是可以形象地理解為“身手鑰錢”隨身帶呢?

其實(shí)，我們通常說(shuō)的分布式數(shù)據(jù)緩存，屬于計(jì)算機(jī)應(yīng)用中的緩存的一種。而計(jì)算機(jī)應(yīng)用中的緩存，一般指內(nèi)存，即內(nèi)存存儲(chǔ)了用戶經(jīng)常訪問的數(shù)據(jù)，用戶或應(yīng)用不再需要到磁盤中去獲取相應(yīng)的數(shù)據(jù)，大幅提高訪問速度。

如下圖所示，數(shù)據(jù) A 是應(yīng)用經(jīng)常訪問的數(shù)據(jù)，而數(shù)據(jù) B 很少被應(yīng)用訪問，因此當(dāng)應(yīng)用訪問數(shù)據(jù) A 時(shí)，不需要到磁盤，而直接訪問內(nèi)存即可得到對(duì)應(yīng)的值，速度較快;相反，訪問數(shù)據(jù) B 時(shí)，由于內(nèi)存中沒有緩存數(shù)據(jù) B，所以應(yīng)用需要到磁盤中獲取對(duì)應(yīng)的值，速度較慢。

那么今天，我要與你分享的分布式數(shù)據(jù)存儲(chǔ)相關(guān)的緩存技術(shù)，就是以內(nèi)存做為磁盤的緩存。

分布式緩存原理

Redis 分布緩存原理Redis 的全稱是 Remote Dictionary Server(遠(yuǎn)程字典服務(wù)器)?？梢灾庇^地看出，它是以字典結(jié)構(gòu)將數(shù)據(jù)存儲(chǔ)在內(nèi)存中，應(yīng)用可直接到內(nèi)存讀寫 Redis 存儲(chǔ)的數(shù)據(jù)。

Redis 集群是一個(gè)典型的去中心化結(jié)構(gòu)，每個(gè)節(jié)點(diǎn)都負(fù)責(zé)一部分?jǐn)?shù)據(jù)的存儲(chǔ)，同時(shí)，每個(gè)節(jié)點(diǎn)還會(huì)進(jìn)行主備設(shè)計(jì)來(lái)提高 Redis 的可靠性，具體原理你可以再回顧下前面文章中的相關(guān)內(nèi)容。

接下來(lái)，我與你分享下，Redis 中與緩存關(guān)系最緊密的三個(gè)特性：支持多數(shù)據(jù)結(jié)構(gòu)、支持持久化和主備同步。

第一，Redis 支持多數(shù)據(jù)結(jié)構(gòu)。

Redis 是一個(gè)基于內(nèi)存的 key-value 數(shù)據(jù)庫(kù)，為了方便支持多應(yīng)用的緩存，比如緩存文本類型、數(shù)據(jù)庫(kù)的查詢結(jié)果(字段與字段對(duì)應(yīng)的值)等等，支持的數(shù)據(jù)結(jié)構(gòu)不僅有簡(jiǎn)單的 k/v 類型，還可以支持 List、Set、Hash 等復(fù)雜類型的存儲(chǔ)。

以 Hash 這種復(fù)雜類型的存儲(chǔ)為例，Redis 將 Hash 視作一個(gè)整體當(dāng)作數(shù)據(jù)庫(kù)的 value(可以是一個(gè)對(duì)象，比如結(jié)構(gòu)體對(duì)象)進(jìn)行存儲(chǔ)。如果把 Hash 結(jié)構(gòu)的整體看作對(duì)象的話，Hash 結(jié)構(gòu)里的 key-value 相當(dāng)于該對(duì)象的屬性名和屬性值。

比如，插入 Hash 數(shù)據(jù)類型的命令：HMSET test field1 “Hello” field2 “World”中，如下圖所示，test 為 key 值， field1 “Hello” field2 “World” 為 value 值，如果把整個(gè) Hash 結(jié)構(gòu)看做對(duì)象的話，則 field1、field2 類似于對(duì)象中的屬性名，“Hello”“World”類似于對(duì)象中的屬性值。

第二，Redis 支持持久化。

持久化是指，將數(shù)據(jù)從內(nèi)存這種易失性存儲(chǔ)設(shè)備中寫入磁盤，從而讓數(shù)據(jù)永久保存。Redis 中存儲(chǔ)的數(shù)據(jù)雖然是基于內(nèi)存的，但它也提供了持久化的機(jī)制，主要有兩種方式：RDB 和 AOF。

RDB(Redis DataBase)，也稱快照方式，簡(jiǎn)單來(lái)說(shuō)就是 Redis 會(huì)定時(shí)將內(nèi)存中的數(shù)據(jù)備份到磁盤中，形成一個(gè)快照，比如每天保存一下過去一周的數(shù)據(jù)。這樣當(dāng)節(jié)點(diǎn)出現(xiàn)故障時(shí)，可以根據(jù)快照恢復(fù)到不同版本的數(shù)據(jù)。這種方式有一個(gè)明顯的缺點(diǎn)，是會(huì)造成數(shù)據(jù)丟失，即當(dāng)節(jié)點(diǎn)出現(xiàn)故障時(shí)，新數(shù)據(jù)可能還未備份到磁盤中。

AOF(Append Only File)的出現(xiàn)主要彌補(bǔ)了 RDB 數(shù)據(jù)不一致的問題，其思想與上一講提到的數(shù)據(jù)庫(kù)復(fù)制技術(shù)中 binary log 類似，即記錄下 Redis 中所有的更新操作。

• 在 Redis 中，提供了三種實(shí)現(xiàn) AOF 的策略：AOF_FSYNC_NO (不同步)，即不會(huì)自動(dòng)觸發(fā)寫操作的同步;
• AOF_FSYNC_EVERYSEC (每秒同步)，即每隔一秒都會(huì)將寫操作同步到磁盤;
• AOF_FSYNC_ALWAYS (每次寫都同步)，即每次發(fā)生寫操作會(huì)立即同步到磁盤。

Redis 中默認(rèn)采用 AOF_FSYNC_EVERYSEC(每秒同步)的策略，因?yàn)檫@種策略的性能很不錯(cuò)，而且一旦出現(xiàn)故障，最多只會(huì)丟失一秒的數(shù)據(jù)。

第三，Redis 支持主備同步。

說(shuō)到主備同步，我相信你應(yīng)該想到了上一講提到的數(shù)據(jù)復(fù)制技術(shù)。在 Redis 中，采用的是異步復(fù)制技術(shù)，但 Redis 可以通過配置 min-replicas-to-write 和 min-replicas-max-lag 這兩個(gè)參數(shù)來(lái)有效地保證數(shù)據(jù)一致性。

比如，設(shè)置 min-replicas-to-write=3、min-replicas-max-lag=10，表示當(dāng)至少有 3 個(gè)備數(shù)據(jù)庫(kù)連接主數(shù)據(jù)庫(kù)的延遲時(shí)間小于 10s 時(shí)，主數(shù)據(jù)庫(kù)才可以執(zhí)行寫操作。延遲時(shí)間是從最后一次收到備數(shù)據(jù)庫(kù)的心跳開始計(jì)算，通常每秒發(fā)送一次心跳。

除了上面對(duì)寫操作的同步，在 Redis 中，還有兩種情況是需要進(jìn)行數(shù)據(jù)同步的：

• 一種情況是初次同步，即備數(shù)據(jù)庫(kù)剛啟動(dòng)時(shí)的數(shù)據(jù)同步;
• 另一種情況是，因網(wǎng)絡(luò)故障導(dǎo)致主備數(shù)據(jù)庫(kù)斷開連接，待網(wǎng)絡(luò)恢復(fù)后的備數(shù)據(jù)庫(kù)的數(shù)據(jù)同步。

針對(duì)這兩種情況，Redis 提供了兩種同步模式，即完整重同步和部分重同步。

完整重同步的流程如下所示：

當(dāng)備服務(wù)器啟動(dòng)時(shí)，會(huì)向主服務(wù)器發(fā)送 SYNC 命令;

主服務(wù)器收到命令后會(huì)生成 RDB(快照)文件，并記錄從現(xiàn)在起新執(zhí)行的寫操作;

RDB 生成后會(huì)發(fā)送給備服務(wù)器，備服務(wù)器通過 RDB 文件進(jìn)行數(shù)據(jù)更新;

更新完成后，主服務(wù)器再將新記錄的寫操作發(fā)送給備服務(wù)器，備服務(wù)器執(zhí)行完這些新記錄的寫操作，便與主服務(wù)器的數(shù)據(jù)保持一致了。

簡(jiǎn)單地說(shuō)，部分重同步就是，當(dāng)網(wǎng)絡(luò)恢復(fù)后，主數(shù)據(jù)庫(kù)將主備數(shù)據(jù)庫(kù)斷開連接之后的一系列寫操作發(fā)送給備服務(wù)器，備數(shù)據(jù)庫(kù)執(zhí)行這些寫操作，從而保證數(shù)據(jù)保持一致。

在這種方式的實(shí)現(xiàn)中，主備數(shù)據(jù)庫(kù)會(huì)共同維護(hù)一個(gè)復(fù)制偏移量，這樣主數(shù)據(jù)庫(kù)就知道應(yīng)該將哪些寫操作發(fā)給備數(shù)據(jù)庫(kù)，備數(shù)據(jù)庫(kù)同步時(shí)也知道應(yīng)該從哪里繼續(xù)執(zhí)行操作。

如圖所示，主數(shù)據(jù)庫(kù)的復(fù)制偏移量為 5000 時(shí)，向備數(shù)據(jù)庫(kù)發(fā)送了 100 個(gè)字節(jié)的數(shù)據(jù)，發(fā)送結(jié)束后復(fù)制偏移量為 5100。

此時(shí)主備數(shù)據(jù)庫(kù)連接斷開，備數(shù)據(jù)庫(kù)沒有接收到這 100 個(gè)字節(jié)的數(shù)據(jù)，等到備數(shù)據(jù)庫(kù)重新與主數(shù)據(jù)庫(kù)連接上之后，會(huì)給主數(shù)據(jù)庫(kù)發(fā)送 PSYNC 命令，并帶上自己的復(fù)制偏移量 5000，主數(shù)據(jù)庫(kù)接收到信息后，根據(jù)接收到的復(fù)制偏移量，將 5000 之后的數(shù)據(jù)發(fā)給備數(shù)據(jù)庫(kù)，從而完成數(shù)據(jù)的部分重同步。

以上，就是分布式緩存系統(tǒng) Redis 中涉及的關(guān)鍵技術(shù)，包括支持的數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)持久化方法和數(shù)據(jù)同步方法，相信通過上面的介紹，你對(duì)分布式緩存技術(shù)已經(jīng)有了一定的了解。

接下來(lái)，我再帶你學(xué)習(xí)另一個(gè)緩存數(shù)據(jù)庫(kù) Memcached。

Memcached 分布式緩存原理

與 Redis 類似，Memcached 也是一個(gè)基于內(nèi)存的高性能 key-value 緩存數(shù)據(jù)庫(kù)。Memcached 比 Redis 問世更早，也有很多公司在使用，比如 Facebook、Vox、LiveJournal 等。

其實(shí)，Memecached 的緩存原理和 Redis 類似。所以接下來(lái)的內(nèi)容，我會(huì)著重于你講述這兩個(gè)數(shù)據(jù)庫(kù)在支持的數(shù)據(jù)結(jié)構(gòu)、持久化和主備同步上的不同。這樣，你可以對(duì)比著學(xué)習(xí)這兩個(gè)數(shù)據(jù)庫(kù)，也會(huì)理解得更全面、深入些。

首先，我要先帶你了解一下 Memcached 的集群結(jié)構(gòu)。

redis 的集群結(jié)構(gòu)是每個(gè)節(jié)點(diǎn)負(fù)責(zé)一部分哈希槽，且每個(gè)節(jié)點(diǎn)可以設(shè)計(jì)主備。與 Redis 不同，Memcached 集群采用一致性哈希的思路，使用的是 Ketama 算法。該算法的主要思想就是，帶虛擬節(jié)點(diǎn)的一致性哈希算法。

在實(shí)際應(yīng)用中，每個(gè)物理節(jié)點(diǎn)對(duì)應(yīng) 100~200 個(gè)虛擬節(jié)點(diǎn)，才能到達(dá)一個(gè)較好的存儲(chǔ)均衡。這里為了方便理解，我對(duì) Memcached 的集群結(jié)構(gòu)做了簡(jiǎn)化，如下圖所示，物理節(jié)點(diǎn) 1 對(duì)應(yīng)兩個(gè)虛擬節(jié)點(diǎn) 1-1、1-2，物理節(jié)點(diǎn) 2 對(duì)應(yīng)三個(gè)虛擬節(jié)點(diǎn) 2-1、2-2 和 2-3。

采用帶虛擬節(jié)點(diǎn)的一致性哈希方法，有一個(gè)優(yōu)點(diǎn)是，當(dāng)添加或移除節(jié)點(diǎn)時(shí)，不會(huì)出現(xiàn)大規(guī)模的數(shù)據(jù)遷移。你可以再回顧下(數(shù)據(jù)分布方式之哈希與一致性哈希，我就是個(gè)神算子)

對(duì)于數(shù)據(jù)結(jié)構(gòu)的支持，Memcached 僅支持簡(jiǎn)單的 k/v 數(shù)據(jù)類型，如果想要存儲(chǔ)復(fù)雜的數(shù)據(jù)類型，比如 List、Set 和 Hash 等，需要客戶端自己處理，將其轉(zhuǎn)化為字符串然后進(jìn)行存儲(chǔ)。這樣就導(dǎo)致了一個(gè)缺點(diǎn)，操作不靈活。比如，Memcached 存儲(chǔ)的數(shù)組中有一個(gè)元素需要修改，則需要將整個(gè)數(shù)組的數(shù)據(jù)取出來(lái)，修改后再整體寫入到數(shù)據(jù)庫(kù)中 。

而對(duì)于持久化，Memcached 是不支持的。這意味著斷電時(shí)，Memcached 中存儲(chǔ)的數(shù)據(jù)將會(huì)全部丟失。因?yàn)閮?nèi)存是一種易失性存儲(chǔ)設(shè)備，斷電后將不會(huì)存儲(chǔ)數(shù)據(jù)。

在 Memcached 中，服務(wù)器和服務(wù)器之間沒有任何通信，即自身不支持主備。如果想要實(shí)現(xiàn)高可用，需要通過第三方實(shí)現(xiàn)。比如，Repcached 實(shí)現(xiàn)了 Memcached 的復(fù)制功能，支持一主一備，從而使 Memcached 滿足高可用。

對(duì)比分析

上面，我以 Redis 和 Memcached 這兩個(gè)主流的分布式緩存系統(tǒng)為例，帶你學(xué)習(xí)了分布式緩存技術(shù)。接下來(lái)，我以一個(gè)表格對(duì)它們進(jìn)行分析對(duì)比，以便于你理解和查閱。

總結(jié)

今天，我主要與你分享了分布式數(shù)據(jù)的緩存技術(shù)。

首先，我以水缸的例子帶你直觀了解了什么是緩存，并引出了什么是分布式數(shù)據(jù)緩存。分布式數(shù)據(jù)緩存是以內(nèi)存作為磁盤的緩存，存儲(chǔ)一些用戶經(jīng)常需要用的數(shù)據(jù)，以提高訪問速度。

其次，我以主流的 Redis 和 Memcached 為例，與你介紹了分布式緩存技術(shù)中的關(guān)鍵技術(shù)，包括支持的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)(比如 k/v、Set、List 等)、持久化技術(shù)(包括快照方式等)和數(shù)據(jù)同步技術(shù)(具體技術(shù)原理，可參見分布式數(shù)據(jù)復(fù)制技術(shù)，今天就教你真正分身術(shù))

最后，我再通過一張思維導(dǎo)圖來(lái)歸納一下今天的核心知識(shí)點(diǎn)吧。