深入分布式緩存

讀完需要

15

分鐘

速讀僅需 5 分鐘

云服務(wù)不僅為軟件系統(tǒng)的開發(fā)和部署帶來(lái)了更多的敏捷性，而且提供了更多創(chuàng)新的可能性。當(dāng)分布式緩存技術(shù)遇到云服務(wù)會(huì)是怎樣的情形呢？EVCache 就是這樣的一種技術(shù)。

EVCache 是一個(gè)開源、快速的分布式緩存，是基于 Memcached 的內(nèi)存存儲(chǔ)和 Spymem-cached 客戶端實(shí)現(xiàn)的解決方案，主要用在亞馬遜彈性計(jì)算云服務(wù)（AWS EC2）的基礎(chǔ)設(shè)施上，為云計(jì)算做了優(yōu)化，能夠順暢而高效地提供數(shù)據(jù)層服務(wù)。圖 10-1 所示是 EVCache 開源項(xiàng)目在 Github 上的表現(xiàn)。

圖 10-1 EVCache 開源項(xiàng)目的 Star 趨勢(shì)

EVCache 是一個(gè)縮寫，包括：

• Ephemeral：數(shù)據(jù)存儲(chǔ)是短暫的，有自身的存活時(shí)間。

• Volatile：數(shù)據(jù)可以在任何時(shí)候消失。

• Cache：一個(gè)內(nèi)存型的鍵值對(duì)存儲(chǔ)系統(tǒng)。

EVCache 實(shí)現(xiàn)的主要功能包括分布式鍵值對(duì)存儲(chǔ)，亞馬遜云服務(wù)的跨區(qū)域數(shù)據(jù)復(fù)制以及注冊(cè)和自動(dòng)發(fā)現(xiàn)新節(jié)點(diǎn)或者新服務(wù)。EVCache 典型的應(yīng)用是對(duì)上下文一致性要求不高的場(chǎng)景，其可擴(kuò)展性已經(jīng)可以處理非常大的流量，同時(shí)提供了健壯的應(yīng)用編程接口。

1

? ?

EVCache 項(xiàng)目介紹

EVCache 是 Netflix 開源軟件項(xiàng)目（Open Source Software，OSS）中的一部分，是 Netflix 多個(gè)關(guān)于數(shù)據(jù)存儲(chǔ)的開源項(xiàng)目中的一個(gè)重要成員。在 Netflix 架構(gòu)中有兩個(gè)基本元素，一個(gè)是控制平面，運(yùn)行在亞馬遜云服務(wù)（AWS）之上，用于用戶登錄，瀏覽和播放以及一般性服務(wù)。另一個(gè)是數(shù)據(jù)平面，叫做 Open Connect，這是一個(gè)全球性的視頻分發(fā)網(wǎng)絡(luò)。

EVCache 是位于控制平面的。

Netflix 是微服務(wù)架構(gòu)領(lǐng)域的實(shí)踐者，在系統(tǒng)中部署了上百個(gè)微服務(wù)，每一個(gè)微服務(wù)只專注做一件事情。這使得 Netflix 所提供的軟件系統(tǒng)能夠做到高度均衡和松耦合。由于狀態(tài)都存儲(chǔ)在緩存或持久存儲(chǔ)中，所以這些微服務(wù)大多數(shù)是無(wú)狀態(tài)的，易于自動(dòng)擴(kuò)展。

EVCache 在 Netflix 內(nèi)部是一個(gè)被廣泛使用的數(shù)據(jù)緩存服務(wù)，所提供的低延遲且高可用的緩存方案可以很好地滿足 Netflix 微服務(wù)架構(gòu)需要，也用來(lái)做一般數(shù)據(jù)的存儲(chǔ)。EVCache 能夠使面向終端用戶的應(yīng)用，個(gè)性化算法和各種微服務(wù)都具備優(yōu)良的性能。

EVCache 具有如下的特性：

• 分布式的鍵值對(duì)存儲(chǔ)，緩存可以跨越多個(gè)實(shí)例。

• 數(shù)據(jù)可以跨越亞馬遜云服務(wù)的可用區(qū)進(jìn)行復(fù)制。

• 通過(guò) Netflix 內(nèi)部的命名服務(wù)進(jìn)行注冊(cè)，自動(dòng)發(fā)現(xiàn)新節(jié)點(diǎn)和服務(wù)。

• 為了存儲(chǔ)數(shù)據(jù)，鍵是非空字符串，值可以是非空的字節(jié)數(shù)組，基本類型，或者序列化對(duì)象，且小于 1 MB。

