完美世界有声小说全集,管理书籍排行榜

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

一文搞懂Redis

作者 | 一洺

一、什么是NoSQL?

Nosql = not only sql(不僅僅是SQL)。

關(guān)系型數(shù)據(jù)庫：列+行，同一個(gè)表下數(shù)據(jù)的結(jié)構(gòu)是一樣的。

非關(guān)系型數(shù)據(jù)庫：數(shù)據(jù)存儲(chǔ)沒有固定的格式，并且可以進(jìn)行橫向擴(kuò)展。

NoSQL泛指非關(guān)系型數(shù)據(jù)庫，隨著web2.0互聯(lián)網(wǎng)的誕生，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫很難對(duì)付web2.0大數(shù)據(jù)時(shí)代!尤其是超大規(guī)模的高并發(fā)的社區(qū)，暴露出來很多難以克服的問題，NoSQL在當(dāng)今大數(shù)據(jù)環(huán)境下發(fā)展的十分迅速，Redis是發(fā)展最快的。

傳統(tǒng)RDBMS和NoSQL

RDBMS
 - 組織化結(jié)構(gòu)
 - 固定SQL
 - 數(shù)據(jù)和關(guān)系都存在單獨(dú)的表中（行列）
 - DML（數(shù)據(jù)操作語言）、DDL（數(shù)據(jù)定義語言）等
 - 嚴(yán)格的一致性（ACID): 原子性、一致性、隔離性、持久性
 - 基礎(chǔ)的事務(wù)

NoSQL
 - 不僅僅是數(shù)據(jù)
 - 沒有固定查詢語言
 - 鍵值對(duì)存儲(chǔ)（redis）、列存儲(chǔ)（HBase）、文檔存儲(chǔ)（MongoDB）、圖形數(shù)據(jù)庫（不是存圖形，放的是關(guān)系）（Neo4j）
 - 最終一致性（BASE）：基本可用、軟狀態(tài)/柔性事務(wù)、最終一致性

二、Redis是什么?

Redis = Remote Dictionary Server，即遠(yuǎn)程字典服務(wù)。

是一個(gè)開源的使用ANSI C語言編寫、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫，并提供多種語言的API。

與memcached一樣，為了保證效率，數(shù)據(jù)都是緩存在內(nèi)存中。區(qū)別的是redis會(huì)周期性的把更新的數(shù)據(jù)寫入磁盤或者把修改操作寫入追加的記錄文件，并且在此基礎(chǔ)上實(shí)現(xiàn)了master-slave(主從)同步。

三、Redis五大基本類型

Redis是一個(gè)開源，內(nèi)存存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)服務(wù)器，可用作數(shù)據(jù)庫，高速緩存和消息隊(duì)列代理。它支持字符串、哈希表、列表、集合、有序集合，位圖，hyperloglogs等數(shù)據(jù)類型。內(nèi)置復(fù)制、Lua腳本、LRU收回、事務(wù)以及不同級(jí)別磁盤持久化功能，同時(shí)通過Redis Sentinel提供高可用，通過Redis Cluster提供自動(dòng)分區(qū)。

由于redis類型大家很熟悉，且網(wǎng)上命令使用介紹很多，下面重點(diǎn)介紹五大基本類型的底層數(shù)據(jù)結(jié)構(gòu)與應(yīng)用場(chǎng)景，以便當(dāng)開發(fā)時(shí)，可以熟練使用redis。

1.String(字符串)

（1）String類型是redis的最基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu)，也是最經(jīng)常使用到的類型。而且其他的四種類型多多少少都是在字符串類型的基礎(chǔ)上構(gòu)建的，所以String類型是redis的基礎(chǔ)。

（2）String 類型的值最大能存儲(chǔ) 512MB，這里的String類型可以是簡單字符串、復(fù)雜的xml/json的字符串、二進(jìn)制圖像或者音頻的字符串、以及可以是數(shù)字的字符串。

應(yīng)用場(chǎng)景

（1）緩存功能：String字符串是最常用的數(shù)據(jù)類型，不僅僅是redis，各個(gè)語言都是最基本類型，因此，利用redis作為緩存，配合其它數(shù)據(jù)庫作為存儲(chǔ)層，利用redis支持高并發(fā)的特點(diǎn)，可以大大加快系統(tǒng)的讀寫速度、以及降低后端數(shù)據(jù)庫的壓力。

（2）計(jì)數(shù)器：許多系統(tǒng)都會(huì)使用redis作為系統(tǒng)的實(shí)時(shí)計(jì)數(shù)器，可以快速實(shí)現(xiàn)計(jì)數(shù)和查詢的功能。而且最終的數(shù)據(jù)結(jié)果可以按照特定的時(shí)間落地到數(shù)據(jù)庫或者其它存儲(chǔ)介質(zhì)當(dāng)中進(jìn)行永久保存。

（3）統(tǒng)計(jì)多單位的數(shù)量：eg，uid：gongming count：0 根據(jù)不同的uid更新count數(shù)量。

（4）共享用戶session：用戶重新刷新一次界面，可能需要訪問一下數(shù)據(jù)進(jìn)行重新登錄，或者訪問頁面緩存cookie，這兩種方式做有一定弊端，1)每次都重新登錄效率低下 2)cookie保存在客戶端，有安全隱患。這時(shí)可以利用redis將用戶的session集中管理，在這種模式只需要保證redis的高可用，每次用戶session的更新和獲取都可以快速完成。大大提高效率。

2.List(列表)

list類型是用來存儲(chǔ)多個(gè)有序的字符串的，列表當(dāng)中的每一個(gè)字符看做一個(gè)元素
一個(gè)列表當(dāng)中可以存儲(chǔ)有一個(gè)或者多個(gè)元素，redis的list支持存儲(chǔ)2^32次方-1個(gè)元素。
redis可以從列表的兩端進(jìn)行插入（pubsh）和彈出（pop）元素，支持讀取指定范圍的元素集，
  或者讀取指定下標(biāo)的元素等操作。redis列表是一種比較靈活的鏈表數(shù)據(jù)結(jié)構(gòu)，它可以充當(dāng)隊(duì)列或者棧的角色。
redis列表是鏈表型的數(shù)據(jù)結(jié)構(gòu)，所以它的元素是有序的，而且列表內(nèi)的元素是可以重復(fù)的。
  意味著它可以根據(jù)鏈表的下標(biāo)獲取指定的元素和某個(gè)范圍內(nèi)的元素集。

應(yīng)用場(chǎng)景

（1）消息隊(duì)列：reids的鏈表結(jié)構(gòu)，可以輕松實(shí)現(xiàn)阻塞隊(duì)列，可以使用左進(jìn)右出的命令組成來完成隊(duì)列的設(shè)計(jì)。比如：數(shù)據(jù)的生產(chǎn)者可以通過Lpush命令從左邊插入數(shù)據(jù)，多個(gè)數(shù)據(jù)消費(fèi)者，可以使用BRpop命令阻塞的“搶”列表尾部的數(shù)據(jù)。

（2）文章列表或者數(shù)據(jù)分頁展示的應(yīng)用。比如，我們常用的博客網(wǎng)站的文章列表，當(dāng)用戶量越來越多時(shí)，而且每一個(gè)用戶都有自己的文章列表，而且當(dāng)文章多時(shí)，都需要分頁展示，這時(shí)可以考慮使用redis的列表，列表不但有序同時(shí)還支持按照范圍內(nèi)獲取元素，可以完美解決分頁查詢功能。大大提高查詢效率。

3.Set(集合)

.redis集合（set）類型和list列表類型類似，都可以用來存儲(chǔ)多個(gè)字符串元素的集合。
但是和list不同的是set集合當(dāng)中不允許重復(fù)的元素。而且set集合當(dāng)中元素是沒有順序的，不存在元素下標(biāo)。
redis的set類型是使用哈希表構(gòu)造的，因此復(fù)雜度是O(1)，它支持集合內(nèi)的增刪改查，
并且支持多個(gè)集合間的交集、并集、差集操作?？梢岳眠@些集合操作，解決程序開發(fā)過程當(dāng)中很多數(shù)據(jù)集合間的問題。

（1）標(biāo)簽：比如我們博客網(wǎng)站常常使用到的興趣標(biāo)簽，把一個(gè)個(gè)有著相同愛好，關(guān)注類似內(nèi)容的用戶利用一個(gè)標(biāo)簽把他們進(jìn)行歸并。

（2）共同好友功能，共同喜好，或者可以引申到二度好友之類的擴(kuò)展應(yīng)用。

（3）統(tǒng)計(jì)網(wǎng)站的獨(dú)立IP。利用set集合當(dāng)中元素不唯一性，可以快速實(shí)時(shí)統(tǒng)計(jì)訪問網(wǎng)站的獨(dú)立IP。

數(shù)據(jù)結(jié)構(gòu)

set的底層結(jié)構(gòu)相對(duì)復(fù)雜寫，使用了intset和hashtable兩種數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)，intset可以理解為數(shù)組。

4.sorted set(有序集合)

redis有序集合也是集合類型的一部分，所以它保留了集合中元素不能重復(fù)的特性，但是不同的是，有序集合給每個(gè)元素多設(shè)置了一個(gè)分?jǐn)?shù)。

redis有序集合也是集合類型的一部分，所以它保留了集合中元素不能重復(fù)的特性，但是不同的是，
有序集合給每個(gè)元素多設(shè)置了一個(gè)分?jǐn)?shù)，利用該分?jǐn)?shù)作為排序的依據(jù)。

應(yīng)用場(chǎng)景

（1）排行榜：有序集合經(jīng)典使用場(chǎng)景。例如視頻網(wǎng)站需要對(duì)用戶上傳的視頻做排行榜，榜單維護(hù)可能是多方面：按照時(shí)間、按照播放量、按照獲得的贊數(shù)等。

