欧美一区二区三区老妇人-欧美做爰猛烈大尺度电-99久久夜色精品国产亚洲a-亚洲福利视频一区二区

Redis為何這么快?一篇文章帶你深入了解Redis

創(chuàng)新互聯自2013年創(chuàng)立以來,先為普陀等服務建站,普陀等地企業(yè),進行企業(yè)商務咨詢服務。為普陀企業(yè)網站制作PC+手機+微官網三網同步一站式服務解決您的所有建站問題。

我們使用 redis 時,會接觸 Redis 的 5 種對象類型(字符串、哈希、列表、集合、有序集合),豐富的類型是 Redis 相對于 Memcached 等的一大優(yōu)勢。

在了解 Redis 的 5 種對象類型的用法和特點的基礎上,進一步了解 Redis 的內存模型,對 Redis 的使用有很大幫助。

Redis內存統(tǒng)計

在客戶端通過 redis-cli 連接服務器后(后面如無特殊說明,客戶端一律使用redis-cli),通過 info 命令可以查看內存使用情況:info memory。

Redis為何這么快?一篇文章帶你深入了解Redis

其中,info 命令可以顯示 Redis 服務器的許多信息,包括服務器基本信息、CPU、內存、持久化、客戶端連接信息等等;Memory 是參數,表示只顯示內存相關的信息。

返回結果中比較重要的幾個說明如下:

used_memory

Redis 分配器分配的內存總量(單位是字節(jié)),包括使用的虛擬內存(即 swap);Redis 分配器后面會介紹。used_memory_human 只是顯示更友好。

used_memory_rss

Redis 進程占據操作系統(tǒng)的內存(單位是字節(jié)),與 top 及 ps 命令看到的值是一致的。

除了分配器分配的內存之外,used_memory_rss 還包括進程運行本身需要的內存、內存碎片等,但是不包括虛擬內存。

mem_fragmentation_ratio

內存碎片比率,該值是 used_memory_rss / used_memory 的比值。

mem_fragmentation_ratio 一般大于 1,且該值越大,內存碎片比例越大;mem_fragmentation_ratio<1,說明 Redis 使用了虛擬內存,由于虛擬內存的媒介是磁盤,比內存速度要慢很多。

Redis內存劃分

Redis 作為內存數據庫,在內存中存儲的內容主要是數據(鍵值對);也有其他部分會占用內存。

Redis 的內存占用主要可以劃分為以下幾個部分:

數據

作為數據庫,數據是最主要的部分;這部分占用的內存會統(tǒng)計在 used_memory 中。

Redis 使用鍵值對存儲數據,其中的值(對象)包括 5 種類型,即字符串、哈希、列表、集合、有序集合。

進程本身運行需要的內存

Redis 主進程本身運行肯定需要占用內存,如代碼、常量池等等;這部分內存大約幾兆,在大多數生產環(huán)境中與 Redis 數據占用的內存相比可以忽略。

緩沖內存

緩沖內存包括客戶端緩沖區(qū)、復制積壓緩沖區(qū)、AOF 緩沖區(qū)等;其中,客戶端緩沖區(qū)存儲客戶端連接的輸入輸出緩沖;復制積壓緩沖區(qū)用于部分復制功能;AOF 緩沖區(qū)用于在進行 AOF 重寫時,保存最近的寫入命令。

內存碎片

內存碎片是 Redis 在分配、回收物理內存過程中產生的。例如,如果對數據的更改頻繁,而且數據之間的大小相差很大,可能導致 Redis 釋放的空間在物理內存中并沒有釋放。

但 Redis 又無法有效利用,這就形成了內存碎片,內存碎片不會統(tǒng)計在 used_memory 中。

Redis數據存儲的細節(jié)

關于 Redis 數據存儲的細節(jié),涉及到以下幾個概念。

dictEntry:Redis 是 Key-Value 數據庫,因此對每個鍵值對都會有一個 dictEntry,里面存儲了指向 Key 和 Value 的指針;next 指向下一個 dictEntry,與本 Key-Value 無關。