• 作為通用的緩存集群被各種應(yīng)用使用，支持可選的緩存名稱，通過(guò)命名空間避免主鍵沖突。

• 一般的緩存命中率在 99%以上。

• 與 Netfix 駐留數(shù)據(jù)框架能夠良好協(xié)作，典型的訪問(wèn)次序：內(nèi)存→ EVCache → Cassandre/SimpleDB/S3。

使用緩存技術(shù)所帶來(lái)的最大影響可能是數(shù)據(jù)的不一致性。出于性能優(yōu)先的考慮，具體的應(yīng)用會(huì)依賴于 EVCache 來(lái)處理數(shù)據(jù)的不一致性。對(duì)于存活時(shí)間很短的數(shù)據(jù)，用 TTL 設(shè)置數(shù)據(jù)的失效時(shí)間，對(duì)于長(zhǎng)時(shí)間保留的數(shù)據(jù)，通過(guò)構(gòu)建一致性檢查來(lái)修復(fù)它們。

EVCache 是使用了 Memeached 操作接口（如 get、set、touch 等)，基于數(shù)據(jù)大小和網(wǎng)絡(luò)容量可以線性擴(kuò)展，支持任意數(shù)量的數(shù)據(jù)備份（有的集群支持 2 個(gè)，有的支持 9 個(gè))。所有操作都擁有對(duì)拓?fù)浣Y(jié)構(gòu)的感知、重試、回退，以及其他機(jī)制來(lái)保障操作的完整性，同時(shí)優(yōu)化了亞馬遜云服務(wù)的架構(gòu)。每個(gè)主鍵中的數(shù)據(jù)通過(guò)數(shù)據(jù)分塊技術(shù)處理后可以是任意大小的。

簡(jiǎn)而言之，Memcached 是一個(gè)單進(jìn)程應(yīng)用，在單臺(tái)主機(jī)上工作的很好，而 EVCache 使用它作為一個(gè)基礎(chǔ)模塊，Memcached 是 EVCache 的一個(gè)子集。

1.1

? ?

EVCache 的由來(lái)

對(duì)于一個(gè)流媒體服務(wù)來(lái)說(shuō)，提供一個(gè)以客戶為中心的用戶體驗(yàn)意味著要做很多事情，要包括優(yōu)秀的內(nèi)容庫(kù)，直觀的用戶界面，個(gè)性化內(nèi)容推薦，可以讓用戶獲取所喜愛的內(nèi)容并可高質(zhì)量播放的快速服務(wù)，等等。

Netflix 期待用戶和系統(tǒng)服務(wù)交互時(shí)能有一個(gè)極致的用戶體驗(yàn)，對(duì)云服務(wù)而言，所考慮的目標(biāo)是：

• 與 Netflix 數(shù)據(jù)中心相對(duì)應(yīng)的快速響應(yīng)時(shí)間。

• 從面向會(huì)話的應(yīng)用到云服務(wù)中的無(wú)會(huì)話狀態(tài)應(yīng)用。

• 使用 NoSQL 的數(shù)據(jù)駐留，如 Cassandra/SimpleDB/S3。

從數(shù)據(jù)存儲(chǔ)（如 Cassandra，或其他的亞馬遜云服務(wù)如 S3 或 SimpleDB）中計(jì)算或提取數(shù)據(jù)，這樣的數(shù)據(jù)存儲(chǔ)操作大多需要花費(fèi)數(shù)百毫秒，因此會(huì)影響用戶體驗(yàn)。通過(guò) EVCache 作為數(shù)據(jù)前端緩存，訪問(wèn)時(shí)間更加快速而且是線性的，同時(shí)削減了這些數(shù)據(jù)存儲(chǔ)的負(fù)載，還能夠更有效的分擔(dān)用戶請(qǐng)求。此外，數(shù)據(jù)加載服務(wù)經(jīng)常是先于緩存響應(yīng)，這保證了用戶可以得到個(gè)性化的數(shù)據(jù)響應(yīng)而不是通用響應(yīng)。另外，使用 EVCache 緩存可以有效地削減操作的總體成本。