（2）用Sorted Sets來做帶權(quán)重的隊(duì)列，比如普通消息的score為1，重要消息的score為2，然后工作線程可以選擇按score的倒序來獲取工作任務(wù)。讓重要的任務(wù)優(yōu)先執(zhí)行。

5.hash(哈希)

Redis hash數(shù)據(jù)結(jié)構(gòu) 是一個(gè)鍵值對(duì)（key-value）集合,它是一個(gè) string 類型的 field 和 value 的映射表，
redis本身就是一個(gè)key-value型數(shù)據(jù)庫，因此hash數(shù)據(jù)結(jié)構(gòu)相當(dāng)于在value中又套了一層key-value型數(shù)據(jù)。
所以redis中hash數(shù)據(jù)結(jié)構(gòu)特別適合存儲(chǔ)關(guān)系型對(duì)象

應(yīng)用場(chǎng)景

（1）由于hash數(shù)據(jù)類型的key-value的特性，用來存儲(chǔ)關(guān)系型數(shù)據(jù)庫中表記錄，是redis中哈希類型最常用的場(chǎng)景。一條記錄作為一個(gè)key-value，把每列屬性值對(duì)應(yīng)成field-value存儲(chǔ)在哈希表當(dāng)中，然后通過key值來區(qū)分表當(dāng)中的主鍵。

（2）經(jīng)常被用來存儲(chǔ)用戶相關(guān)信息。優(yōu)化用戶信息的獲取，不需要重復(fù)從數(shù)據(jù)庫當(dāng)中讀取，提高系統(tǒng)性能。

四、五大基本類型底層數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)

在學(xué)習(xí)基本類型底層數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)前，首先看下redis整體的存儲(chǔ)結(jié)構(gòu)。

redis內(nèi)部整體的存儲(chǔ)結(jié)構(gòu)是一個(gè)大的hashmap，內(nèi)部是數(shù)組實(shí)現(xiàn)的hash，key沖突通過掛鏈表去實(shí)現(xiàn)，每個(gè)dictEntry為一個(gè)key/value對(duì)象，value為定義的redisObject。

結(jié)構(gòu)圖如下：

dictEntry是存儲(chǔ)key->value的地方，再讓我們看一下dictEntry結(jié)構(gòu)體。

/*
 * 字典
 */
typedef struct dictEntry {
    // 鍵
    void *key;
    // 值
    union {
        // 指向具體redisObject
        void *val;
        // 
        uint64_t u64;
        int64_t s64;
    } v;
    // 指向下個(gè)哈希表節(jié)點(diǎn)，形成鏈表
    struct dictEntry *next;
} dictEntry;

1.redisObject

我們接著再往下看redisObject究竟是什么結(jié)構(gòu)的。

/*
 * Redis 對(duì)象
 */
typedef struct redisObject {
    // 類型 4bits
    unsigned type:4;
    // 編碼方式 4bits
    unsigned encoding:4;
    // LRU 時(shí)間（相對(duì)于 server.lruclock） 24bits
    unsigned lru:22;
    // 引用計(jì)數(shù) Redis里面的數(shù)據(jù)可以通過引用計(jì)數(shù)進(jìn)行共享 32bits
    int refcount;
    // 指向?qū)ο蟮闹?64-bit
    void *ptr;
} robj;

*ptr指向具體的數(shù)據(jù)結(jié)構(gòu)的地址;type表示該對(duì)象的類型，即String,List,Hash,Set,Zset中的一個(gè)，但為了提高存儲(chǔ)效率與程序執(zhí)行效率，每種對(duì)象的底層數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)都可能不止一種，encoding 表示對(duì)象底層所使用的編碼。

redis對(duì)象底層的八種數(shù)據(jù)結(jié)構(gòu)

REDIS_ENCODING_INT（long 類型的整數(shù)）
 REDIS_ENCODING_EMBSTR embstr （編碼的簡單動(dòng)態(tài)字符串）
 REDIS_ENCODING_RAW （簡單動(dòng)態(tài)字符串）
 REDIS_ENCODING_HT （字典）
 REDIS_ENCODING_LINKEDLIST （雙端鏈表）
 REDIS_ENCODING_ZIPLIST （壓縮列表）
 REDIS_ENCODING_INTSET （整數(shù)集合）
 REDIS_ENCODING_SKIPLIST （跳躍表和字典）

好了，通過redisObject就可以具體指向redis數(shù)據(jù)類型了，總結(jié)一下每種數(shù)據(jù)類型都使用了哪些數(shù)據(jù)結(jié)構(gòu)，如下圖所示：

前期準(zhǔn)備知識(shí)已準(zhǔn)備完畢，下面分每種基本類型來講。

2.String數(shù)據(jù)結(jié)構(gòu)

String類型的轉(zhuǎn)換順序

當(dāng)保存的值為整數(shù)且值的大小不超過long的范圍，使用整數(shù)存儲(chǔ)。
當(dāng)字符串長度不超過44字節(jié)時(shí)，使用EMBSTR 編碼。

它只分配一次內(nèi)存空間，redisObject和sds是連續(xù)的內(nèi)存，查詢效率會(huì)快很多，也正是因?yàn)閞edisObject和sds是連續(xù)在一起，伴隨了一些缺點(diǎn)：當(dāng)字符串增加的時(shí)候，它長度會(huì)增加，這個(gè)時(shí)候又需要重新分配內(nèi)存，導(dǎo)致的結(jié)果就是整個(gè)redisObject和sds都需要重新分配空間，這樣是會(huì)影響性能的，所以redis用embstr實(shí)現(xiàn)一次分配而后,只允許讀，如果修改數(shù)據(jù)，那么它就會(huì)轉(zhuǎn)成raw編碼，不再用embstr編碼了。

大于44字符時(shí)，使用raw編碼。

SDS

embstr和raw都為sds編碼，看一下sds的結(jié)構(gòu)體：

/* 針對(duì)不同長度整形做了相應(yīng)的數(shù)據(jù)結(jié)構(gòu)
 * Note: sdshdr5 is never used, we just access the flags byte directly.
 * However is here to document the layout of type 5 SDS strings. 
 */
struct __attribute__ ((__packed__)) sdshdr5 {
    unsigned char flags; /* 3 lsb of type, and 5 msb of string length */
    char buf[];
};

struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len; /* used */
    uint8_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};

struct __attribute__ ((__packed__)) sdshdr16 {
    uint16_t len; /* used */
    uint16_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};

struct __attribute__ ((__packed__)) sdshdr32 {
    uint32_t len; /* used */
    uint32_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};

struct __attribute__ ((__packed__)) sdshdr64 {
    uint64_t len; /* used */
    uint64_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};

由于redis底層使用c語言實(shí)現(xiàn)，可能會(huì)有疑問為什么不用c語言的字符串呢，而是用sds結(jié)構(gòu)體。

1) 低復(fù)雜度獲取字符串長度：由于len存在，可以直接查出字符串長度，復(fù)雜度O(1);如果用c語言字符串，查詢字符串長度需要遍歷整個(gè)字符串，復(fù)雜度為O(n);

2) 避免緩沖區(qū)溢出：進(jìn)行兩個(gè)字符串拼接c語言可使用strcat函數(shù)，但如果沒有足夠的內(nèi)存空間。就會(huì)造成緩沖區(qū)溢出;而用sds在進(jìn)行合并時(shí)會(huì)先用len檢查內(nèi)存空間是否滿足需求，如果不滿足，進(jìn)行空間擴(kuò)展，不會(huì)造成緩沖區(qū)溢出;

3)減少修改字符串的內(nèi)存重新分配次數(shù)：c語言字符串不記錄字符串長度，如果要修改字符串要重新分配內(nèi)存，如果不進(jìn)行重新分配會(huì)造成內(nèi)存緩沖區(qū)泄露;

redis sds實(shí)現(xiàn)了空間預(yù)分配和惰性空間釋放兩種策略。

空間預(yù)分配：

1)如果sds修改后，sds長度(len的值)將于1mb，那么會(huì)分配與len相同大小的未使用空間，此時(shí)len與free值相同。例如，修改之后字符串長度為100字節(jié)，那么會(huì)給分配100字節(jié)的未使用空間。最終sds空間實(shí)際為 100 + 100 + 1(保存空字符'\0');

2)如果大于等于1mb，每次給分配1mb未使用空間惰性空間釋放：對(duì)字符串進(jìn)行縮短操作時(shí)，程序不立即使用內(nèi)存重新分配來回收縮短后多余的字節(jié)，而是使用 free 屬性將這些字節(jié)的數(shù)量記錄下來，等待后續(xù)使用(sds也提供api，我們可以手動(dòng)觸發(fā)字符串縮短);

3)二進(jìn)制安全：因?yàn)镃字符串以空字符作為字符串結(jié)束的標(biāo)識(shí)，而對(duì)于一些二進(jìn)制文件(如圖片等)，內(nèi)容可能包括空字符串，因此C字符串無法正確存取;而所有 SDS 的API 都是以處理二進(jìn)制的方式來處理 buf 里面的元素，并且 SDS 不是以空字符串來判斷是否結(jié)束，而是以 len 屬性表示的長度來判斷字符串是否結(jié)束;

4)遵從每個(gè)字符串都是以空字符串結(jié)尾的慣例，這樣可以重用 C 語言庫中的一部分函數(shù)。

學(xué)習(xí)完sds，我們回到上面講到的，為什么小于44字節(jié)用embstr編碼呢?

再看一下rejectObject和sds定義的結(jié)構(gòu)(短字符串的embstr用最小的sdshdr8)。

typedef struct redisObject {
    // 類型 4bits
    unsigned type:4;
    // 編碼方式 4bits
    unsigned encoding:4;
    // LRU 時(shí)間（相對(duì)于 server.lruclock） 24bits
    unsigned lru:22;
    // 引用計(jì)數(shù) Redis里面的數(shù)據(jù)可以通過引用計(jì)數(shù)進(jìn)行共享 32bits
    int refcount;
    // 指向?qū)ο蟮闹?64-bit
    void *ptr;
} robj;

struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len; /* used */
    uint8_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};

redisObject占用空間

4 + 4 + 24 + 32 + 64 = 128bits = 16字節(jié)。

sdshdr8占用空間

1(uint8_t) + 1(uint8_t)+ 1 (unsigned char)+ 1(buf[]中結(jié)尾的'\0'字符)= 4字節(jié)。

初始最小分配為64字節(jié)，所以只分配一次空間的embstr最大為 64 - 16- 4 = 44字節(jié)。

3.List存儲(chǔ)結(jié)構(gòu)

（1）Redis3.2之前的底層實(shí)現(xiàn)方式：壓縮列表ziplist 或者雙向循環(huán)鏈表linkedlist。

當(dāng)list存儲(chǔ)的數(shù)據(jù)量比較少且同時(shí)滿足下面兩個(gè)條件時(shí)，list就使用ziplist存儲(chǔ)數(shù)據(jù)：

list中保存的每個(gè)元素的長度小于 64 字節(jié);
列表中數(shù)據(jù)個(gè)數(shù)少于512個(gè)。

（2）Redis3.2及之后的底層實(shí)現(xiàn)方式：quicklist。

quicklist是一個(gè)雙向鏈表，而且是一個(gè)基于ziplist的雙向鏈表，quicklist的每個(gè)節(jié)點(diǎn)都是一個(gè)ziplist，結(jié)合了雙向鏈表和ziplist的優(yōu)點(diǎn)。

ziplist

ziplist是一種壓縮鏈表，它的好處是更能節(jié)省內(nèi)存空間，因?yàn)樗鎯?chǔ)的內(nèi)容都是在連續(xù)的內(nèi)存區(qū)域當(dāng)中的。當(dāng)列表對(duì)象元素不大，每個(gè)元素也不大的時(shí)候，就采用ziplist存儲(chǔ)。但當(dāng)數(shù)據(jù)量過大時(shí)就ziplist就不是那么好用了。因?yàn)闉榱吮ＷC他存儲(chǔ)內(nèi)容在內(nèi)存中的連續(xù)性，插入的復(fù)雜度是O(N)，即每次插入都會(huì)重新進(jìn)行realloc。如下圖所示，redisObject對(duì)象結(jié)構(gòu)中ptr所指向的就是一個(gè)ziplist。整個(gè)ziplist只需要malloc一次，它們?cè)趦?nèi)存中是一塊連續(xù)的區(qū)域。

ziplist結(jié)構(gòu)如下：

（1）zlbytes:用于記錄整個(gè)壓縮列表占用的內(nèi)存字節(jié)數(shù)。

（2）zltail：記錄要列表尾節(jié)點(diǎn)距離壓縮列表的起始地址有多少字節(jié)　。

（3）zllen：記錄了壓縮列表包含的節(jié)點(diǎn)數(shù)量。

（4）entryX：要說列表包含的各個(gè)節(jié)點(diǎn)。

（5）zlend：用于標(biāo)記壓縮列表的末端。

為什么數(shù)據(jù)量大時(shí)不用ziplist?

因?yàn)閦iplist是一段連續(xù)的內(nèi)存，插入的時(shí)間復(fù)雜化度為O(n)，而且每當(dāng)插入新的元素需要realloc做內(nèi)存擴(kuò)展;而且如果超出ziplist內(nèi)存大小，還會(huì)做重新分配的內(nèi)存空間，并將內(nèi)容復(fù)制到新的地址。如果數(shù)量大的話，重新分配內(nèi)存和拷貝內(nèi)存會(huì)消耗大量時(shí)間。所以不適合大型字符串，也不適合存儲(chǔ)量多的元素。

快速列表(quickList)

快速列表是ziplist和linkedlist的混合體，是將linkedlist按段切分，每一段用ziplist來緊湊存儲(chǔ)，多個(gè)ziplist之間使用雙向指針鏈接。

為什么不直接使用linkedlist?

linkedlist的附加空間相對(duì)太高，prev和next指針就要占去16個(gè)字節(jié)，而且每一個(gè)結(jié)點(diǎn)都是單獨(dú)分配，會(huì)加劇內(nèi)存的碎片化，影響內(nèi)存管理效率。

quicklist結(jié)構(gòu)

typedef struct quicklist {
    // 指向quicklist的頭部
    quicklistNode *head;
    // 指向quicklist的尾部
    quicklistNode *tail;
    unsigned long count;
    unsigned int len;
    // ziplist大小限定，由list-max-ziplist-size給定
    int fill : 16;
    // 節(jié)點(diǎn)壓縮深度設(shè)置，由list-compress-depth給定
    unsigned int compress : 16;
} quicklist;

typedef struct quicklistNode {
    // 指向上一個(gè)ziplist節(jié)點(diǎn)
    struct quicklistNode *prev;
    // 指向下一個(gè)ziplist節(jié)點(diǎn)
    struct quicklistNode *next;
    // 數(shù)據(jù)指針，如果沒有被壓縮，就指向ziplist結(jié)構(gòu)，反之指向quicklistLZF結(jié)構(gòu)
    unsigned char *zl;
    // 表示指向ziplist結(jié)構(gòu)的總長度(內(nèi)存占用長度)
    unsigned int sz;
    // ziplist數(shù)量
    unsigned int count : 16;     /* count of items in ziplist */
    unsigned int encoding : 2;   /* RAW==1 or LZF==2 */
    // 預(yù)留字段，存放數(shù)據(jù)的方式，1--NONE，2--ziplist
    unsigned int container : 2;  /* NONE==1 or ZIPLIST==2 */
    // 解壓標(biāo)記，當(dāng)查看一個(gè)被壓縮的數(shù)據(jù)時(shí)，需要暫時(shí)解壓，標(biāo)記此參數(shù)為1，之后再重新進(jìn)行壓縮
    unsigned int recompress : 1; /* was this node previous compressed? */
    unsigned int attempted_compress : 1; /* node can't compress; too small */
    // 擴(kuò)展字段
    unsigned int extra : 10; /* more bits to steal for future usage */
} quicklistNode;

typedef struct quicklistLZF {
    // LZF壓縮后占用的字節(jié)數(shù)
    unsigned int sz; /* LZF size in bytes*/
    // 柔性數(shù)組，存放壓縮后的ziplist字節(jié)數(shù)組
    char compressed[];
} quicklistLZF;

結(jié)構(gòu)圖如下：

ziplist的長度

quicklist內(nèi)部默認(rèn)單個(gè)ziplist長度為8k字節(jié)，超出了這個(gè)字節(jié)數(shù)，就會(huì)新起一個(gè)ziplist。關(guān)于長度可以使用list-max-ziplist-size決定。

壓縮深度

我們上面說到了quicklist下是用多個(gè)ziplist組成的，同時(shí)為了進(jìn)一步節(jié)約空間，Redis還會(huì)對(duì)ziplist進(jìn)行壓縮存儲(chǔ)，使用LZF算法壓縮，可以選擇壓縮深度。quicklist默認(rèn)的壓縮深度是0，也就是不壓縮。壓縮的實(shí)際深度由配置參數(shù)list-compress-depth決定。為了支持快速push/pop操作，quicklist 的首尾兩個(gè) ziplist 不壓縮，此時(shí)深度就是 1。如果深度為 2，就表示 quicklist 的首尾第一個(gè) ziplist 以及首尾第二個(gè) ziplist 都不壓縮。

4.Hash類型

當(dāng)Hash中數(shù)據(jù)項(xiàng)比較少的情況下，Hash底層才用壓縮列表ziplist進(jìn)行存儲(chǔ)數(shù)據(jù)，隨著數(shù)據(jù)的增加，底層的ziplist就可能會(huì)轉(zhuǎn)成dict，具體配置如下：

hash-max-ziplist-entries 512
hash-max-ziplist-value 64

在List中已經(jīng)介紹了ziplist，下面來介紹下dict。

看下數(shù)據(jù)結(jié)構(gòu)：

typedef struct dict {
    dictType *type;
    void *privdata;
    dictht ht[2];
    long rehashidx; /* rehashing not in progress if rehashidx == -1 */
    int iterators; /* number of iterators currently running */
} dict;

typedef struct dictht {
    //指針數(shù)組，這個(gè)hash的桶
    dictEntry **table;
    //元素個(gè)數(shù)
    unsigned long size;
    unsigned long sizemask;
    unsigned long used;
} dictht;

dictEntry大家應(yīng)該熟悉，在上面有講，使用來真正存儲(chǔ)key->value的地方
typedef struct dictEntry {
    // 鍵
    void *key;
    // 值
    union {
        // 指向具體redisObject
        void *val;
        // 
        uint64_t u64;
        int64_t s64;
    } v;
    // 指向下個(gè)哈希表節(jié)點(diǎn)，形成鏈表
    struct dictEntry *next;
} dictEntry;

我們可以看到每個(gè)dict中都有兩個(gè)hashtable。

結(jié)構(gòu)圖如下：

雖然dict結(jié)構(gòu)有兩個(gè)hashtable，但是通常情況下只有一個(gè)hashtable是有值的。但是在dict擴(kuò)容縮容的時(shí)候，需要分配新的hashtable，然后進(jìn)行漸近式搬遷，這時(shí)候兩個(gè)hashtable存儲(chǔ)的舊的hashtable和新的hashtable。搬遷結(jié)束后，舊hashtable刪除，新的取而代之。

下面讓我們學(xué)習(xí)下rehash全貌。

5.漸進(jìn)式rehash

所謂漸進(jìn)式rehash是指我們的大字典的擴(kuò)容是比較消耗時(shí)間的，需要重新申請(qǐng)新的數(shù)組，然后將舊字典所有鏈表的元素重新掛接到新的數(shù)組下面，是一個(gè)O(n)的操作。但是因?yàn)槲覀兊膔edis是單線程的，無法承受這樣的耗時(shí)過程，所以采用了漸進(jìn)式rehash小步搬遷，雖然慢一點(diǎn)，但是可以搬遷完畢。

