偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

資深架構(gòu)師分享:大型網(wǎng)站多級(jí)緩存的分層架構(gòu)

存儲(chǔ) 存儲(chǔ)軟件
這種說(shuō)法帶有片面性,甚至是一知半解,但是作為專(zhuān)業(yè)人士的我們,需要對(duì)緩存有更深、更廣的了解。

 這種說(shuō)法帶有片面性,甚至是一知半解,但是作為專(zhuān)業(yè)人士的我們,需要對(duì)緩存有更深、更廣的了解。

[[279660]]

緩存技術(shù)存在于應(yīng)用場(chǎng)景的方方面面。從瀏覽器請(qǐng)求,到反向代理服務(wù)器,從進(jìn)程內(nèi)緩存到分布式緩存。其中緩存策略,算法也是層出不窮,今天就帶大家走進(jìn)緩存。

緩存對(duì)于每個(gè)開(kāi)發(fā)者來(lái)說(shuō)是相當(dāng)熟悉了,為了提高程序的性能我們會(huì)去加緩存,但是在什么地方加緩存,如何加緩存呢?

假設(shè)一個(gè)網(wǎng)站,需要提高性能,緩存可以放在瀏覽器,可以放在反向代理服務(wù)器,還可以放在應(yīng)用程序進(jìn)程內(nèi),同時(shí)可以放在分布式緩存系統(tǒng)中。

 

資深架構(gòu)師分享:大型網(wǎng)站多級(jí)緩存的分層架構(gòu)

 

從用戶(hù)請(qǐng)求數(shù)據(jù)到數(shù)據(jù)返回,數(shù)據(jù)經(jīng)過(guò)了瀏覽器,CDN,代理服務(wù)器,應(yīng)用服務(wù)器,以及數(shù)據(jù)庫(kù)各個(gè)環(huán)節(jié)。每個(gè)環(huán)節(jié)都可以運(yùn)用緩存技術(shù)。

從瀏覽器/客戶(hù)端開(kāi)始請(qǐng)求數(shù)據(jù),通過(guò) HTTP 配合 CDN 獲取數(shù)據(jù)的變更情況,到達(dá)代理服務(wù)器(Nginx)可以通過(guò)反向代理獲取靜態(tài)資源。

再往下來(lái)到應(yīng)用服務(wù)器可以通過(guò)進(jìn)程內(nèi)(堆內(nèi))緩存,分布式緩存等遞進(jìn)的方式獲取數(shù)據(jù)。如果以上所有緩存都沒(méi)有命中數(shù)據(jù),才會(huì)回源到數(shù)據(jù)庫(kù)。

緩存的請(qǐng)求順序是:用戶(hù)請(qǐng)求 → HTTP 緩存 → CDN 緩存 → 代理服務(wù)器緩存 → 進(jìn)程內(nèi)緩存 → 分布式緩存 → 數(shù)據(jù)庫(kù)。

看來(lái)在技術(shù)的架構(gòu)每個(gè)環(huán)節(jié)都可以加入緩存,看看每個(gè)環(huán)節(jié)是如何應(yīng)用緩存技術(shù)的。

1. HTTP緩存

當(dāng)用戶(hù)通過(guò)瀏覽器請(qǐng)求服務(wù)器的時(shí)候,會(huì)發(fā)起 HTTP 請(qǐng)求,如果對(duì)每次 HTTP 請(qǐng)求進(jìn)行緩存,那么可以減少應(yīng)用服務(wù)器的壓力。

當(dāng)?shù)谝淮握?qǐng)求的時(shí)候,瀏覽器本地緩存庫(kù)沒(méi)有緩存數(shù)據(jù),會(huì)從服務(wù)器取數(shù)據(jù),并且放到瀏覽器的緩存庫(kù)中,下次再進(jìn)行請(qǐng)求的時(shí)候會(huì)根據(jù)緩存的策略來(lái)讀取本地或者服務(wù)的信息。

 