EVCache 是典型的客戶端／服務(wù)器結(jié)構(gòu)。服務(wù)器端包括一個(gè) Memcached 進(jìn)程，這是一個(gè)流行的且久經(jīng)考驗(yàn)的內(nèi)存型鍵值對(duì)存儲(chǔ)，還包括一個(gè)叫 Prana 的 Java 進(jìn)程用于與發(fā)現(xiàn)服務(wù)（基于 Eureka 的實(shí)現(xiàn)）通信并托管本地管理，以及監(jiān)控服務(wù)健康狀態(tài)和統(tǒng)計(jì)狀態(tài)的各種應(yīng)用，并將統(tǒng)計(jì)信息發(fā)送給 Netfix 平臺(tái)的統(tǒng)計(jì)服務(wù)。具體結(jié)構(gòu)如圖 10-2 所示。

圖 10-2 EVCache Server 的基本結(jié)構(gòu)

其中，面向微服務(wù)的 Java 應(yīng)用提供了一個(gè)集成應(yīng)用程序到微服務(wù)生態(tài)系統(tǒng)的 HTTP 接口，主要功能如下：

• 注冊(cè)到發(fā)現(xiàn)系統(tǒng)。

• 其他服務(wù)的發(fā)現(xiàn)。

• 健康檢查服務(wù)。

• HTTP API 和負(fù)載均衡要求。

• 動(dòng)態(tài)屬性加載。

EVCache 客戶端是一個(gè) Java 的客戶端，用于發(fā)現(xiàn) EVCache 服務(wù)器并管理所有的增刪改查（CRUD）操作，由客戶端處理在集群中添加/刪除服務(wù)器。基于亞馬遜云服務(wù)可用區(qū)，客戶端在執(zhí)行創(chuàng)建、更新和刪除操作的時(shí)候復(fù)制數(shù)據(jù)。另一方面，客戶端的讀操作直接從同一可用區(qū)的服務(wù)器讀取數(shù)據(jù)。圖 10-3 展示了 EVCache 的典型部署結(jié)構(gòu)和單節(jié)點(diǎn)客戶端實(shí)例與服務(wù)器的關(guān)系。

圖 10-3 EVCache 單節(jié)點(diǎn)客戶端實(shí)例與服務(wù)器的關(guān)系

一個(gè) EVCache 客戶端連接了多個(gè) EVCache 的服務(wù)器集群。在一個(gè)區(qū)域內(nèi)，Netflix 有多個(gè)全數(shù)據(jù)集的拷貝，由亞馬遜云服務(wù)的可用區(qū)隔離開來(lái)。虛線框描述了區(qū)域內(nèi)的副本，每個(gè)都擁有數(shù)據(jù)的全量鏡像，作為隔離亞馬遜云服務(wù)的自動(dòng)伸縮組來(lái)管理這些鏡像。某些緩存在一個(gè)區(qū)域內(nèi)有兩個(gè)鏡像，有的擁有更多。這種高層架構(gòu)長(zhǎng)期來(lái)看是有效的，不會(huì)改變。每個(gè)客戶端連接自己區(qū)域內(nèi)所有可用區(qū)的所有服務(wù)器。寫操作被發(fā)往所有實(shí)例，讀操作優(yōu)先選擇離讀請(qǐng)求近的服務(wù)器。

1.2

? ?

EVCache 的發(fā)展

Netflix 的服務(wù)在全球 130 個(gè)多個(gè)國(guó)家上線了，很多國(guó)家都可以使用。為了應(yīng)對(duì)用戶和服務(wù)日益增長(zhǎng)的需求，Netflix 在全球建立了 EVCache 分布式系統(tǒng)。

Netflix 的全球云服務(wù)遍布亞馬遜各個(gè)服務(wù)區(qū)域，例如北弗吉尼亞、俄勒岡州和愛爾蘭，為這些地區(qū)的會(huì)員提供就近服務(wù)，但是網(wǎng)絡(luò)流量會(huì)因?yàn)楦鞣N原因改變，比如關(guān)鍵基礎(chǔ)設(shè)施出了問(wèn)題故障，或者地區(qū)之間進(jìn)行失敗恢復(fù)等，因此，Netflix 采用無(wú)態(tài)應(yīng)用服務(wù)器服務(wù)于來(lái)自任何地區(qū)的會(huì)員。

這些數(shù)據(jù)如果從持久層存儲(chǔ)獲得將會(huì)非常昂貴（造成頻繁的數(shù)據(jù)庫(kù)訪問(wèn))，Netflix 需要將這種數(shù)據(jù)寫入到本地緩存，而且必須復(fù)制到所有地區(qū)的緩存中，以便服務(wù)于各個(gè)地區(qū)的用戶請(qǐng)求。微服務(wù)是依賴于緩存的，必須快速可靠地訪問(wèn)多種類型的數(shù)據(jù)，比如會(huì)員的觀影歷史，排行榜和個(gè)性化推薦等，這些數(shù)據(jù)的更新與改變都必須復(fù)制到全世界各個(gè)地區(qū)，以便這些地區(qū)的用戶能夠快速可靠地訪問(wèn)。