Key:圖中右上角可見,Key(”hello”)并不是直接以字符串存儲,而是存儲在 SDS 結構中。

下面來分別介紹 jemalloc、RedisObject、SDS、對象類型及內部編碼。

jemalloc

jemalloc 在 64 位系統(tǒng)中,將內存空間劃分為小、大、巨大三個范圍;當 Redis 存儲數據時,會選擇大小最合適的內存塊進行存儲。

jemalloc 劃分的內存單元如下圖所示:

Redis為何這么快?一篇文章帶你深入了解Redis

例如,如果需要存儲大小為 130 字節(jié)的對象,jemalloc 會將其放入 160 字節(jié)的內存單元中。

RedisObject

前面說到,Redis 對象有 5 種類型;無論是哪種類型,Redis 都不會直接存儲,而是通過 RedisObject 對象進行存儲。

SDS

Redis 沒有直接使用 C 字符串(即以空字符’’結尾的字符數組)作為默認的字符串表示,而是使用了 SDS。SDS 是簡單動態(tài)字符串(Simple Dynamic String)的縮寫。

SDS 結構

Redis為何這么快?一篇文章帶你深入了解Redis

其中,buf 表示字節(jié)數組,用來存儲字符串;len 表示 buf 已使用的長度;free 表示 buf 未使用的長度。

舉個例子:

Redis為何這么快?一篇文章帶你深入了解Redis

Redis為何這么快?一篇文章帶你深入了解Redis

通過 SDS 的結構可以看出,buf 數組的長度=free+len+1(其中 1 表示字符串結尾的空字符)。

所以,一個 SDS 結構占據的空間為:free 所占長度+len 所占長度+ buf 數組的長度=4+4+free+len+1=free+len+9。

004

Redis的對象類型與內部編碼

Redis 支持 5 種對象類型,而每種結構都有至少兩種編碼。

這樣做的好處在于:一方面接口與實現分離,當需要增加或改變內部編碼時,用戶使用不受影響,另一方面可以根據不同的應用場景切換內部編碼,提高效率。

Redis 各種對象類型支持的內部編碼如下圖所示(圖中版本是 Redis3.0):

Redis為何這么快?一篇文章帶你深入了解Redis

關于 Redis 內部編碼的轉換,都符合以下規(guī)律:編碼轉換在 Redis 寫入數據時完成,且轉換過程不可逆,只能從小內存編碼向大內存編碼轉換。

字符串

字符串是最基礎的類型,因為所有的鍵都是字符串類型,且字符串之外的其他幾種復雜類型的元素也是字符串,字符串長度不能超過 512MB。

內部編碼

字符串類型的內部編碼有 3 種,它們的應用場景如下:

int:8 個字節(jié)的長整型。字符串值是整型時,這個值使用 long 整型表示。

embstr:<=39 字節(jié)的字符串。embstr 與 raw 都使用 RedisObject 和 sds 保存數據。

區(qū)別在于:embstr 的使用只分配一次內存空間(因此 RedisObject 和 sds 是連續(xù)的),而 raw 需要分配兩次內存空間(分別為 RedisObject 和 sds 分配空間)。

raw:大于 39 個字節(jié)的字符串。

示例如下圖所示:

Redis為何這么快?一篇文章帶你深入了解Redis

embstr 和 raw 進行區(qū)分的長度,是 39;是因為 RedisObject 的長度是 16 字節(jié),sds 的長度是 9+ 字符串長度。

因此當字符串長度是 39 時,embstr 的長度正好是 16+9+39=64,jemalloc 正好可以分配 64 字節(jié)的內存單元。

編碼轉換

當 int 數據不再是整數,或大小超過了 long 的范圍時,自動轉化為 raw。而對于 embstr,由于其實現是只讀的,因此在對 embstr 對象進行修改時,都會先轉化為 raw 再進行修改。