資深架構(gòu)師分享:大型網(wǎng)站多級(jí)緩存的分層架構(gòu)

 

一般信息的傳遞通過(guò) HTTP 請(qǐng)求頭 Header 來(lái)傳遞。目前比較常見(jiàn)的緩存方式有兩種,分別是:

  • 強(qiáng)制緩存
  • 對(duì)比緩存

1.1. 強(qiáng)制緩存

當(dāng)瀏覽器本地緩存庫(kù)保存了緩存信息,在緩存數(shù)據(jù)未失效的情況下,可以直接使用緩存數(shù)據(jù)。否則就需要重新獲取數(shù)據(jù)。

這種緩存機(jī)制看上去比較直接,那么如何判斷緩存數(shù)據(jù)是否失效呢?這里需要關(guān)注 HTTP Header 中的兩個(gè)字段 Expires 和 Cache-Control。

Expires 為服務(wù)端返回的過(guò)期時(shí)間,客戶(hù)端第一次請(qǐng)求服務(wù)器,服務(wù)器會(huì)返回資源的過(guò)期時(shí)間。如果客戶(hù)端再次請(qǐng)求服務(wù)器,會(huì)把請(qǐng)求時(shí)間與過(guò)期時(shí)間做比較。

如果請(qǐng)求時(shí)間小于過(guò)期時(shí)間,那么說(shuō)明緩存沒(méi)有過(guò)期,則可以直接使用本地緩存庫(kù)的信息。

反之,說(shuō)明數(shù)據(jù)已經(jīng)過(guò)期,必須從服務(wù)器重新獲取信息,獲取完畢又會(huì)更新最新的過(guò)期時(shí)間。

這種方式在 HTTP 1.0 用的比較多,到了 HTTP 1.1 會(huì)使用 Cache-Control 替代。

Cache-Control 中有個(gè) max-age 屬性,單位是秒,用來(lái)表示緩存內(nèi)容在客戶(hù)端的過(guò)期時(shí)間。

例如:max-age 是 60 秒,當(dāng)前緩存沒(méi)有數(shù)據(jù),客戶(hù)端第一次請(qǐng)求完后,將數(shù)據(jù)放入本地緩存。

那么在 60 秒以?xún)?nèi)客戶(hù)端再發(fā)送請(qǐng)求,都不會(huì)請(qǐng)求應(yīng)用服務(wù)器,而是從本地緩存中直接返回?cái)?shù)據(jù)。如果兩次請(qǐng)求相隔時(shí)間超過(guò)了 60 秒,那么就需要通過(guò)服務(wù)器獲取數(shù)據(jù)。

1.2. 對(duì)比緩存

需要對(duì)比前后兩次的緩存標(biāo)志來(lái)判斷是否使用緩存。瀏覽器第一次請(qǐng)求時(shí),服務(wù)器會(huì)將緩存標(biāo)識(shí)與數(shù)據(jù)一起返回,瀏覽器將二者備份至本地緩存庫(kù)中。瀏覽器再次請(qǐng)求時(shí),將備份的緩存標(biāo)識(shí)發(fā)送給服務(wù)器。

服務(wù)器根據(jù)緩存標(biāo)識(shí)進(jìn)行判斷,如果判斷數(shù)據(jù)沒(méi)有發(fā)生變化,把判斷成功的 304 狀態(tài)碼發(fā)給瀏覽器。

這時(shí)瀏覽器就可以使用緩存的數(shù)據(jù)來(lái)。服務(wù)器返回的就只是 Header,不包含 Body。

下面介紹兩種標(biāo)識(shí)規(guī)則:

1.2.1. Last-Modified/If-Modified-Since 規(guī)則

在客戶(hù)端第一次請(qǐng)求的時(shí)候,服務(wù)器會(huì)返回資源最后的修改時(shí)間,記作 Last-Modified??蛻?hù)端將這個(gè)字段連同資源緩存起來(lái)。

Last-Modified 被保存以后,在下次請(qǐng)求時(shí)會(huì)以 Last-Modified-Since 字段被發(fā)送。