EVCache 是專門為這些情況而設(shè)計(jì)的緩存產(chǎn)品，這是建立在于全局復(fù)制基礎(chǔ)上的，同時(shí)也考慮了強(qiáng)一致性。例如，如果愛爾蘭和弗吉尼亞的推薦內(nèi)容有輕微差別，這些差別不會(huì)傷害到用戶瀏覽和觀看體驗(yàn)，對(duì)于非重要的數(shù)據(jù)，會(huì)嚴(yán)重依賴最終一致性模型進(jìn)行復(fù)制，

本地和全局兩個(gè)緩存的差別保持在一個(gè)可以容忍的很短的時(shí)間內(nèi)，這就大大簡(jiǎn)化了數(shù)據(jù)的復(fù)制。EVCache 并不需要處理全局鎖、事務(wù)更新、部分提交回滾或其他分布式一致性有關(guān)的復(fù)雜問(wèn)題。即使在跨區(qū)域復(fù)制變慢的情況下，也不會(huì)影響性能和本地緩存的可靠性，所有復(fù)制都是異步的，復(fù)制系統(tǒng)能夠在不影響本地緩存操作的情況下悄悄地進(jìn)行。復(fù)制延遲是另外一個(gè)問(wèn)題，快得足夠嗎？在兩個(gè)地區(qū)之間切換的會(huì)員流量有多頻繁？什么情況會(huì)沖擊導(dǎo)致不一致性？寧愿不從完美主義去設(shè)計(jì)一個(gè)復(fù)制系統(tǒng)，EVcache 只要能最低限度滿足應(yīng)用和會(huì)員用戶的要求即可。

圖 10-4 介紹了 EVCache 跨地域的復(fù)制

圖 10-4 EVCache 跨地域的數(shù)據(jù)復(fù)制

這張圖說(shuō)明復(fù)制操作是在 SET 操作以后實(shí)現(xiàn)，應(yīng)用程序調(diào)用 EVCache 客戶端庫(kù)的 set 方法，之后的復(fù)制路徑對(duì)于調(diào)用者是透明的：

1）EVCache 客戶端庫(kù)發(fā)送 SET 到緩存系統(tǒng)的本地地區(qū)的一個(gè)實(shí)例服務(wù)器中。

2）EVCache 客戶端庫(kù)同時(shí)也將寫人元數(shù)據(jù)（包括 key，但是不包括要緩存的數(shù)據(jù)本身）到復(fù)制消息隊(duì)列（Kafka）。

3）本地區(qū)的復(fù)制中繼服務(wù)將會(huì)從這個(gè)消息隊(duì)列中讀取消息。

4）中繼服務(wù)會(huì)從本地緩存中抓取符合 key 的數(shù)據(jù)。

5）中繼服務(wù)會(huì)發(fā)送一個(gè) SET 請(qǐng)求到另一個(gè)地域的復(fù)制中繼服務(wù)。

6）在另一個(gè)區(qū)域中，復(fù)制中繼服務(wù)會(huì)接受請(qǐng)求，然后執(zhí)行 SET 操作到它的本地緩存，

完成復(fù)制。

7）在接受地區(qū)的本地應(yīng)用當(dāng)通過(guò) GET 操作以后會(huì)在本地緩存上看到這個(gè)已經(jīng)更新的數(shù)據(jù)值。

這是一個(gè)簡(jiǎn)單描述，需要注意的是，它只會(huì)對(duì) SET 操作有效，對(duì)于其他 DELETE TOUCH 或批 mutation 等操作不會(huì)復(fù)制，DELETE 和 TOUCH 是非常類的，只有一點(diǎn)不同：它們不從本地緩存中讀取已經(jīng)存在的值。

跨區(qū)域復(fù)制主要是通過(guò)消息隊(duì)列進(jìn)行，一個(gè)地區(qū)的 EVCache 客戶端不會(huì)注意到其他地區(qū)的復(fù)制情況，讀寫都是只使用本區(qū)域緩存，不會(huì)和其他地區(qū)緩存耦合，通過(guò)消息系統(tǒng)來(lái)解耦合。

1.3

? ?

EVCache 的演進(jìn)