因此,只要是修改 embstr 對象,修改后的對象一定是 raw 的,無論是否達到了 39 個字節(jié)。

示例如下圖所示:

Redis為何這么快?一篇文章帶你深入了解Redis

列表

列表(list)用來存儲多個有序的字符串,每個字符串稱為元素;一個列表可以存儲 2^32-1 個元素。

Redis 中的列表支持兩端插入和彈出,并可以獲得指定位置(或范圍)的元素,可以充當數組、隊列、棧等。

內部編碼

列表的內部編碼可以是壓縮列表(ziplist)或雙端鏈表(linkedlist)。

雙端鏈表:由一個 list 結構和多個 listNode 結構組成;典型結構如下圖所示:

Redis為何這么快?一篇文章帶你深入了解Redis

通過圖中可以看出,雙端鏈表同時保存了表頭指針和表尾指針,并且每個節(jié)點都有指向前和指向后的指針。

壓縮列表:壓縮列表是 Redis 為了節(jié)約內存而開發(fā)的,是由一系列特殊編碼的連續(xù)內存塊(而不是像雙端鏈表一樣每個節(jié)點是指針)組成的順序型數據結構,具體結構相對比較復雜。

當節(jié)點數量較少時,可以使用壓縮列表;壓縮列表不僅用于實現列表,也用于實現哈希、有序列表;使用非常廣泛。

編碼轉換

只有同時滿足下面兩個條件時,才會使用壓縮列表:列表中元素數量小于 512 個;列表中所有字符串對象都不足 64 字節(jié)。

如果有一個條件不滿足,則使用雙端列表;且編碼只可能由壓縮列表轉化為雙端鏈表,反方向則不可能。

下圖展示了列表編碼轉換的特點:

Redis為何這么快?一篇文章帶你深入了解Redis

其中,單個字符串不能超過 64 字節(jié),是為了便于統(tǒng)一分配每個節(jié)點的長度。

哈希

哈希(作為一種數據結構),不僅是 Redis 對外提供的 5 種對象類型的一種(與字符串、列表、集合、有序結合并列),也是 Redis 作為 Key-Value 數據庫所使用的數據結構。

內部編碼

內層的哈希使用的內部編碼可以是壓縮列表(ziplist)和哈希表(hashtable)2 種;Redis 的外層的哈希則只使用了 hashtable。

hashtable:一個 hashtable 由 1 個 dict 結構、2 個 dictht 結構、1 個 dictEntry 指針數組(稱為 bucket)和多個 dictEntry 結構組成。

正常情況下(即 hashtable 沒有進行 rehash 時),各部分關系如下圖所示:

Redis為何這么快?一篇文章帶你深入了解Redis

下面從底層向上依次介紹各個部分:

dictEntry:dictEntry 結構用于保存鍵值對,結構定義如下。

Redis為何這么快?一篇文章帶你深入了解Redis

其中,各個屬性的功能如下:

  • key:鍵值對中的鍵。

  • val:鍵值對中的值,使用 union(即共用體)實現,存儲的內容既可能是一個指向值的指針,也可能是 64 位整型,或無符號 64 位整型。

  • next:指向下一個 dictEntry,用于解決哈希沖突問題。

在 64 位系統(tǒng)中,一個 dictEntry 對象占 24 字節(jié)(key/val/next 各占 8 字節(jié))。

bucket:bucket 是一個數組,數組的每個元素都是指向 dictEntry 結構的指針。Redis 中 bucket 數組的大小計算規(guī)則如下:大于 dictEntry 的、最小的 2^n。

例如,如果有 1000 個 dictEntry,那么 bucket 大小為 1024;如果有 1500 個 dictEntry,則 bucket 大小為 2048。

編碼轉換

下圖展示了 Redis 內層的哈希編碼轉換的特點:

Redis為何這么快?一篇文章帶你深入了解Redis

集合

集合中的元素是無序的,因此不能通過索引來操作元素;集合中的元素不能有重復。一個集合中最多可以存儲 2^32-1 個元素。