當(dāng)客戶(hù)端再次請(qǐng)求服務(wù)器時(shí),會(huì)把 Last-Modified 連同請(qǐng)求的資源一起發(fā)給服務(wù)器,這時(shí) Last-Modified 會(huì)被命名為 If-Modified-Since,存放的內(nèi)容都是一樣的。

服務(wù)器收到請(qǐng)求,會(huì)把 If-Modified-Since 字段與服務(wù)器上保存的 Last-Modified 字段作比較:

  • 若服務(wù)器上的 Last-Modified 最后修改時(shí)間大于請(qǐng)求的 If-Modified-Since,說(shuō)明資源被改動(dòng)過(guò),就會(huì)把資源(包括 Header+Body)重新返回給瀏覽器,同時(shí)返回狀態(tài)碼 200。
  • 若資源的最后修改時(shí)間小于或等于 If-Modified-Since,說(shuō)明資源沒(méi)有改動(dòng)過(guò),只會(huì)返回 Header,并且返回狀態(tài)碼 304。瀏覽器接受到這個(gè)消息就可以使用本地緩存庫(kù)的數(shù)據(jù)。

注意:Last-Modified 和 If-Modified-Since 指的是同一個(gè)值,只是在客戶(hù)端和服務(wù)器端的叫法不同。

1.2.2. ETag / If-None-Match 規(guī)則

客戶(hù)端第一次請(qǐng)求的時(shí)候,服務(wù)器會(huì)給每個(gè)資源生成一個(gè) ETag 標(biāo)記。這個(gè) ETag 是根據(jù)每個(gè)資源生成的唯一 Hash 串,資源如何發(fā)生變化 ETag 隨之更改,之后將這個(gè) ETag 返回給客戶(hù)端,客戶(hù)端把請(qǐng)求的資源和 ETag 都緩存到本地。

ETag 被保存以后,在下次請(qǐng)求時(shí)會(huì)當(dāng)作 If-None-Match 字段被發(fā)送出去。

在瀏覽器第二次請(qǐng)求服務(wù)器相同資源時(shí),會(huì)把資源對(duì)應(yīng)的 ETag 一并發(fā)送給服務(wù)器。在請(qǐng)求時(shí) ETag 轉(zhuǎn)化成 If-None-Match,但其內(nèi)容不變。

服務(wù)器收到請(qǐng)求后,會(huì)把 If-None-Match 與服務(wù)器上資源的 ETag 進(jìn)行比較:

  • 如果不一致,說(shuō)明資源被改動(dòng)過(guò),則返回資源(Header+Body),返回狀態(tài)碼 200。
  • 如果一致,說(shuō)明資源沒(méi)有被改過(guò),則返回 Header,返回狀態(tài)碼 304。瀏覽器接受到這個(gè)消息就可以使用本地緩存庫(kù)的數(shù)據(jù)。

注意:ETag 和 If-None-Match 指的是同一個(gè)值,只是在客戶(hù)端和服務(wù)器端的叫法不同。

2. CDN 緩存

HTTP 緩存主要是對(duì)靜態(tài)數(shù)據(jù)進(jìn)行緩存,把從服務(wù)器拿到的數(shù)據(jù)緩存到客戶(hù)端/瀏覽器。

如果在客戶(hù)端和服務(wù)器之間再加上一層 CDN,可以讓 CDN 為應(yīng)用服務(wù)器提供緩存,如果在 CDN 上緩存,就不用再請(qǐng)求應(yīng)用服務(wù)器了。并且 HTTP 緩存提到的兩種策略同樣可以在 CDN 服務(wù)器執(zhí)行。

CDN 的全稱(chēng)是 Content Delivery Network,即內(nèi)容分發(fā)網(wǎng)絡(luò)。