EVCache 作為 Nethix 系統(tǒng)中最大的子系統(tǒng)之一，在系統(tǒng)優(yōu)化中占有相當(dāng)?shù)谋壤?#xff0c;地位獨(dú)一無(wú)二。所有數(shù)據(jù)存儲(chǔ)在內(nèi)存的成本隨著用戶基數(shù)的增長(zhǎng)而上揚(yáng)，單日個(gè)性化批處理輸出將加載超過(guò) 5 TB 的數(shù)據(jù)到 EVCache 集群。數(shù)據(jù)存儲(chǔ)成本是存儲(chǔ)數(shù)據(jù)與全局副本個(gè)數(shù)的乘積。如前所述，不同的 A/B 測(cè)試和其他內(nèi)部數(shù)據(jù)也增加了更多的數(shù)據(jù)。對(duì)于用戶的工作集，如今已經(jīng)有數(shù)十億的鍵值，而且在持續(xù)增加，成本的壓力逐漸顯現(xiàn)了出來(lái)。

面向數(shù)據(jù)和時(shí)延的優(yōu)化

在一般情況下，在 Netflix 的某個(gè)服務(wù)區(qū)域內(nèi)可以看到同一個(gè)用戶的反復(fù)區(qū)域切換對(duì)用戶而言并不是常態(tài)。盡管數(shù)據(jù)在三個(gè)區(qū)域的內(nèi)存中，只有一個(gè)區(qū)域中的數(shù)據(jù)被所在的用戶正常使用。由此推斷，在每個(gè)區(qū)域有著這些緩存的不同工作集，一個(gè)小的子集是熱數(shù)據(jù),其他是冷數(shù)據(jù)。

除了冷熱數(shù)據(jù)的分類之外，所有在內(nèi)存中的這些數(shù)據(jù)存儲(chǔ)成本隨著用戶的基數(shù)在增加。

Netflix 使用 EVCache 在內(nèi)存中存儲(chǔ)了若干 TB 的數(shù)據(jù)，包括了用于彈性的多個(gè)數(shù)據(jù)拷貝。

隨著成本面臨的壓力。Netflix 開始使用 RocksDB 來(lái)降低 EVCache 的存儲(chǔ)成本，同時(shí)保持了相對(duì)低的請(qǐng)求延遲。Netflix 引人了多級(jí)緩存機(jī)制，即同時(shí)使用 RAM 和 SSD。

根據(jù)不同區(qū)域不同數(shù)據(jù)訪問(wèn)的情況，Netflix 構(gòu)建了一個(gè)系統(tǒng)將熱數(shù)據(jù)存儲(chǔ)在 RAM，冷數(shù)據(jù)存儲(chǔ)在硬盤。這是典型的兩級(jí)緩存架構(gòu)（L1 代表 RAM，L2 代表硬盤)，依賴于 EVCache 的強(qiáng)一致性和低時(shí)延性能。面對(duì)盡量低的時(shí)延需求，要使用更多的昂貴內(nèi)存，使用低成本的 SSD 也要滿足客戶端對(duì)低時(shí)延的預(yù)期。

內(nèi)存型 EVCache 集群運(yùn)行在 AWS r3 系列的實(shí)例類型上，對(duì)大規(guī)模內(nèi)存的使用進(jìn)行了優(yōu)化。通過(guò)轉(zhuǎn)移到 i2 系列的實(shí)例上，在相同的 RAM 和 CPU 的條件下，可以獲得比 SSD 存儲(chǔ)(r3 系)擴(kuò)大十倍的增益（80 → 800GB，從 r3.xlarge 到 i2.xlarge)。Netflix 也降級(jí)了實(shí)例的大小到小型內(nèi)存實(shí)例上。結(jié)合這兩點(diǎn)，就可以在數(shù)千臺(tái)服務(wù)器上做優(yōu)先的成本優(yōu)化了。

基于 EVCache，這種充分利用全局化請(qǐng)求發(fā)布和成本優(yōu)化的項(xiàng)目叫做 Moneta，源自拉丁記憶女神的名字，也是羅馬神話中財(cái)富守護(hù)神——Juno Moneta。

Moneta 架構(gòu)

Moneta 項(xiàng)目在 EVCahce 服務(wù)器中引入了 2 個(gè)新的進(jìn)程：Rend 和 Mnemonic。Rend 是用 Go 語(yǔ)言寫的一個(gè)高性能代理，Mnemonic 是一個(gè)基于 RocksDB 的硬盤型鍵值對(duì)存儲(chǔ)。