擴(kuò)容條件

我們的擴(kuò)容一般會(huì)在Hash表中的元素個(gè)數(shù)等于第一維數(shù)組的長度的時(shí)候，就會(huì)開始擴(kuò)容。擴(kuò)容的大小是原數(shù)組的兩倍。不過在redis在做bgsave(RDB持久化操作的過程)，為了減少內(nèi)存頁的過多分離(Copy On Write)，redis不會(huì)去擴(kuò)容。但是如果hash表的元素個(gè)數(shù)已經(jīng)到達(dá)了第一維數(shù)組長度的5倍的時(shí)候，就會(huì)強(qiáng)制擴(kuò)容，不管你是否在持久化。

不擴(kuò)容主要是為了盡可能減少內(nèi)存頁過多分離，系統(tǒng)需要更多的開銷去回收內(nèi)存。

縮容條件

當(dāng)我們的hash表元素逐漸刪除的越來越少的時(shí)候。redis于是就會(huì)對(duì)hash表進(jìn)行縮容來減少第一維數(shù)組長度的空間占用?？s容的條件是元素個(gè)數(shù)低于數(shù)組長度的10%，并且縮容不考慮是否在做redis持久化。

不用考慮bgsave主要是因?yàn)槲覀兊目s容的內(nèi)存都是已經(jīng)使用過的，縮容的時(shí)候可以直接置空，而且由于申請(qǐng)的內(nèi)存比較小，同時(shí)會(huì)釋放掉一些已經(jīng)使用的內(nèi)存，不會(huì)增大系統(tǒng)的壓力。

rehash步驟

（1）為ht[1] 分配空間，讓字典同時(shí)持有ht[0]和ht[1]兩個(gè)哈希表;

（2）定時(shí)維持一個(gè)索引計(jì)數(shù)器變量rehashidx，并將它的值設(shè)置為0，表示rehash 開始;

（3）在rehash進(jìn)行期間，每次對(duì)字典執(zhí)行CRUD操作時(shí)，程序除了執(zhí)行指定的操作以外，還會(huì)將ht[0]中的數(shù)據(jù)rehash 到ht[1]表中，并且將rehashidx加一;

（4）當(dāng)ht[0]中所有數(shù)據(jù)轉(zhuǎn)移到ht[1]中時(shí)，將rehashidx 設(shè)置成-1，表示rehash 結(jié)束;

(采用漸進(jìn)式rehash 的好處在于它采取分而治之的方式，避免了集中式rehash 帶來的龐大計(jì)算量。特別的在進(jìn)行rehash時(shí)只能對(duì)h[0]元素減少的操作，如查詢和刪除;而查詢是在兩個(gè)哈希表中查找的，而插入只能在ht[1]中進(jìn)行，ht[1]也可以查詢和刪除。)

（5）將ht[0]釋放，然后將ht[1]設(shè)置成ht[0]，最后為ht[1]分配一個(gè)空白哈希表。

過程如下圖：

6.set數(shù)據(jù)結(jié)構(gòu)

Redis 的集合相當(dāng)于Java中的 HashSet，它內(nèi)部的鍵值對(duì)是無序、唯一的。它的內(nèi)部實(shí)現(xiàn)相當(dāng)于一個(gè)特殊的字典，字典中所有的 value 都是一個(gè)值 NULL。集合Set類型底層編碼包括hashtable和inset。

當(dāng)存儲(chǔ)的數(shù)據(jù)同時(shí)滿足下面這樣兩個(gè)條件的時(shí)候，Redis 就采用整數(shù)集合intset來實(shí)現(xiàn)set這種數(shù)據(jù)類型：

存儲(chǔ)的數(shù)據(jù)都是整數(shù)
存儲(chǔ)的數(shù)據(jù)元素個(gè)數(shù)小于512個(gè)

當(dāng)不能同時(shí)滿足這兩個(gè)條件的時(shí)候，Redis 就使用dict來存儲(chǔ)集合中的數(shù)據(jù)。

hashtable在上面介紹過了，我們就只介紹inset。

inset結(jié)構(gòu)體

typedef struct intset {
    uint32_t encoding;
    // length就是數(shù)組的實(shí)際長度
    uint32_t length;
    // contents 數(shù)組是實(shí)際保存元素的地方，數(shù)組中的元素有以下兩個(gè)特性：
    // 1.沒有重復(fù)元素
    // 2.元素在數(shù)組中從小到大排列
    int8_t contents[];
} intset;

// encoding 的值可以是以下三個(gè)常量的其中一個(gè)
#define INTSET_ENC_INT16 (sizeof(int16_t))
#define INTSET_ENC_INT32 (sizeof(int32_t))
#define INTSET_ENC_INT64 (sizeof(int64_t))

inset的查詢

intset是一個(gè)有序集合，查找元素的復(fù)雜度為O(logN)(采用二分法)，但插入時(shí)不一定為O(logN)，因?yàn)橛锌赡苌婕暗缴?jí)操作。比如當(dāng)集合里全是int16_t型的整數(shù)，這時(shí)要插入一個(gè)int32_t，那么為了維持集合中數(shù)據(jù)類型的一致，那么所有的數(shù)據(jù)都會(huì)被轉(zhuǎn)換成int32_t類型，涉及到內(nèi)存的重新分配，這時(shí)插入的復(fù)雜度就為O(N)了。是intset不支持降級(jí)操作。

**inset是有序不要和我們zset搞混，zset是設(shè)置一個(gè)score來進(jìn)行排序，而inset這里只是單純的對(duì)整數(shù)進(jìn)行升序而已。

7.Zset數(shù)據(jù)結(jié)構(gòu)

Zset有序集合和set集合有著必然的聯(lián)系，他保留了集合不能有重復(fù)成員的特性，但不同的是，有序集合中的元素是可以排序的，但是它和列表的使用索引下標(biāo)作為排序依據(jù)不同的是，它給每個(gè)元素設(shè)置一個(gè)分?jǐn)?shù)，作為排序的依據(jù)。

zet的底層編碼有兩種數(shù)據(jù)結(jié)構(gòu)，一個(gè)ziplist，一個(gè)是skiplist。

Zset也使用了ziplist做了排序，所以下面講一下ziplist如何做排序。

ziplist做排序

每個(gè)集合元素使用兩個(gè)緊挨在一起的壓縮列表節(jié)點(diǎn)來保存，第一個(gè)節(jié)點(diǎn)保存元素的成員(member)，而第二個(gè)元素則保存元素的分值(score)。

存儲(chǔ)結(jié)構(gòu)圖如下一目了然：

skiplist跳表

結(jié)構(gòu)體如下，skiplist是與dict結(jié)合來使用的，這個(gè)結(jié)構(gòu)比較復(fù)雜。

/*
 * 跳躍表
 */
typedef struct zskiplist {
    // 頭節(jié)點(diǎn)，尾節(jié)點(diǎn)
    struct zskiplistNode *header, *tail;
    // 節(jié)點(diǎn)數(shù)量
    unsigned long length;
    // 目前表內(nèi)節(jié)點(diǎn)的最大層數(shù)
    int level;
} zskiplist;

/*
 * 跳躍表節(jié)點(diǎn)
 */
typedef struct zskiplistNode {
    // member 對(duì)象
    robj *obj;
    // 分值
    double score;
    // 后退指針
    struct zskiplistNode *backward;
    // 層
    struct zskiplistLevel {
        // 前進(jìn)指針
        struct zskiplistNode *forward;
        // 這個(gè)層跨越的節(jié)點(diǎn)數(shù)量
        unsigned int span;
    } level[];
} zskiplistNode;

跳表是什么?

我們先看下鏈表：

如果想查找到node5需要從node1查到node5，查詢耗時(shí)。

但如果在node上加上索引：

這樣通過索引就能直接從node1查找到node5。

redis跳躍表

讓我們?cè)倏聪聄edis的跳表結(jié)構(gòu)(圖太復(fù)雜，直接從網(wǎng)上找了張圖說明)：

header:指向跳躍表的表頭節(jié)點(diǎn)，通過這個(gè)指針程序定位表頭節(jié)點(diǎn)的時(shí)間復(fù)雜度就為O(1);
tail:指向跳躍表的表尾節(jié)點(diǎn),通過這個(gè)指針程序定位表尾節(jié)點(diǎn)的時(shí)間復(fù)雜度就為O(1);
level:記錄目前跳躍表內(nèi),層數(shù)最大的那個(gè)節(jié)點(diǎn)的層數(shù)(表頭節(jié)點(diǎn)的層數(shù)不計(jì)算在內(nèi))，通過這個(gè)屬性可以再O(1)的時(shí)間復(fù)雜度內(nèi)獲取層高最好的節(jié)點(diǎn)的層數(shù);
length:記錄跳躍表的長度,也即是,跳躍表目前包含節(jié)點(diǎn)的數(shù)量(表頭節(jié)點(diǎn)不計(jì)算在內(nèi))，通過這個(gè)屬性，程序可以再O(1)的時(shí)間復(fù)雜度內(nèi)返回跳躍表的長度。

結(jié)構(gòu)右方的是四個(gè) zskiplistNode結(jié)構(gòu),該結(jié)構(gòu)包含以下屬性：

層(level):

節(jié)點(diǎn)中用L1、L2、L3等字樣標(biāo)記節(jié)點(diǎn)的各個(gè)層,L1代表第一層,L2代表第二層,以此類推。