內部編碼

集合的內部編碼可以是整數集合(intset)或哈希表(hashtable)。

整數集合的結構定義如下:

Redis為何這么快?一篇文章帶你深入了解Redis

其中,encoding 代表 contents 中存儲內容的類型,雖然 contents(存儲集合中的元素)是 int8_t 類型。

但實際上其存儲的值是 int16_t、int32_t 或 int64_t,具體的類型便是由 encoding 決定的,length 表示元素個數。

編碼轉換

下圖展示了集合編碼轉換的特點:

Redis為何這么快?一篇文章帶你深入了解Redis

有序集合

有序集合與集合一樣,元素都不能重復;但與集合不同的是,有序集合中的元素是有順序的。有序集合為每個元素設置一個分數(score)作為排序依據。

內部編碼

跳躍表是一種有序數據結構,通過在每個節(jié)點中維持多個指向其他節(jié)點的指針,從而達到快速訪問節(jié)點的目的。

Redis 的跳躍表實現由 zskiplist 和 zskiplistNode 兩個結構組成:前者用于保存跳躍表信息(如頭結點、尾節(jié)點、長度等),后者用于表示跳躍表節(jié)點,具體結構相對比較復雜。

編碼轉換

只有同時滿足下面兩個條件時,才會使用壓縮列表:有序集合中元素數量小于 128 個;有序集合中所有成員長度都不足 64 字節(jié)。

如果有一個條件不滿足,則使用跳躍表;且編碼只可能由壓縮列表轉化為跳躍表,反方向則不可能。

下圖展示了有序集合編碼轉換的特點:

Redis為何這么快?一篇文章帶你深入了解Redis

Redis在國內外各大公司都能看到其身影,比如我們熟悉的新浪,阿里,騰訊,百度,搜狐,優(yōu)酷,美團,小米等等。

零基礎學習Redis,這幾方面尤其重要:Redis 客戶端、Redis 高級功能、Redis 持久化和開發(fā)運維常用問題探討、Redis 復制的原理和優(yōu)化策略、Redis 分布式解決方案等。

文章標題:Redis為何這么快?一篇文章帶你深入了解Redis
本文URL:http://chinadenli.net/article18/jggegp.html

成都網站建設公司_創(chuàng)新互聯,為您提供面包屑導航、網站收錄虛擬主機、動態(tài)網站、企業(yè)建站、網站導航

廣告

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

網站托管運營
特黄大片性高水多欧美一级| 国产又粗又长又大高潮视频| 精品少妇一区二区三区四区| 福利一区二区视频在线| 欧美黑人在线精品极品| 日韩美女偷拍视频久久| 微拍一区二区三区福利| 在线视频免费看你懂的| 欧美日韩国产的另类视频| 激情五月综五月综合网| 欧美日韩国产精品第五页| 少妇人妻中出中文字幕| 日本深夜福利在线播放| 不卡免费成人日韩精品| 日本人妻中出在线观看| 国产午夜精品福利免费不| 国产又大又硬又粗又黄| 欧美日韩亚洲精品内裤| 亚洲黄片在线免费小视频| 日韩一区二区三区在线日| 丝袜美女诱惑在线观看| 激情丁香激情五月婷婷| 日韩在线中文字幕不卡| 色婷婷成人精品综合一区| 好吊日视频这里都是精品| 五月激情婷婷丁香六月网| 欧美成人免费夜夜黄啪啪| 黄色美女日本的美女日人| 国产又粗又长又大的视频| 国产又粗又爽又猛又黄的| 国产视频一区二区三区四区| 日本高清视频在线播放| 黄片在线观看一区二区三区| 老司机精品福利视频在线播放| 婷婷基地五月激情五月| 久久这里只精品免费福利| 久久亚洲国产视频三级黄| 91人妻人人澡人人人人精品| 亚洲国产精品国自产拍社区| 亚洲成人精品免费在线观看| 熟妇久久人妻中文字幕|