Mnemnonic 重用了 Rend 服務(wù)器組件來(lái)處理協(xié)議解析(如 Memcached 協(xié)議)，連接管理和并行鎖。這三種服務(wù)器都使用 Memeached 的文本和二進(jìn)制協(xié)議，所以客戶端與它們的交互有著相同的語(yǔ)法，給調(diào)試和一致性檢查帶來(lái)了便捷性。Moneta 的系統(tǒng)結(jié)構(gòu)如圖 10-5 所示。

圖 10-5 Moneta 的結(jié)構(gòu)組成

Rend 代理服務(wù)

Rend 作為另外兩個(gè)真正存儲(chǔ)數(shù)據(jù)進(jìn)程的代理，是一個(gè)高性能服務(wù)器，使用二進(jìn)制和文本 Memcached 協(xié)議進(jìn)行通信。它是 Go 語(yǔ)言寫的，具有對(duì)并發(fā)處理的高性能。這個(gè)項(xiàng)目已經(jīng)在 Github 上開源了。使用 Go 是不錯(cuò)的選擇，因?yàn)樾枰?Java 更好的低時(shí)延（垃圾回收時(shí)的暫停是個(gè)問(wèn)題)，以及比 C 更好的生產(chǎn)效率，同時(shí)能處理成千上萬(wàn)的客戶端連接，Go 非常適合這樣的場(chǎng)景。

Rend 的職責(zé)是管理 L1 和 L2 緩存的關(guān)系，根據(jù)不同的內(nèi)部使用場(chǎng)景采用不同的策略，還具有裁剪數(shù)據(jù)的特性，能夠?qū)?shù)據(jù)分割成固定的大小插入到 Memcached 中以避免內(nèi)存分配時(shí)的病態(tài)行為。這種服務(wù)器側(cè)的分片代替了客戶端分片，已經(jīng)證明是可行的。

Rend 的設(shè)計(jì)是模塊化的，并且可配置。在內(nèi)部，有這樣一些分層：連接管理，服務(wù)器循環(huán)，通信協(xié)議，請(qǐng)求編排和后臺(tái)處理器。Rend 也有著獨(dú)立用來(lái)測(cè)試的客戶端代碼庫(kù)，能夠集中發(fā)現(xiàn)協(xié)議中的 bug 或者其他錯(cuò)誤，例如錯(cuò)誤對(duì)齊，未清除的緩存以及未完成的響應(yīng)等。Rend 的基本結(jié)構(gòu)如圖 10-6 所示。

圖 10-6 Rend 的結(jié)構(gòu)組成

作為 Moneta 服務(wù)的那些緩存，一個(gè)服務(wù)器就可以服務(wù)多種不同的客戶端。一類是熱路徑上的在線分析流量，用戶請(qǐng)求的個(gè)性化數(shù)據(jù)。其他是離線分析的流量和近期系統(tǒng)所產(chǎn)生的數(shù)據(jù)。這些典型的服務(wù)是整夜運(yùn)行的巨量批處理和結(jié)束時(shí)幾個(gè)小時(shí)的持續(xù)寫操作。

模塊化允許使用默認(rèn)的實(shí)現(xiàn)來(lái)優(yōu)化 Netflix 夜間的批處理計(jì)算，直接在 L2 中插入數(shù)據(jù)并且在 L1 中更換熱數(shù)據(jù)，避免了在夜間預(yù)計(jì)算時(shí)引起 L1 緩存的寫風(fēng)暴。來(lái)自其他區(qū)域的副本數(shù)據(jù)通常不是熱數(shù)據(jù)，所以也直接插人 L2。

圖 10-7 展示了一個(gè) Rend 進(jìn)程有多個(gè)端口連接了各種后臺(tái)存儲(chǔ)。

圖 10-7 Rend多端口連接后臺(tái)存儲(chǔ)服務(wù)

鑒于 Rend 的模塊化，很容易在不同的端口上引入其他的服務(wù)器，幾行代碼就能實(shí)現(xiàn)批處理和流量副本。允許不同后臺(tái)的插件式嵌人，通過(guò)一個(gè)接口和一個(gè)構(gòu)造函數(shù)即可。已經(jīng)證明了這種設(shè)計(jì)的有效性，一個(gè)工程師在一天內(nèi)熟悉了相關(guān)代碼并學(xué)習(xí)了 LMDB，把它集成起來(lái)作為了存儲(chǔ)后臺(tái)。這些代碼參見 https://github.com/Netflix/rend-Imdb ( https://github.com/Netflix/rend-Imdb )。

Mnemonic 存儲(chǔ)