每個(gè)層都帶有兩個(gè)屬性:前進(jìn)指針和跨度。前進(jìn)指針用于訪問位于表尾方向的其他節(jié)點(diǎn),而跨度則記錄了前進(jìn)指針?biāo)赶蚬?jié)點(diǎn)和當(dāng)前節(jié)點(diǎn)的距離(跨度越大、距離越遠(yuǎn))。在上圖中,連線上帶有數(shù)字的箭頭就代表前進(jìn)指針,而那個(gè)數(shù)字就是跨度。當(dāng)程序從表頭向表尾進(jìn)行遍歷時(shí)，訪問會(huì)沿著層的前進(jìn)指針進(jìn)行。

每次創(chuàng)建一個(gè)新跳躍表節(jié)點(diǎn)的時(shí)候,程序都根據(jù)冪次定律(powerlaw,越大的數(shù)出現(xiàn)的概率越小)隨機(jī)生成一個(gè)介于1和32之間的值作為level數(shù)組的大小,這個(gè)大小就是層的“高度”。

后退(backward)指針：

節(jié)點(diǎn)中用BW字樣標(biāo)記節(jié)點(diǎn)的后退指針,它指向位于當(dāng)前節(jié)點(diǎn)的前一個(gè)節(jié)點(diǎn)。后退指針在程序從表尾向表頭遍歷時(shí)使用。與前進(jìn)指針?biāo)煌氖敲總€(gè)節(jié)點(diǎn)只有一個(gè)后退指針，因此每次只能后退一個(gè)節(jié)點(diǎn)。

分值(score):

各個(gè)節(jié)點(diǎn)中的1.0、2.0和3.0是節(jié)點(diǎn)所保存的分值。在跳躍表中,節(jié)點(diǎn)按各自所保存的分值從小到大排列。

成員對(duì)象(oj):

各個(gè)節(jié)點(diǎn)中的o1、o2和o3是節(jié)點(diǎn)所保存的成員對(duì)象。在同一個(gè)跳躍表中,各個(gè)節(jié)點(diǎn)保存的成員對(duì)象必須是唯一的,但是多個(gè)節(jié)點(diǎn)保存的分值卻可以是相同的:分值相同的節(jié)點(diǎn)將按照成員對(duì)象在字典序中的大小來進(jìn)行排序,成員對(duì)象較小的節(jié)點(diǎn)會(huì)排在前面(靠近表頭的方向),而成員對(duì)象較大的節(jié)點(diǎn)則會(huì)排在后面(靠近表尾的方向)。

五、三大特殊數(shù)據(jù)類型

1.geospatial(地理位置)

geospatial將指定的地理空間位置（緯度、經(jīng)度、名稱）添加到指定的key中。
  這些數(shù)據(jù)將會(huì)存儲(chǔ)到sorted set這樣的目的是為了方便使用GEORADIUS或者GEORADIUSBYMEMBER命令對(duì)數(shù)據(jù)進(jìn)行半徑查詢等操作。
sorted set使用一種稱為Geohash的技術(shù)進(jìn)行填充。經(jīng)度和緯度的位是交錯(cuò)的，以形成一個(gè)獨(dú)特的52位整數(shù)。
  sorted set的double score可以代表一個(gè)52位的整數(shù)，而不會(huì)失去精度。（有興趣的同學(xué)可以學(xué)習(xí)一下Geohash技術(shù)，使用二分法構(gòu)建唯一的二進(jìn)制串）
有效的經(jīng)度是-180度到180度
  有效的緯度是-85.05112878度到85.05112878度

應(yīng)用場(chǎng)景

查看附近的人
微信位置共享
地圖上直線距離的展示

2.Hyperloglog(基數(shù))

什么是基數(shù)? 不重復(fù)的元素。

hyperloglog 是用來做基數(shù)統(tǒng)計(jì)的，其優(yōu)點(diǎn)是：輸入的提及無論多么大，hyperloglog使用的空間總是固定的12KB ，利用12KB，它可以計(jì)算2^64個(gè)不同元素的基數(shù)！非常節(jié)省空間！但缺點(diǎn)是估算的值，可能存在誤差

應(yīng)用場(chǎng)景

網(wǎng)頁統(tǒng)計(jì)UV (瀏覽用戶數(shù)量，同一天同一個(gè)ip多次訪問算一次訪問，目的是計(jì)數(shù)，而不是保存用戶)。

傳統(tǒng)的方式，set保存用戶的id，可以統(tǒng)計(jì)set中元素?cái)?shù)量作為標(biāo)準(zhǔn)判斷。

但如果這種方式保存大量用戶id，會(huì)占用大量內(nèi)存，我們的目的是為了計(jì)數(shù)，而不是去保存id。

3.Bitmaps(位存儲(chǔ))

Redis提供的Bitmaps這個(gè)“數(shù)據(jù)結(jié)構(gòu)”可以實(shí)現(xiàn)對(duì)位的操作。Bitmaps本身不是一種數(shù)據(jù)結(jié)構(gòu)，實(shí)際上就是字符串，但是它可以對(duì)字符串的位進(jìn)行操作。
可以把Bitmaps想象成一個(gè)以位為單位數(shù)組，數(shù)組中的每個(gè)單元只能存0或者1，數(shù)組的下標(biāo)在bitmaps中叫做偏移量。單個(gè)bitmaps的最大長度是512MB，即2^32個(gè)比特位。

應(yīng)用場(chǎng)景

兩種狀態(tài)的統(tǒng)計(jì)都可以使用bitmaps，例如：統(tǒng)計(jì)用戶活躍與非活躍數(shù)量、登錄與非登錄、上班打卡等等。

六、Redis事務(wù)

事務(wù)本質(zhì)：一組命令的集合。

1.數(shù)據(jù)庫事務(wù)與redis事務(wù)

數(shù)據(jù)庫的事務(wù)

數(shù)據(jù)庫事務(wù)通過ACID(原子性、一致性、隔離性、持久性)來保證。

數(shù)據(jù)庫中除查詢操作以外，插入(Insert)、刪除(Delete)和更新(Update)這三種操作都會(huì)對(duì)數(shù)據(jù)造成影響，因?yàn)槭聞?wù)處理能夠保證一系列操作可以完全地執(zhí)行或者完全不執(zhí)行，因此在一個(gè)事務(wù)被提交以后，該事務(wù)中的任何一條SQL語句在被執(zhí)行的時(shí)候，都會(huì)生成一條撤銷日志(Undo Log)。

Redis事務(wù)

redis事務(wù)提供了一種“將多個(gè)命令打包，然后一次性、按順序地執(zhí)行”的機(jī)制，并且事務(wù)在執(zhí)行的期間不會(huì)主動(dòng)中斷 —— 服務(wù)器在執(zhí)行完事務(wù)中的所有命令之后，才會(huì)繼續(xù)處理其他客戶端的其他命令。

Redis中一個(gè)事務(wù)從開始到執(zhí)行會(huì)經(jīng)歷開始事務(wù)(muiti)、命令入隊(duì)和執(zhí)行事務(wù)(exec)三個(gè)階段，事務(wù)中的命令在加入時(shí)都沒有被執(zhí)行，直到提交時(shí)才會(huì)開始執(zhí)行(Exec)一次性完成。

一組命令中存在兩種錯(cuò)誤不同處理方式：

代碼語法錯(cuò)誤(編譯時(shí)異常)所有命令都不執(zhí)行。
代碼邏輯錯(cuò)誤(運(yùn)行時(shí)錯(cuò)誤)，其他命令可以正常執(zhí)行 (該點(diǎn)不保證事務(wù)的原子性)。

為什么redis不支持回滾來保證原子性？

這種做法的優(yōu)點(diǎn)：

Redis 命令只會(huì)因?yàn)殄e(cuò)誤的語法而失敗(并且這些問題不能在入隊(duì)時(shí)發(fā)現(xiàn))，或是命令用在了錯(cuò)誤類型的鍵上面：這也就是說，從實(shí)用性的角度來說，失敗的命令是由編程錯(cuò)誤造成的，而這些錯(cuò)誤應(yīng)該在開發(fā)的過程中被發(fā)現(xiàn)，而不應(yīng)該出現(xiàn)在生產(chǎn)環(huán)境中。
因?yàn)椴恍枰獙?duì)回滾進(jìn)行支持，所以 Redis 的內(nèi)部可以保持簡單且快速。

**鑒于沒有任何機(jī)制能避免程序員自己造成的錯(cuò)誤，并且這類錯(cuò)誤通常不會(huì)在生產(chǎn)環(huán)境中出現(xiàn)，所以 Redis 選擇了更簡單、更快速的無回滾方式來處理事務(wù)。

事務(wù)監(jiān)控

悲觀鎖：認(rèn)為什么時(shí)候都會(huì)出現(xiàn)問題，無論做什么操作都會(huì)加鎖。

樂觀鎖：認(rèn)為什么時(shí)候都不會(huì)出現(xiàn)問題，所以不會(huì)上鎖!更新數(shù)據(jù)的時(shí)候去判斷一下，在此期間是否有人修改過這個(gè)數(shù)據(jù)。

使用cas實(shí)現(xiàn)樂觀鎖

redis使用watch key監(jiān)控指定數(shù)據(jù)，相當(dāng)于加樂觀鎖。

watch保證事務(wù)只能在所有被監(jiān)視鍵都沒有被修改的前提下執(zhí)行，如果這個(gè)前提不能滿足的話，事務(wù)就不會(huì)被執(zhí)行。

watch執(zhí)行流程：

七、Redis持久化

Redis是一種內(nèi)存型數(shù)據(jù)庫，一旦服務(wù)器進(jìn)程退出，數(shù)據(jù)庫的數(shù)據(jù)就會(huì)丟失，為了解決這個(gè)問題Redis供了兩種持久化的方案，將內(nèi)存中的數(shù)據(jù)保存到磁盤中，避免數(shù)據(jù)的丟失兩種持久化方式：快照(RDB文件)和追加式文件(AOF文件)，下面分別為大家介紹兩種方式的原理。