讓我們來(lái)看看它是如何工作的吧:

  • 客戶(hù)端發(fā)送 URL 給 DNS 服務(wù)器。
  • DNS 通過(guò)域名解析,把請(qǐng)求指向 CDN 網(wǎng)絡(luò)中的 DNS 負(fù)載均衡器。
  • DNS 負(fù)載均衡器將最近 CDN 節(jié)點(diǎn)的 IP 告訴 DNS,DNS 告之客戶(hù)端最新 CDN 節(jié)點(diǎn)的 IP。
  • 客戶(hù)端請(qǐng)求最近的 CDN 節(jié)點(diǎn)。
  • CDN 節(jié)點(diǎn)從應(yīng)用服務(wù)器獲取資源返回給客戶(hù)端,同時(shí)將靜態(tài)信息緩存。注意:客戶(hù)端下次互動(dòng)的對(duì)象就是 CDN 緩存了,CDN 可以和應(yīng)用服務(wù)器同步緩存信息。

CDN 接受客戶(hù)端的請(qǐng)求,它就是離客戶(hù)端最近的服務(wù)器,它后面會(huì)鏈接多臺(tái)服務(wù)器,起到了緩存和負(fù)載均衡的作用。

3. 負(fù)載均衡緩存

說(shuō)完客戶(hù)端(HTTP)緩存和 CDN 緩存,我們離應(yīng)用服務(wù)越來(lái)越近了,在到達(dá)應(yīng)用服務(wù)之前,請(qǐng)求還要經(jīng)過(guò)負(fù)載均衡器。

雖說(shuō)它的主要工作是對(duì)應(yīng)用服務(wù)器進(jìn)行負(fù)載均衡,但是它也可以作緩存。可以把一些修改頻率不高的數(shù)據(jù)緩存在這里,例如:用戶(hù)信息,配置信息。通過(guò)服務(wù)定期刷新這個(gè)緩存就行了。

 

資深架構(gòu)師分享:大型網(wǎng)站多級(jí)緩存的分層架構(gòu)

 

以 Nginx 為例,我們看看它是如何工作的:

  • 用戶(hù)請(qǐng)求在達(dá)到應(yīng)用服務(wù)器之前,會(huì)先訪問(wèn) Nginx 負(fù)載均衡器,如果發(fā)現(xiàn)有緩存信息,直接返回給用戶(hù)。
  • 如果沒(méi)有發(fā)現(xiàn)緩存信息,Nginx 回源到應(yīng)用服務(wù)器獲取信息。
  • 另外,有一個(gè)緩存更新服務(wù),定期把應(yīng)用服務(wù)器中相對(duì)穩(wěn)定的信息更新到 Nginx 本地緩存中。

4. 進(jìn)程內(nèi)緩存

通過(guò)了客戶(hù)端,CDN,負(fù)載均衡器,我們終于來(lái)到了應(yīng)用服務(wù)器。應(yīng)用服務(wù)器上部署著一個(gè)個(gè)應(yīng)用,這些應(yīng)用以進(jìn)程的方式運(yùn)行著,那么在進(jìn)程中的緩存是怎樣的呢?

進(jìn)程內(nèi)緩存又叫托管堆緩存,以APC為例,同時(shí)會(huì)受到托管堆回收算法的影響。

由于其運(yùn)行在內(nèi)存中,對(duì)數(shù)據(jù)的響應(yīng)速度很快,通常我們會(huì)把熱點(diǎn)數(shù)據(jù)放在這里。

在進(jìn)程內(nèi)緩存沒(méi)有命中的時(shí)候,我們會(huì)去搜索進(jìn)程外的緩存或者分布式緩存。這種緩存的好處是沒(méi)有序列化和反序列化,是最快的緩存。缺點(diǎn)是緩存的空間不能太大,對(duì)垃圾回收器的性能有影響。

這里我們需要關(guān)注幾個(gè)緩存的回收策略,具體的實(shí)現(xiàn)架構(gòu)的回收策略會(huì)有所不同,但大致的思路都是一致的:

  • FIFO(First In First Out):先進(jìn)先出算法,最先放入緩存的數(shù)據(jù)最先被移除。
  • LRU(Least Recently Used):最近最少使用算法,把最久沒(méi)有使用過(guò)的數(shù)據(jù)移除緩存。
  • LFU(Least Frequently Used):最不常用算法,在一段時(shí)間內(nèi)使用頻率最小的數(shù)據(jù)被移除緩存。