Mnemonic 是基于 RocksDB 的 L2 解決方案，在硬盤上存儲(chǔ)數(shù)據(jù)。協(xié)議解析、連接管理、Mnemonic 的并發(fā)控制等所有的管理都使用了和 Rend 相同的庫(kù)。Mnemonic 是嵌入到 Moneta 服務(wù)器的一個(gè)后臺(tái)服務(wù)，Mnemonic 項(xiàng)目暴露出一個(gè)定制化的 C API 供 Rend 處理器使用。Mnemonic 的基本結(jié)構(gòu)如圖 10-8 所示。

圖 10-8 Mnemonic 的基本結(jié)構(gòu)組成

Mnemonic 中有趣的部分是在 C++的核心層封裝了 RocksDB。Mnemonic 處理 Memcached 協(xié)議風(fēng)格的請(qǐng)求，實(shí)現(xiàn)了 Memeached 的所需操作，包括 TTL 支持。它包含了一個(gè)重要的特性：將請(qǐng)求分發(fā)到一個(gè)本地系統(tǒng)的多個(gè) RocksDB 數(shù)據(jù)庫(kù)，減少了每個(gè) RocksDB 數(shù)據(jù)庫(kù)實(shí)例的負(fù)載。

在研究過(guò)有效訪問(wèn) SSD 的幾種技術(shù)之后，Netflix 選擇了 RocksDB，一個(gè)嵌入式鍵值對(duì)存儲(chǔ)，它使用了日志結(jié)構(gòu)合并樹的數(shù)據(jù)結(jié)構(gòu)。寫操作首先插入到一個(gè)內(nèi)存數(shù)據(jù)結(jié)構(gòu)中（一個(gè)內(nèi)存表)，當(dāng)寫滿的時(shí)候再寫入到硬盤上。當(dāng)寫入硬盤的時(shí)候，內(nèi)存表是一個(gè)不可修改的 SST 文件。這樣形成了批量的序列化寫人 SSD 的操作，減少了大量的內(nèi)部垃圾回收，改善了 SSD 在長(zhǎng)時(shí)間運(yùn)行實(shí)例上的時(shí)延。

Netflix 開始使用有層次的精簡(jiǎn)配置，主要原因是在多個(gè)數(shù)據(jù)庫(kù)中分發(fā)請(qǐng)求。然而，當(dāng)評(píng)估生產(chǎn)數(shù)據(jù)的精簡(jiǎn)配置以及與生產(chǎn)環(huán)境類似的流量的時(shí)候，發(fā)現(xiàn)這樣的配置會(huì)引起大量額外的 SSD 讀寫，增加了時(shí)延。SSD 讀流量經(jīng)常達(dá)到 200MB/sec。評(píng)估時(shí)的流量包括了長(zhǎng)時(shí)間的高寫操作，仿真了每天的批處理計(jì)算進(jìn)程。在此期間，RocksDB 持續(xù)的移動(dòng) L0 記錄達(dá)到了一個(gè)很高的水平，放大成為非常高的寫操作。

為了避免過(guò)載，Netflix 切換到 FIFO 型的精簡(jiǎn)配置。在這種配置中，沒有真正的精簡(jiǎn)操作被完成。基于數(shù)據(jù)庫(kù)的最大尺寸，刪除舊的 SST 文件。記錄在硬盤的 level 0 中,所以只在多個(gè) SST 文件中按時(shí)間排序。這種配置的下降趨勢(shì)在于讀操作必須在判斷一個(gè)鍵是否命中之前以時(shí)間倒序檢查每個(gè) SST 文件。這種檢查通常不需要硬盤讀操作，RocksDB 中的大量過(guò)濾器杜絕了高比例的對(duì)每個(gè) SST 的硬盤訪問(wèn)。然而，有利有弊，SST 文件的數(shù)量影響了賦值操作的有效性，將低于正常有層次風(fēng)格的精簡(jiǎn)配置。Netflix 通過(guò)初始進(jìn)入系統(tǒng)時(shí)的讀寫請(qǐng)求在多個(gè) RocksDB 進(jìn)行分發(fā)減少了掃描多個(gè)文件的負(fù)面影響。（未完待續(xù)）

- EOF -

文末留言，分享你對(duì)緩存的理解與看法，截止到2021年1月15日12點(diǎn)，精選后點(diǎn)贊數(shù)前5名，獲得作者簽名書《深入分布式緩存》一本

想要加入中生代架構(gòu)群的小伙伴，請(qǐng)?zhí)砑尤汉匣锶?strong>大白的微信

申請(qǐng)備注（姓名+公司+技術(shù)方向）才能通過(guò)哦！

阿里技術(shù)精彩文章推薦