RDB持久化方式會(huì)在一個(gè)特定的間隔保存那個(gè)時(shí)間點(diǎn)的數(shù)據(jù)快照。
AOF持久化方式則會(huì)記錄每一個(gè)服務(wù)器收到的寫操作。在服務(wù)啟動(dòng)時(shí)，這些記錄的操作會(huì)逐條執(zhí)行從而重建出原來的數(shù)據(jù)。寫操作命令記錄的格式跟Redis協(xié)議一致，以追加的方式進(jìn)行保存。
Redis的持久化是可以禁用的，就是說你可以讓數(shù)據(jù)的生命周期只存在于服務(wù)器的運(yùn)行時(shí)間里。
兩種方式的持久化是可以同時(shí)存在的，但是當(dāng)Redis重啟時(shí)，AOF文件會(huì)被優(yōu)先用于重建數(shù)據(jù)。

1 RDB持久化

RDB持久化產(chǎn)生的文件是一個(gè)經(jīng)過壓縮的二進(jìn)制文件，這個(gè)文件可以被保存到硬盤中，可以通過這個(gè)文件還原數(shù)據(jù)庫的狀態(tài)，它可以手動(dòng)執(zhí)行，也可以在redis.conf配置文件中配置，定時(shí)執(zhí)行。

工作原理

在進(jìn)行RDB時(shí)，redis的主進(jìn)程不會(huì)做io操作，會(huì)fork一個(gè)子進(jìn)程來完成該操作：

Redis 調(diào)用forks。同時(shí)擁有父進(jìn)程和子進(jìn)程。

子進(jìn)程將數(shù)據(jù)集寫入到一個(gè)臨時(shí) RDB 文件中。

當(dāng)子進(jìn)程完成對(duì)新 RDB 文件的寫入時(shí)，Redis 用新 RDB 文件替換原來的 RDB 文件，并刪除舊的 RDB 文件。

這種工作方式使得 Redis 可以從寫時(shí)復(fù)制(copy-on-write)機(jī)制中獲益(因?yàn)槭鞘褂米舆M(jìn)程進(jìn)行寫操作，而父進(jìn)程依然可以接收來自客戶端的請(qǐng)求)。

觸發(fā)機(jī)制

在Redis中RDB持久化的觸發(fā)分為兩種：自己手動(dòng)觸發(fā)與自動(dòng)觸發(fā)。

主動(dòng)觸發(fā)

save命令是同步的命令，會(huì)占用主進(jìn)程，會(huì)造成阻塞，阻塞所有客戶端的請(qǐng)求。
bgsave。

bgsave是異步進(jìn)行，進(jìn)行持久化的時(shí)候，redis還可以將繼續(xù)響應(yīng)客戶端請(qǐng)求。

bgsave和save對(duì)比

命令	save	bgsave
IO類型	同步	異步
阻塞	是	是（阻塞發(fā)生在fock()，通常非?？欤?/p>
復(fù)雜度	O(n)	O(n)
優(yōu)點(diǎn)	不會(huì)消耗額外的內(nèi)存	不阻塞客戶端命令
缺點(diǎn)	阻塞客戶端命令	需要fock子進(jìn)程，消耗內(nèi)存

自動(dòng)觸發(fā)

（1）save自動(dòng)觸發(fā)配置，見下面配置，滿足m秒內(nèi)修改n次key，觸發(fā)rdb。

# 時(shí)間策略   save m n m秒內(nèi)修改n次key，觸發(fā)rdb
save 900 1
save 300 10
save 60 10000

# 文件名稱
dbfilename dump.rdb

# 文件保存路徑
dir /home/work/app/redis/data/

# 如果持久化出錯(cuò)，主進(jìn)程是否停止寫入
stop-writes-on-bgsave-error yes

# 是否壓縮
rdbcompression yes

# 導(dǎo)入時(shí)是否檢查
rdbchecksum yes

（2）從節(jié)點(diǎn)全量復(fù)制時(shí)，主節(jié)點(diǎn)發(fā)送rdb文件給從節(jié)點(diǎn)完成復(fù)制操作，主節(jié)點(diǎn)會(huì)觸發(fā)bgsave命令;

（3）執(zhí)行flushall命令，會(huì)觸發(fā)rdb

（4）退出redis，且沒有開啟aof時(shí)

優(yōu)點(diǎn)：

RDB 的內(nèi)容為二進(jìn)制的數(shù)據(jù)，占用內(nèi)存更小，更緊湊，更適合做為備份文件;
RDB 對(duì)災(zāi)難恢復(fù)非常有用，它是一個(gè)緊湊的文件，可以更快的傳輸?shù)竭h(yuǎn)程服務(wù)器進(jìn)行 Redis 服務(wù)恢復(fù);
RDB 可以更大程度的提高 Redis 的運(yùn)行速度，因?yàn)槊看纬志没瘯r(shí) Redis 主進(jìn)程都會(huì) fork() 一個(gè)子進(jìn)程，進(jìn)行數(shù)據(jù)持久化到磁盤，Redis 主進(jìn)程并不會(huì)執(zhí)行磁盤 I/O 等操作;
與 AOF 格式的文件相比，RDB 文件可以更快的重啟。

缺點(diǎn)：

因?yàn)?RDB 只能保存某個(gè)時(shí)間間隔的數(shù)據(jù)，如果中途 Redis 服務(wù)被意外終止了，則會(huì)丟失一段時(shí)間內(nèi)的 Redis 數(shù)據(jù)。
RDB 需要經(jīng)常 fork() 才能使用子進(jìn)程將其持久化在磁盤上。如果數(shù)據(jù)集很大，fork() 可能很耗時(shí)，并且如果數(shù)據(jù)集很大且 CPU 性能不佳，則可能導(dǎo)致 Redis 停止為客戶端服務(wù)幾毫秒甚至一秒鐘。

2.AOF(Append Only File)

以日志的形式來記錄每個(gè)寫的操作，將Redis執(zhí)行過的所有指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件，redis啟動(dòng)之初會(huì)讀取該文件重新構(gòu)建數(shù)據(jù)，換言之，redis重啟的話就根據(jù)日志文件的內(nèi)容將寫指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復(fù)工作。

AOF配置項(xiàng)

# 默認(rèn)不開啟aof  而是使用rdb的方式
appendonly no

# 默認(rèn)文件名
appendfilename "appendonly.aof"

# 每次修改都會(huì)sync 消耗性能
# appendfsync always
# 每秒執(zhí)行一次 sync 可能會(huì)丟失這一秒的數(shù)據(jù)
appendfsync everysec
# 不執(zhí)行 sync ,這時(shí)候操作系統(tǒng)自己同步數(shù)據(jù)，速度最快
# appendfsync no

AOF的整個(gè)流程大體來看可以分為兩步，一步是命令的實(shí)時(shí)寫入(如果是appendfsync everysec 配置，會(huì)有1s損耗)，第二步是對(duì)aof文件的重寫。

AOF 重寫機(jī)制

隨著Redis的運(yùn)行，AOF的日志會(huì)越來越長，如果實(shí)例宕機(jī)重啟，那么重放整個(gè)AOF將會(huì)變得十分耗時(shí)，而在日志記錄中，又有很多無意義的記錄，比如我現(xiàn)在將一個(gè)數(shù)據(jù) incr一千次，那么就不需要去記錄這1000次修改，只需要記錄最后的值即可。所以就需要進(jìn)行 AOF 重寫。

Redis 提供了bgrewriteaof指令用于對(duì)AOF日志進(jìn)行重寫，該指令運(yùn)行時(shí)會(huì)開辟一個(gè)子進(jìn)程對(duì)內(nèi)存進(jìn)行遍歷，然后將其轉(zhuǎn)換為一系列的 Redis 的操作指令，再序列化到一個(gè)日志文件中。完成后再替換原有的AOF文件，至此完成。

同樣的也可以在redis.config中對(duì)重寫機(jī)制的觸發(fā)進(jìn)行配置：

通過將no-appendfsync-on-rewrite設(shè)置為yes，開啟重寫機(jī)制;auto-aof-rewrite-percentage 100意為比上次從寫后文件大小增長了100%再次觸發(fā)重寫;

auto-aof-rewrite-min-size 64mb意為當(dāng)文件至少要達(dá)到64mb才會(huì)觸發(fā)制動(dòng)重寫。

觸發(fā)方式

手動(dòng)觸發(fā)：bgrewriteaof。
自動(dòng)觸發(fā) 就是根據(jù)配置規(guī)則來觸發(fā)，當(dāng)然自動(dòng)觸發(fā)的整體時(shí)間還跟Redis的定時(shí)任務(wù)頻率有關(guān)系。

優(yōu)點(diǎn)

數(shù)據(jù)安全，aof 持久化可以配置 appendfsync 屬性，有 always，每進(jìn)行一次命令操作就記錄到 aof 文件中一次。
通過 append 模式寫文件，即使中途服務(wù)器宕機(jī)，可以通過 redis-check-aof 工具解決數(shù)據(jù)一致性問題。
AOF 機(jī)制的 rewrite 模式。AOF 文件沒被 rewrite 之前(文件過大時(shí)會(huì)對(duì)命令進(jìn)行合并重寫)，可以刪除其中的某些命令(比如誤操作的 flushall))。

缺點(diǎn)

AOF 文件比 RDB 文件大，且恢復(fù)速度慢。
數(shù)據(jù)集大的時(shí)候，比 rdb 啟動(dòng)效率低。

3.rdb與aof對(duì)比

比較項(xiàng)	RDB	AOF
啟動(dòng)優(yōu)先級(jí)	低	高
體積	小	大
恢復(fù)速度	快	慢
數(shù)據(jù)安全性	丟數(shù)據(jù)	根據(jù)策略決定

八、發(fā)布與訂閱

redis發(fā)布與訂閱是一種消息通信的模式：發(fā)送者(pub)發(fā)送消息，訂閱者(sub)接收消息。