在分布式架構(gòu)的今天,多應(yīng)用中如果采用進(jìn)程內(nèi)緩存會(huì)存在數(shù)據(jù)一致性的問(wèn)題。

這里推薦兩個(gè)方案:

  • 消息隊(duì)列修改方案
  • Timer 修改方案

4.1. 消息隊(duì)列修改方案

應(yīng)用在修改完自身緩存數(shù)據(jù)和數(shù)據(jù)庫(kù)數(shù)據(jù)之后,給消息隊(duì)列發(fā)送數(shù)據(jù)變化通知,其他應(yīng)用訂閱了消息通知,在收到通知的時(shí)候修改緩存數(shù)據(jù)。

 

資深架構(gòu)師分享:大型網(wǎng)站多級(jí)緩存的分層架構(gòu)

 

4.2. Timer 修改方案

為了避免耦合,降低復(fù)雜性,對(duì)“實(shí)時(shí)一致性”不敏感的情況下。每個(gè)應(yīng)用都會(huì)啟動(dòng)一個(gè) Timer,定時(shí)從數(shù)據(jù)庫(kù)拉取最新的數(shù)據(jù),更新緩存。

不過(guò)在有的應(yīng)用更新數(shù)據(jù)庫(kù)后,其他節(jié)點(diǎn)通過(guò) Timer 獲取數(shù)據(jù)之間,會(huì)讀到臟數(shù)據(jù)。這里需要控制好 Timer 的頻率,以及應(yīng)用與對(duì)實(shí)時(shí)性要求不高的場(chǎng)景。

 

資深架構(gòu)師分享:大型網(wǎng)站多級(jí)緩存的分層架構(gòu)

 

進(jìn)程內(nèi)緩存有哪些使用場(chǎng)景呢?

場(chǎng)景一:只讀數(shù)據(jù),可以考慮在進(jìn)程啟動(dòng)時(shí)加載到內(nèi)存。當(dāng)然,把數(shù)據(jù)加載到類(lèi)似 Redis 這樣的進(jìn)程外緩存服務(wù)也能解決這類(lèi)問(wèn)題。

場(chǎng)景二:高并發(fā),可以考慮使用進(jìn)程內(nèi)緩存,例如:秒殺。

5. 分布式緩存

說(shuō)完進(jìn)程內(nèi)緩存,自然就過(guò)度到進(jìn)程外緩存了。與進(jìn)程內(nèi)緩存不同,進(jìn)程外緩存在應(yīng)用運(yùn)行的進(jìn)程之外,它擁有更大的緩存容量,并且可以部署到不同的物理節(jié)點(diǎn),通常會(huì)用分布式緩存的方式實(shí)現(xiàn)。

分布式緩存是與應(yīng)用分離的緩存服務(wù),最大的特點(diǎn)是,自身是一個(gè)獨(dú)立的應(yīng)用/服務(wù),與本地應(yīng)用隔離,多個(gè)應(yīng)用可直接共享一個(gè)或者多個(gè)緩存應(yīng)用/服務(wù)。

 

資深架構(gòu)師分享:大型網(wǎng)站多級(jí)緩存的分層架構(gòu)

 

既然是分布式緩存,緩存的數(shù)據(jù)會(huì)分布到不同的緩存節(jié)點(diǎn)上,每個(gè)緩存節(jié)點(diǎn)緩存的數(shù)據(jù)大小通常也是有限制的。

數(shù)據(jù)被緩存到不同的節(jié)點(diǎn),為了能方便的訪問(wèn)這些節(jié)點(diǎn),需要引入緩存代理,類(lèi)似 Twemproxy。他會(huì)幫助請(qǐng)求找到對(duì)應(yīng)的緩存節(jié)點(diǎn)。