往期推薦

深度：揭秘阿里巴巴的客群畫像

多隆：從工程師到阿里巴巴合伙人

阿里技術(shù)專家楚衡：架構(gòu)制圖的工具與方法論

螞蟻集團(tuán)技術(shù)專家山丘：性能優(yōu)化常見壓測(cè)模型及優(yōu)缺點(diǎn)

阿里文娛技術(shù)專家戰(zhàn)獒: 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)詳解之What, Why, How?

阿里專家馬飛翔：一文讀懂架構(gòu)整潔之道

阿里專家常昊：新人如何上手項(xiàng)目管理？

螞蟻集團(tuán)沈凋墨：Kubernetes-微內(nèi)核的分布式操作系統(tǒng)

阿里合伙人范禹：常掛在阿里技術(shù)人嘴邊的四句土話

阿里技術(shù)專家都鐸：一文搞懂技術(shù)債

支付寶研究員兼OceanBase總架構(gòu)師楊傳輝：我在數(shù)據(jù)庫(kù)夢(mèng)之隊(duì)的十年成長(zhǎng)路

阿里技術(shù)專家麒燁：修煉測(cè)試基本功

阿里計(jì)算平臺(tái)掌門人賈揚(yáng)清：我對(duì)人工智能方向的一點(diǎn)淺見

螞蟻資深算法專家周俊：從原理到落地，支付寶如何打造保護(hù)隱私的共享智能？

阿里高級(jí)技術(shù)專家簫逸：如何畫好一張架構(gòu)圖？

阿里高級(jí)技術(shù)專家張建飛：應(yīng)用架構(gòu)分離業(yè)務(wù)邏輯和技術(shù)細(xì)節(jié)之道

螞蟻科技 Service Mesh 落地實(shí)踐與挑戰(zhàn) | GIAC 實(shí)錄

阿里6年，我的技術(shù)蛻變之路！

螞蟻集團(tuán)涵暢：再啟程，Service Mesh 前路雖長(zhǎng)，尤可期許

阿里P9專家右軍：大話軟件質(zhì)量穩(wěn)定性

阿里合伙人程立：阿里15年，我撕掉了身上兩個(gè)標(biāo)簽

阿里高工流生 | 云原生時(shí)代的 DevOps 之道

阿里高級(jí)技術(shù)專家邱小俠：微服務(wù)架構(gòu)的理論基礎(chǔ) - 康威定律

阿里P9專家右軍：以終為始的架構(gòu)設(shè)計(jì)

阿里P8架構(gòu)師：淘寶技術(shù)架構(gòu)從1.0到4.0的架構(gòu)變遷！12頁(yè)P(yáng)PT詳解

阿里技術(shù)：如何畫出一張合格的技術(shù)架構(gòu)圖？

螞蟻資深技術(shù)專家王旭：開源項(xiàng)目是如何讓這個(gè)世界更安全的？

阿里資深技術(shù)專家崮德：8 個(gè)影響我職業(yè)生涯的重要技能

阿里儒梟：我看技術(shù)人的成長(zhǎng)路徑

阿里高級(jí)技術(shù)專家宋意：平凡人在阿里十年的成長(zhǎng)之旅

阿里技術(shù)專家甘盤：淺談雙十一背后的支付寶LDC架構(gòu)和其CAP分析

阿里技術(shù)專家光錐：億級(jí)長(zhǎng)連網(wǎng)關(guān)的云原生演進(jìn)之路

阿里云原生張羽辰：服務(wù)發(fā)現(xiàn)技術(shù)選型那點(diǎn)事兒

螞蟻研究員玉伯：做一個(gè)簡(jiǎn)單自由有愛的技術(shù)人

阿里高級(jí)技術(shù)專家至簡(jiǎn): Service Mesh 在超大規(guī)模場(chǎng)景下的落地挑戰(zhàn)

阿里巴巴山獵：手把手教你玩轉(zhuǎn)全鏈路監(jiān)控

阿里涉江：你真的會(huì)學(xué)習(xí)嗎？從結(jié)構(gòu)化思維說(shuō)起

螞蟻金服資深技術(shù)專家經(jīng)國(guó)：云原生時(shí)代微服務(wù)的高可用架構(gòu)設(shè)計(jì)

? ?END ? ?? #架構(gòu)師必備#點(diǎn)分享點(diǎn)點(diǎn)贊點(diǎn)在看

總結(jié)

以上是生活随笔為你收集整理的深入分布式缓存之EVCache探秘开局篇（文末赠书）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。