redis通過PUBLISH和SUBSCRIBE等命令實(shí)現(xiàn)了訂閱與發(fā)布模式，這個(gè)功能提供兩種信息機(jī)制，分別是訂閱/發(fā)布到頻道、訂閱/發(fā)布到模式的客戶端。

1.頻道(channel)

發(fā)布

完整流程

發(fā)布者發(fā)布消息

發(fā)布者向頻道channel:1發(fā)布消息hi。

127.0.0.1:6379> publish channel:1 hi
(integer) 1

訂閱者訂閱消息

127.0.0.1:6379> subscribe channel:1
Reading messages... (press Ctrl-C to quit)
1) "subscribe" // 消息類型
2) "channel:1" // 頻道
3) "hi" // 消息內(nèi)容

執(zhí)行subscribe后客戶端會(huì)進(jìn)入訂閱狀態(tài)，僅可以使subscribe、unsubscribe、psubscribe和punsubscribe這四個(gè)屬于"發(fā)布/訂閱"之外的命令。

訂閱頻道后的客戶端可能會(huì)收到三種消息類型：

subscribe。表示訂閱成功的反饋信息。第二個(gè)值是訂閱成功的頻道名稱，第三個(gè)是當(dāng)前客戶端訂閱的頻道數(shù)量。
message。表示接收到的消息，第二個(gè)值表示產(chǎn)生消息的頻道名稱，第三個(gè)值是消息的內(nèi)容。
unsubscribe。表示成功取消訂閱某個(gè)頻道。第二個(gè)值是對(duì)應(yīng)的頻道名稱，第三個(gè)值是當(dāng)前客戶端訂閱的頻道數(shù)量，當(dāng)此值為0時(shí)客戶端會(huì)退出訂閱狀態(tài)，之后就可以執(zhí)行其他非"發(fā)布/訂閱"模式的命令了。

數(shù)據(jù)結(jié)構(gòu)

基于頻道的發(fā)布訂閱模式是通過字典數(shù)據(jù)類型實(shí)現(xiàn)的。

struct redisServer {
    // ...
    dict *pubsub_channels;
    // ...
};

其中，字典的鍵為正在被訂閱的頻道，而字典的值則是一個(gè)鏈表，鏈表中保存了所有訂閱這個(gè)頻道的客戶端。

當(dāng)使用subscribe訂閱時(shí)，在字典中找到頻道key(如沒有則創(chuàng)建)，并將訂閱的client關(guān)聯(lián)在鏈表后面。

當(dāng)client 10執(zhí)行subscribe channel1 channel2 channel3時(shí)，會(huì)將client 10分別加到 channel1 channel2 channel3關(guān)聯(lián)的鏈表尾部。

發(fā)布

發(fā)布時(shí)，根據(jù)key，找到字典匯總key的地址，然后將msg發(fā)送到關(guān)聯(lián)的鏈表每一臺(tái)機(jī)器。

退訂

遍歷關(guān)聯(lián)的鏈表，將指定的地址刪除即可。

2.模式(pattern)

pattern使用了通配符的方式來訂閱。

通配符中?表示1個(gè)占位符，*表示任意個(gè)占位符(包括0)，?*表示1個(gè)以上占位符。

所以當(dāng)使用 publish命令發(fā)送信息到某個(gè)頻道時(shí)，不僅所有訂閱該頻道的客戶端會(huì)收到信息，如果有某個(gè)/某些模式和這個(gè)頻道匹配的話，那么所有訂閱這個(gè)/這些頻道的客戶端也同樣會(huì)收到信息。

訂閱發(fā)布完整流程

發(fā)布者發(fā)布消息

127.0.0.1:6379> publish b m1
(integer) 1
127.0.0.1:6379> publish b1 m1
(integer) 1
127.0.0.1:6379> publish b11 m1
(integer) 1

訂閱者訂閱消息

127.0.0.1:6379> psubscribe b*
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "b*"
3) (integer) 3
1) "pmessage"
2) "b*"
3) "b"
4) "m1"
1) "pmessage"
2) "b*"
3) "b1"
4) "m1"
1) "pmessage"
2) "b*"
3) "b11"
4) "m1"

數(shù)據(jù)結(jié)構(gòu)

pattern屬性是一個(gè)鏈表，鏈表中保存著所有和模式相關(guān)的信息。

struct redisServer {
    // ...
    list *pubsub_patterns;
    // ...
};
// 鏈表中的每一個(gè)節(jié)點(diǎn)結(jié)構(gòu)如下，保存著客戶端與模式信息
typedef struct pubsubPattern {
    redisClient *client;
    robj *pattern;
} pubsubPattern;

數(shù)據(jù)結(jié)構(gòu)圖如下：

當(dāng)有信的訂閱時(shí)，會(huì)將訂閱的客戶端和模式信息添加到鏈表后面。

發(fā)布

當(dāng)發(fā)布者發(fā)布消息時(shí)，首先會(huì)發(fā)送到對(duì)應(yīng)的頻道上，在遍歷模式列表，根據(jù)key匹配模式，匹配成功將消息發(fā)給對(duì)應(yīng)的訂閱者。

完成的發(fā)布偽代碼如下：

def PUBLISH(channel, message):
    # 遍歷所有訂閱頻道 channel 的客戶端
    for client in server.pubsub_channels[channel]:
        # 將信息發(fā)送給它們
        send_message(client, message)
    # 取出所有模式，以及訂閱模式的客戶端
    for pattern, client in server.pubsub_patterns:
        # 如果 channel 和模式匹配
        if match(channel, pattern):
            # 那么也將信息發(fā)給訂閱這個(gè)模式的客戶端
            send_message(client, message)

退訂

使用punsubscribe，可以將訂閱者退訂，將改客戶端移除出鏈表。

九、主從復(fù)制

什么是主從復(fù)制

主從復(fù)制，是指將一臺(tái)Redis服務(wù)器的數(shù)據(jù)，復(fù)制到其他的Redis服務(wù)器。
前者稱為主節(jié)點(diǎn)(master)，后者稱為從節(jié)點(diǎn)(slave)；數(shù)據(jù)的復(fù)制是單向的，只能由主節(jié)點(diǎn)到從節(jié)點(diǎn)
默認(rèn)情況下，每臺(tái)redis服務(wù)器都是主節(jié)點(diǎn)；且一個(gè)主節(jié)點(diǎn)可以有多個(gè)從節(jié)點(diǎn)（或者沒有），但一個(gè)從節(jié)點(diǎn)只有一個(gè)主

主從復(fù)制的作用主要包括：

數(shù)據(jù)冗余：主從復(fù)制實(shí)現(xiàn)了數(shù)據(jù)的熱備份，是持久化之外的一種數(shù)據(jù)冗余方式。
故障恢復(fù)：當(dāng)主節(jié)點(diǎn)出現(xiàn)問題時(shí)，可以由從節(jié)點(diǎn)提供服務(wù)，實(shí)現(xiàn)快速的故障恢復(fù);實(shí)際上是一種服務(wù)的冗余。
負(fù)載均衡：在主從復(fù)制的基礎(chǔ)上，配合讀寫分離，可以由主節(jié)點(diǎn)提供寫服務(wù)，由從節(jié)點(diǎn)提供讀服務(wù)(即寫Redis數(shù)據(jù)時(shí)應(yīng)用連接主節(jié)點(diǎn)，讀Redis數(shù)據(jù)時(shí)應(yīng)用連接從節(jié)點(diǎn))，分擔(dān)服務(wù)器負(fù)載;尤其是在寫少讀多的場(chǎng)景下，通過多個(gè)從節(jié)點(diǎn)分擔(dān)讀負(fù)載，可以大大提高Redis服務(wù)器的并發(fā)量。
高可用基石：除了上述作用以外，主從復(fù)制還是哨兵和集群能夠?qū)嵤┑幕A(chǔ)，因此說主從復(fù)制是Redis高可用的基礎(chǔ)。

主從庫采用的是讀寫分離的方式：

1.原理

分為全量復(fù)制與增量復(fù)制。

全量復(fù)制：發(fā)生在第一次復(fù)制時(shí)。

增量復(fù)制：只會(huì)把主從庫網(wǎng)絡(luò)斷連期間主庫收到的命令，同步給從庫。

2.全量復(fù)制的三個(gè)階段

第一階段是主從庫間建立連接、協(xié)商同步的過程。

主要是為全量復(fù)制做準(zhǔn)備。從庫和主庫建立起連接，并告訴主庫即將進(jìn)行同步，主庫確認(rèn)回復(fù)后，主從庫間就可以開始同步了。

具體來說，從庫給主庫發(fā)送 psync 命令，表示要進(jìn)行數(shù)據(jù)同步，主庫根據(jù)這個(gè)命令的參數(shù)來啟動(dòng)復(fù)制。psync 命令包含了主庫的 runID 和復(fù)制進(jìn)度 offset 兩個(gè)參數(shù)。runID，是每個(gè) Redis 實(shí)例啟動(dòng)時(shí)都會(huì)自動(dòng)生成的一個(gè)隨機(jī) ID，用來唯一標(biāo)記這個(gè)實(shí)例。當(dāng)從庫和主庫第一次復(fù)制時(shí)，因?yàn)椴恢乐鲙斓?runID，所以將 runID 設(shè)為“?”。offset，此時(shí)設(shè)為 -1，表示第一次復(fù)制。主庫收到 psync 命令后，會(huì)用 FULLRESYNC 響應(yīng)命令帶上兩個(gè)參數(shù)：主庫 runID 和主庫目前的復(fù)制進(jìn)度 offset，返回給從庫。從庫收到響應(yīng)后，會(huì)記錄下這兩個(gè)參數(shù)。這里有個(gè)地方需要注意，F(xiàn)ULLRESYNC 響應(yīng)表示第一次復(fù)制采用的全量復(fù)制，也就是說，主庫會(huì)把當(dāng)前所有的數(shù)據(jù)都復(fù)制給從庫。