同時(shí)如果緩存節(jié)點(diǎn)增加了,這個(gè)代理也會(huì)只能識(shí)別并且把新的緩存數(shù)據(jù)分片到新的節(jié)點(diǎn),做橫向的擴(kuò)展。

為了提高緩存的可用性,會(huì)在原有的緩存節(jié)點(diǎn)上加入 Master/Slave 的設(shè)計(jì)。當(dāng)緩存數(shù)據(jù)寫(xiě)入 Master 節(jié)點(diǎn)的時(shí)候,會(huì)同時(shí)同步一份到 Slave 節(jié)點(diǎn)。

一旦 Master 節(jié)點(diǎn)失效,可以通過(guò)代理直接切換到 Slave 節(jié)點(diǎn),這時(shí) Slave 節(jié)點(diǎn)就變成了 Master 節(jié)點(diǎn),保證緩存的正常工作。

每個(gè)緩存節(jié)點(diǎn)還會(huì)提供緩存過(guò)期的機(jī)制,并且會(huì)把緩存內(nèi)容定期以快照的方式保存到文件上,方便緩存崩潰之后啟動(dòng)預(yù)熱加載。

5.1. 高性能

當(dāng)緩存做成分布式的時(shí)候,數(shù)據(jù)會(huì)根據(jù)一定的規(guī)律分配到每個(gè)緩存應(yīng)用/服務(wù)上。

如果我們把這些緩存應(yīng)用/服務(wù)叫做緩存節(jié)點(diǎn),每個(gè)節(jié)點(diǎn)一般都可以緩存一定容量的數(shù)據(jù),例如:Redis 一個(gè)節(jié)點(diǎn)可以緩存 2G 的數(shù)據(jù)。

如果需要緩存的數(shù)據(jù)量比較大就需要擴(kuò)展多個(gè)緩存節(jié)點(diǎn)來(lái)實(shí)現(xiàn),這么多的緩存節(jié)點(diǎn),客戶(hù)端的請(qǐng)求不知道訪問(wèn)哪個(gè)節(jié)點(diǎn)怎么辦?緩存的數(shù)據(jù)又如何放到這些節(jié)點(diǎn)上?

緩存代理服務(wù)已經(jīng)幫我們解決這些問(wèn)題了,例如:Twemproxy 不但可以幫助緩存路由,同時(shí)可以管理緩存節(jié)點(diǎn)。

這里有介紹三種緩存數(shù)據(jù)分片的算法,有了這些算法緩存代理就可以方便的找到分片的數(shù)據(jù)了。

5.1.1. 哈希算法

Hash 表是最常見(jiàn)的數(shù)據(jù)結(jié)構(gòu),實(shí)現(xiàn)方式是,對(duì)數(shù)據(jù)記錄的關(guān)鍵值進(jìn)行 Hash,然后再對(duì)需要分片的緩存節(jié)點(diǎn)個(gè)數(shù)進(jìn)行取模得到的余數(shù)進(jìn)行數(shù)據(jù)分配。

例如:有三條記錄數(shù)據(jù)分別是 R1,R2,R3。他們的 ID 分別是 01,02,03,假設(shè)對(duì)這三個(gè)記錄的 ID 作為關(guān)鍵值進(jìn)行 Hash 算法之后的結(jié)果依舊是 01,02,03。

我們想把這三條數(shù)據(jù)放到三個(gè)緩存節(jié)點(diǎn)中,可以把這個(gè)結(jié)果分別對(duì) 3 這個(gè)數(shù)字取模得到余數(shù),這個(gè)余數(shù)就是這三條記錄分別放置的緩存節(jié)點(diǎn)。

 

資深架構(gòu)師分享:大型網(wǎng)站多級(jí)緩存的分層架構(gòu)

 

Hash 算法是某種程度上的平均放置,策略比較簡(jiǎn)單,如果要增加緩存節(jié)點(diǎn),對(duì)已經(jīng)存在的數(shù)據(jù)會(huì)有較大的變動(dòng)。

5.1.2. 一致性哈希算法

一致性 Hash 是將數(shù)據(jù)按照特征值映射到一個(gè)首尾相接的 Hash 環(huán)上,同時(shí)也將緩存節(jié)點(diǎn)映射到這個(gè)環(huán)上。

如果要緩存數(shù)據(jù),通過(guò)數(shù)據(jù)的關(guān)鍵值(Key)在環(huán)上找到自己存放的位置。這些數(shù)據(jù)按照自身的 ID 取 Hash 之后得到的值按照順序在環(huán)上排列。

 

資深架構(gòu)師分享:大型網(wǎng)站多級(jí)緩存的分層架構(gòu)

 

如果這個(gè)時(shí)候要插入一條新的數(shù)據(jù)其 ID 是 115,那么就應(yīng)該插入到如下圖的位置。

 

資深架構(gòu)師分享:大型網(wǎng)站多級(jí)緩存的分層架構(gòu)

 

同理如果要增加一個(gè)緩存節(jié)點(diǎn) N4 150,也可以放到如下圖的位置。

 

資深架構(gòu)師分享:大型網(wǎng)站多級(jí)緩存的分層架構(gòu)

 

這種算法對(duì)于增加緩存數(shù)據(jù),和緩存節(jié)點(diǎn)的開(kāi)銷(xiāo)相對(duì)比較小。

5.1.3. Range Based 算法

這種方式是按照關(guān)鍵值(例如 ID)將數(shù)據(jù)劃分成不同的區(qū)間,每個(gè)緩存節(jié)點(diǎn)負(fù)責(zé)一個(gè)或者多個(gè)區(qū)間。跟一致性哈希有點(diǎn)像。

例如:存在三個(gè)緩存節(jié)點(diǎn)分別是 N1,N2,N3。他們用來(lái)存放數(shù)據(jù)的區(qū)間分別是,N1(0, 100], N2(100, 200], N3(300, 400]。

那么數(shù)據(jù)根據(jù)自己 ID 作為關(guān)鍵字做 Hash 以后的結(jié)果就會(huì)分別對(duì)應(yīng)放到這幾個(gè)區(qū)域里面了。

責(zé)任編輯:武曉燕 來(lái)源: 今日頭條
相關(guān)推薦

2019-10-30 16:24:34

分層架構(gòu)緩存

2018-07-03 15:46:24

Java架構(gòu)師源碼

2017-09-16 18:29:00

代碼數(shù)據(jù)庫(kù)線程

2012-11-01 15:08:10

IBM資深架構(gòu)師

2019-08-27 11:00:38

技術(shù)數(shù)據(jù)庫(kù)設(shè)計(jì)

2015-04-10 17:35:26

WOT2015谷歌資深架構(gòu)師李聰

2013-10-17 15:54:46

紅帽

2013-10-17 15:45:24

紅帽

2021-06-07 09:35:11

架構(gòu)運(yùn)維技術(shù)

2013-11-14 10:06:11

紅帽redhat

2009-02-19 16:19:48

SaaS開(kāi)發(fā)SaaS安全SaaS

2012-09-29 13:29:11

存儲(chǔ)架構(gòu)架構(gòu)緩存

2013-10-15 13:24:00

負(fù)載均衡架構(gòu)

2016-11-07 21:00:04

網(wǎng)站service架構(gòu)設(shè)計(jì)

2012-12-17 17:38:37

System CentWindows SerHyper-V

2018-07-06 11:25:40

Java架構(gòu)師面試

2020-08-24 08:50:12

架構(gòu)師TL技術(shù)

2013-01-28 10:23:12

軟件架構(gòu)師架構(gòu)師程序員

2014-09-26 09:53:41

系統(tǒng)架構(gòu)架構(gòu)架構(gòu)演變

2012-09-28 14:08:20

大型網(wǎng)站架構(gòu)大型網(wǎng)站算法算法
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)