第二階段，主庫將所有數(shù)據(jù)同步給從庫。

從庫收到數(shù)據(jù)后，在本地完成數(shù)據(jù)加載。這個(gè)過程依賴于內(nèi)存快照生成的 RDB 文件。

具體來說，主庫執(zhí)行 bgsave 命令，生成 RDB 文件，接著將文件發(fā)給從庫。從庫接收到 RDB 文件后，會(huì)先清空當(dāng)前數(shù)據(jù)庫，然后加載 RDB 文件。這是因?yàn)閺膸煸谕ㄟ^ replicaof 命令開始和主庫同步前，可能保存了其他數(shù)據(jù)。為了避免之前數(shù)據(jù)的影響，從庫需要先把當(dāng)前數(shù)據(jù)庫清空。在主庫將數(shù)據(jù)同步給從庫的過程中，主庫不會(huì)被阻塞，仍然可以正常接收請(qǐng)求。否則，Redis 的服務(wù)就被中斷了。但是，這些請(qǐng)求中的寫操作并沒有記錄到剛剛生成的 RDB 文件中。為了保證主從庫的數(shù)據(jù)一致性，主庫會(huì)在內(nèi)存中用專門的 replication buffer，記錄 RDB 文件生成后收到的所有寫操作。

第三個(gè)階段，主庫會(huì)把第二階段執(zhí)行過程中新收到的寫命令，再發(fā)送給從庫。

具體的操作是，當(dāng)主庫完成 RDB 文件發(fā)送后，就會(huì)把此時(shí) replication buffer 中的修改操作發(fā)給從庫，從庫再重新執(zhí)行這些操作。這樣一來，主從庫就實(shí)現(xiàn)同步了。

十、哨兵機(jī)制

哨兵的核心功能是主節(jié)點(diǎn)的自動(dòng)故障轉(zhuǎn)移。

下圖是一個(gè)典型的哨兵集群監(jiān)控的邏輯圖：

Redis Sentinel包含了若個(gè)Sentinel節(jié)點(diǎn)，這樣做也帶來了兩個(gè)好處：

對(duì)于節(jié)點(diǎn)的故障判斷是由多個(gè)Sentinel節(jié)點(diǎn)共同完成，這樣可以有效地防止誤判。
即使個(gè)別Sentinel節(jié)點(diǎn)不可用，整個(gè)Sentinel集群依然是可用的。

哨兵實(shí)現(xiàn)了一下功能：

監(jiān)控：每個(gè)Sentinel節(jié)點(diǎn)會(huì)對(duì)數(shù)據(jù)節(jié)點(diǎn)(Redis master/slave 節(jié)點(diǎn))和其余Sentinel節(jié)點(diǎn)進(jìn)行監(jiān)控。
通知：Sentinel節(jié)點(diǎn)會(huì)將故障轉(zhuǎn)移的結(jié)果通知給應(yīng)用方
故障轉(zhuǎn)移：實(shí)現(xiàn)slave晉升為master，并維護(hù)后續(xù)正確的主從關(guān)系。
配置中心：在Redis Sentinel模式中，客戶端在初始化的時(shí)候連接的是Sentinel節(jié)點(diǎn)集合，從中獲取主節(jié)點(diǎn)信息。

其中，監(jiān)控和自動(dòng)故障轉(zhuǎn)移功能，使得哨兵可以及時(shí)發(fā)現(xiàn)主節(jié)點(diǎn)故障并完成轉(zhuǎn)移;而配置中心和通知功能，則需要在與客戶端的交互中才能體現(xiàn)。

1.原理

監(jiān)控

Sentinel節(jié)點(diǎn)需要監(jiān)控master、slave以及其它Sentinel節(jié)點(diǎn)的狀態(tài)。這一過程是通過Redis的pub/sub系統(tǒng)實(shí)現(xiàn)的。Redis Sentinel一共有三個(gè)定時(shí)監(jiān)控任務(wù)，完成對(duì)各個(gè)節(jié)點(diǎn)發(fā)現(xiàn)和監(jiān)控：

監(jiān)控主從拓?fù)湫畔ⅲ好扛?0秒，每個(gè)Sentinel節(jié)點(diǎn)，會(huì)向master和slave發(fā)送INFO命令獲取最新的拓?fù)浣Y(jié)構(gòu)。
Sentinel節(jié)點(diǎn)信息交換：每隔2秒，每個(gè)Sentinel節(jié)點(diǎn)，會(huì)向Redis數(shù)據(jù)節(jié)點(diǎn)的__sentinel__:hello頻道上，發(fā)送自身的信息，以及對(duì)主節(jié)點(diǎn)的判斷信息。這樣，Sentinel節(jié)點(diǎn)之間就可以交換信息。
節(jié)點(diǎn)狀態(tài)監(jiān)控：每隔1秒，每個(gè)Sentinel節(jié)點(diǎn)，會(huì)向master、slave、其余Sentinel節(jié)點(diǎn)發(fā)送PING命令做心跳檢測(cè)，來確認(rèn)這些節(jié)點(diǎn)當(dāng)前是否可達(dá)。

主觀/客觀下線

主觀下線

每個(gè)Sentinel節(jié)點(diǎn)，每隔1秒會(huì)對(duì)數(shù)據(jù)節(jié)點(diǎn)發(fā)送ping命令做心跳檢測(cè)，當(dāng)這些節(jié)點(diǎn)超過down-after-milliseconds沒有進(jìn)行有效回復(fù)時(shí)，Sentinel節(jié)點(diǎn)會(huì)對(duì)該節(jié)點(diǎn)做失敗判定，這個(gè)行為叫做主觀下線。

客觀下線

客觀下線，是指當(dāng)大多數(shù)Sentinel節(jié)點(diǎn)，都認(rèn)為master節(jié)點(diǎn)宕機(jī)了，那么這個(gè)判定就是客觀的，叫做客觀下線。

那么這個(gè)大多數(shù)是指多少呢?這其實(shí)就是分布式協(xié)調(diào)中的quorum判定了，大多數(shù)就是過半數(shù)，比如哨兵數(shù)量是5，那么大多數(shù)就是5/2+1=3個(gè)，哨兵數(shù)量是10大多數(shù)就是10/2+1=6個(gè)。

注：Sentinel節(jié)點(diǎn)的數(shù)量至少為3個(gè)，否則不滿足quorum判定條件。

哨兵選舉

如果發(fā)生了客觀下線，那么哨兵節(jié)點(diǎn)會(huì)選舉出一個(gè)Leader來進(jìn)行實(shí)際的故障轉(zhuǎn)移工作。Redis使用了Raft算法來實(shí)現(xiàn)哨兵領(lǐng)導(dǎo)者選舉，大致思路如下：

每個(gè)Sentinel節(jié)點(diǎn)都有資格成為領(lǐng)導(dǎo)者，當(dāng)它主觀認(rèn)為某個(gè)數(shù)據(jù)節(jié)點(diǎn)宕機(jī)后，會(huì)向其他Sentinel節(jié)點(diǎn)發(fā)送sentinel is-master-down-by-addr命令，要求自己成為領(lǐng)導(dǎo)者;
收到命令的Sentinel節(jié)點(diǎn)，如果沒有同意過其他Sentinel節(jié)點(diǎn)的sentinelis-master-down-by-addr命令，將同意該請(qǐng)求，否則拒絕(每個(gè)Sentinel節(jié)點(diǎn)只有1票);
文章名稱：一文搞懂Redis
新聞來源：http://www.fisionsoft.com.cn/article/ccddies.html

新聞中心

一、什么是NoSQL?

二、Redis是什么?

三、Redis五大基本類型

1.String(字符串)

應(yīng)用場(chǎng)景

2.List(列表)

應(yīng)用場(chǎng)景

3.Set(集合)

4.sorted set(有序集合)

應(yīng)用場(chǎng)景

5.hash(哈希)

應(yīng)用場(chǎng)景

四、五大基本類型底層數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)

1.redisObject

2.String數(shù)據(jù)結(jié)構(gòu)

SDS

3.List存儲(chǔ)結(jié)構(gòu)

ziplist

快速列表(quickList)

4.Hash類型

5.漸進(jìn)式rehash

6.set數(shù)據(jù)結(jié)構(gòu)

inset結(jié)構(gòu)體

7.Zset數(shù)據(jù)結(jié)構(gòu)

redis跳躍表

五、三大特殊數(shù)據(jù)類型

1.geospatial(地理位置)

應(yīng)用場(chǎng)景

2.Hyperloglog(基數(shù))

應(yīng)用場(chǎng)景

3.Bitmaps(位存儲(chǔ))

應(yīng)用場(chǎng)景

六、Redis事務(wù)

1.數(shù)據(jù)庫事務(wù)與redis事務(wù)

數(shù)據(jù)庫的事務(wù)

Redis事務(wù)

七、Redis持久化

1 RDB持久化

工作原理

觸發(fā)機(jī)制

2.AOF(Append Only File)

AOF配置項(xiàng)

AOF 重寫機(jī)制

觸發(fā)方式

3.rdb與aof對(duì)比

八、發(fā)布與訂閱

1.頻道(channel)

訂閱

發(fā)布

完整流程

數(shù)據(jù)結(jié)構(gòu)

2.模式(pattern)

訂閱發(fā)布完整流程

發(fā)布者發(fā)布消息

訂閱者訂閱消息

數(shù)據(jù)結(jié)構(gòu)

九、主從復(fù)制

1.原理

2.全量復(fù)制的三個(gè)階段

十、哨兵機(jī)制

1.原理

監(jiān)控

主觀/客觀下線

哨兵選舉

其他資訊

一、什么是NoSQL?

二、Redis是什么?

三、Redis五大基本類型

五、三大特殊數(shù)據(jù)類型

七、Redis持久化

九、主從復(fù)制

十、哨兵機(jī)制