一文搞懂redis
簡(jiǎn)介：NoSQL泛指非關(guān)系型數(shù)據(jù)庫(kù)，隨著web2.0互聯(lián)網(wǎng)的誕生，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)很難對(duì)付web2.0大數(shù)據(jù)時(shí)代！尤其是超大規(guī)模的高并發(fā)的社區(qū)，暴露出來(lái)很多難以克服的問(wèn)題，NoSQL在當(dāng)今大數(shù)據(jù)環(huán)境下發(fā)展的十分迅速，Redis是發(fā)展最快的。
作者 | 一洺
來(lái)源 | 阿里技術(shù)公眾號(hào)
一 什么是NoSQL？
Nosql = not only sql（不僅僅是SQL）
關(guān)系型數(shù)據(jù)庫(kù)：列+行，同一個(gè)表下數(shù)據(jù)的結(jié)構(gòu)是一樣的。
非關(guān)系型數(shù)據(jù)庫(kù)：數(shù)據(jù)存儲(chǔ)沒(méi)有固定的格式，并且可以進(jìn)行橫向擴(kuò)展。
NoSQL泛指非關(guān)系型數(shù)據(jù)庫(kù)，隨著web2.0互聯(lián)網(wǎng)的誕生，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)很難對(duì)付web2.0大數(shù)據(jù)時(shí)代！尤其是超大規(guī)模的高并發(fā)的社區(qū)，暴露出來(lái)很多難以克服的問(wèn)題，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ù)操作語(yǔ)言）、DDL（數(shù)據(jù)定義語(yǔ)言）等- 嚴(yán)格的一致性（ACID): 原子性、一致性、隔離性、持久性- 基礎(chǔ)的事務(wù) NoSQL- 不僅僅是數(shù)據(jù)- 沒(méi)有固定查詢語(yǔ)言- 鍵值對(duì)存儲(chǔ)（redis）、列存儲(chǔ)（HBase）、文檔存儲(chǔ)（MongoDB）、圖形數(shù)據(jù)庫(kù)（不是存圖形，放的是關(guān)系）（Neo4j）- 最終一致性（BASE）：基本可用、軟狀態(tài)/柔性事務(wù)、最終一致性二 redis是什么？
Redis = Remote Dictionary Server，即遠(yuǎn)程字典服務(wù)。
是一個(gè)開(kāi)源的使用ANSI C語(yǔ)言編寫、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫(kù)，并提供多種語(yǔ)言的API。
與memcached一樣，為了保證效率，數(shù)據(jù)都是緩存在內(nèi)存中。區(qū)別的是redis會(huì)周期性的把更新的數(shù)據(jù)寫入磁盤或者把修改操作寫入追加的記錄文件，并且在此基礎(chǔ)上實(shí)現(xiàn)了master-slave(主從)同步。
三 redis五大基本類型
Redis是一個(gè)開(kāi)源，內(nèi)存存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)服務(wù)器，可用作數(shù)據(jù)庫(kù)，高速緩存和消息隊(duì)列代理。它支持字符串、哈希表、列表、集合、有序集合，位圖，hyperloglogs等數(shù)據(jù)類型。內(nèi)置復(fù)制、Lua腳本、LRU收回、事務(wù)以及不同級(jí)別磁盤持久化功能，同時(shí)通過(guò)Redis Sentinel提供高可用，通過(guò)Redis Cluster提供自動(dòng)分區(qū)。
由于redis類型大家很熟悉，且網(wǎng)上命令使用介紹很多，下面重點(diǎn)介紹五大基本類型的底層數(shù)據(jù)結(jié)構(gòu)與應(yīng)用場(chǎng)景，以便當(dāng)開(kāi)發(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類型可以是簡(jiǎn)單字符串、復(fù)雜的xml/json的字符串、二進(jìn)制圖像或者音頻的字符串、以及可以是數(shù)字的字符串應(yīng)用場(chǎng)景
1、緩存功能：String字符串是最常用的數(shù)據(jù)類型，不僅僅是redis，各個(gè)語(yǔ)言都是最基本類型，因此，利用redis作為緩存，配合其它數(shù)據(jù)庫(kù)作為存儲(chǔ)層，利用redis支持高并發(fā)的特點(diǎn)，可以大大加快系統(tǒng)的讀寫速度、以及降低后端數(shù)據(jù)庫(kù)的壓力。
2、計(jì)數(shù)器：許多系統(tǒng)都會(huì)使用redis作為系統(tǒng)的實(shí)時(shí)計(jì)數(shù)器，可以快速實(shí)現(xiàn)計(jì)數(shù)和查詢的功能。而且最終的數(shù)據(jù)結(jié)果可以按照特定的時(shí)間落地到數(shù)據(jù)庫(kù)或者其它存儲(chǔ)介質(zhì)當(dāng)中進(jìn)行永久保存。
3、統(tǒng)計(jì)多單位的數(shù)量：eg，uid：gongming count：0 根據(jù)不同的uid更新count數(shù)量。
4、共享用戶session：用戶重新刷新一次界面，可能需要訪問(wèn)一下數(shù)據(jù)進(jìn)行重新登錄，或者訪問(wèn)頁(yè)面緩存cookie，這兩種方式做有一定弊端，1）每次都重新登錄效率低下 2）cookie保存在客戶端，有安全隱患。這時(shí)可以利用redis將用戶的session集中管理，在這種模式只需要保證redis的高可用，每次用戶session的更新和獲取都可以快速完成。大大提高效率。
2 List（列表）
1.list類型是用來(lái)存儲(chǔ)多個(gè)有序的字符串的，列表當(dāng)中的每一個(gè)字符看做一個(gè)元素 2.一個(gè)列表當(dāng)中可以存儲(chǔ)有一個(gè)或者多個(gè)元素，redis的list支持存儲(chǔ)2^32次方-1個(gè)元素。 3.redis可以從列表的兩端進(jìn)行插入（pubsh）和彈出（pop）元素，支持讀取指定范圍的元素集，或者讀取指定下標(biāo)的元素等操作。redis列表是一種比較靈活的鏈表數(shù)據(jù)結(jié)構(gòu)，它可以充當(dāng)隊(duì)列或者棧的角色。 4.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)右出的命令組成來(lái)完成隊(duì)列的設(shè)計(jì)。比如：數(shù)據(jù)的生產(chǎn)者可以通過(guò)Lpush命令從左邊插入數(shù)據(jù)，多個(gè)數(shù)據(jù)消費(fèi)者，可以使用BRpop命令阻塞的“搶”列表尾部的數(shù)據(jù)。
2、文章列表或者數(shù)據(jù)分頁(yè)展示的應(yīng)用。比如，我們常用的博客網(wǎng)站的文章列表，當(dāng)用戶量越來(lái)越多時(shí)，而且每一個(gè)用戶都有自己的文章列表，而且當(dāng)文章多時(shí)，都需要分頁(yè)展示，這時(shí)可以考慮使用redis的列表，列表不但有序同時(shí)還支持按照范圍內(nèi)獲取元素，可以完美解決分頁(yè)查詢功能。大大提高查詢效率。
3 Set（集合）
1.redis集合（set）類型和list列表類型類似，都可以用來(lái)存儲(chǔ)多個(gè)字符串元素的集合。 2.但是和list不同的是set集合當(dāng)中不允許重復(fù)的元素。而且set集合當(dāng)中元素是沒(méi)有順序的，不存在元素下標(biāo)。 3.redis的set類型是使用哈希表構(gòu)造的，因此復(fù)雜度是O(1)，它支持集合內(nèi)的增刪改查，并且支持多個(gè)集合間的交集、并集、差集操作。可以利用這些集合操作，解決程序開(kāi)發(fā)過(guò)程當(dāng)中很多數(shù)據(jù)集合間的問(wèn)題。應(yīng)用場(chǎng)景
1、標(biāo)簽：比如我們博客網(wǎng)站常常使用到的興趣標(biāo)簽，把一個(gè)個(gè)有著相同愛(ài)好，關(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èn)網(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來(lái)做帶權(quán)重的隊(duì)列，比如普通消息的score為1，重要消息的score為2，然后工作線程可以選擇按score的倒序來(lái)獲取工作任務(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ù)庫(kù)，因此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的特性，用來(lái)存儲(chǔ)關(guān)系型數(shù)據(jù)庫(kù)中表記錄，是redis中哈希類型最常用的場(chǎng)景。一條記錄作為一個(gè)key-value，把每列屬性值對(duì)應(yīng)成field-value存儲(chǔ)在哈希表當(dāng)中，然后通過(guò)key值來(lái)區(qū)分表當(dāng)中的主鍵。
2、經(jīng)常被用來(lái)存儲(chǔ)用戶相關(guān)信息。優(yōu)化用戶信息的獲取，不需要重復(fù)從數(shù)據(jù)庫(kù)當(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沖突通過(guò)掛鏈表去實(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 {// 指向具體redisObjectvoid *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 {// 類型 4bitsunsigned type:4;// 編碼方式 4bitsunsigned encoding:4;// LRU 時(shí)間（相對(duì)于 server.lruclock） 24bitsunsigned lru:22;// 引用計(jì)數(shù) Redis里面的數(shù)據(jù)可以通過(guò)引用計(jì)數(shù)進(jìn)行共享 32bitsint refcount;// 指向?qū)ο蟮闹?64-bitvoid *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 （編碼的簡(jiǎn)單動(dòng)態(tài)字符串）REDIS_ENCODING_RAW （簡(jiǎn)單動(dòng)態(tài)字符串）REDIS_ENCODING_HT （字典）REDIS_ENCODING_LINKEDLIST （雙端鏈表）REDIS_ENCODING_ZIPLIST （壓縮列表）REDIS_ENCODING_INTSET （整數(shù)集合）REDIS_ENCODING_SKIPLIST （跳躍表和字典）好了，通過(guò)redisObject就可以具體指向redis數(shù)據(jù)類型了，總結(jié)一下每種數(shù)據(jù)類型都使用了哪些數(shù)據(jù)結(jié)構(gòu)，如下圖所示
前期準(zhǔn)備知識(shí)已準(zhǔn)備完畢，下面分每種基本類型來(lái)講。
2 String數(shù)據(jù)結(jié)構(gòu)
String類型的轉(zhuǎn)換順序
- 當(dāng)保存的值為整數(shù)且值的大小不超過(guò)long的范圍，使用整數(shù)存儲(chǔ)
- 當(dāng)字符串長(zhǎng)度不超過(guò)44字節(jié)時(shí)，使用EMBSTR 編碼
它只分配一次內(nèi)存空間，redisObject和sds是連續(xù)的內(nèi)存，查詢效率會(huì)快很多，也正是因?yàn)閞edisObject和sds是連續(xù)在一起，伴隨了一些缺點(diǎn)：當(dāng)字符串增加的時(shí)候，它長(zhǎng)度會(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ì)不同長(zhǎng)度整形做了相應(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語(yǔ)言實(shí)現(xiàn)，可能會(huì)有疑問(wèn)為什么不用c語(yǔ)言的字符串呢，而是用sds結(jié)構(gòu)體。
1) 低復(fù)雜度獲取字符串長(zhǎng)度：由于len存在，可以直接查出字符串長(zhǎng)度，復(fù)雜度O(1)；如果用c語(yǔ)言字符串，查詢字符串長(zhǎng)度需要遍歷整個(gè)字符串，復(fù)雜度為O(n)；
2) 避免緩沖區(qū)溢出：進(jìn)行兩個(gè)字符串拼接c語(yǔ)言可使用strcat函數(shù)，但如果沒(méi)有足夠的內(nèi)存空間。就會(huì)造成緩沖區(qū)溢出；而用sds在進(jìn)行合并時(shí)會(huì)先用len檢查內(nèi)存空間是否滿足需求，如果不滿足，進(jìn)行空間擴(kuò)展，不會(huì)造成緩沖區(qū)溢出；
3）減少修改字符串的內(nèi)存重新分配次數(shù)：c語(yǔ)言字符串不記錄字符串長(zhǎng)度，如果要修改字符串要重新分配內(nèi)存，如果不進(jìn)行重新分配會(huì)造成內(nèi)存緩沖區(qū)泄露；
redis sds實(shí)現(xiàn)了空間預(yù)分配和惰性空間釋放兩種策略
空間預(yù)分配：
1）如果sds修改后，sds長(zhǎng)度（len的值）將于1mb，那么會(huì)分配與len相同大小的未使用空間，此時(shí)len與free值相同。例如，修改之后字符串長(zhǎng)度為100字節(jié)，那么會(huì)給分配100字節(jié)的未使用空間。最終sds空間實(shí)際為 100 + 100 + 1(保存空字符'\0')；
2）如果大于等于1mb，每次給分配1mb未使用空間
惰性空間釋放：對(duì)字符串進(jìn)行縮短操作時(shí)，程序不立即使用內(nèi)存重新分配來(lái)回收縮短后多余的字節(jié)，而是使用 free 屬性將這些字節(jié)的數(shù)量記錄下來(lái)，等待后續(xù)使用（sds也提供api，我們可以手動(dòng)觸發(fā)字符串縮短）；
4）二進(jìn)制安全：因?yàn)镃字符串以空字符作為字符串結(jié)束的標(biāo)識(shí)，而對(duì)于一些二進(jìn)制文件（如圖片等），內(nèi)容可能包括空字符串，因此C字符串無(wú)法正確存取；而所有 SDS 的API 都是以處理二進(jìn)制的方式來(lái)處理 buf 里面的元素，并且 SDS 不是以空字符串來(lái)判斷是否結(jié)束，而是以 len 屬性表示的長(zhǎng)度來(lái)判斷字符串是否結(jié)束；
5）遵從每個(gè)字符串都是以空字符串結(jié)尾的慣例，這樣可以重用 C 語(yǔ)言庫(kù)<string.h> 中的一部分函數(shù)。
學(xué)習(xí)完sds，我們回到上面講到的，為什么小于44字節(jié)用embstr編碼呢？
再看一下rejectObject和sds定義的結(jié)構(gòu)（短字符串的embstr用最小的sdshdr8）
typedef struct redisObject {// 類型 4bitsunsigned type:4;// 編碼方式 4bitsunsigned encoding:4;// LRU 時(shí)間（相對(duì)于 server.lruclock） 24bitsunsigned lru:22;// 引用計(jì)數(shù) Redis里面的數(shù)據(jù)可以通過(guò)引用計(jì)數(shù)進(jìn)行共享 32bitsint refcount;// 指向?qū)ο蟮闹?64-bitvoid *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)
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è)元素的長(zhǎng)度小于 64 字節(jié)；
- 列表中數(shù)據(jù)個(gè)數(shù)少于512個(gè)
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ù)量過(guò)大時(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：要說(shuō)列表包含的各個(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來(lái)緊湊存儲(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ù)指針，如果沒(méi)有被壓縮，就指向ziplist結(jié)構(gòu)，反之指向quicklistLZF結(jié)構(gòu)unsigned char *zl;// 表示指向ziplist結(jié)構(gòu)的總長(zhǎng)度(內(nèi)存占用長(zhǎng)度)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--ziplistunsigned 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的長(zhǎng)度
quicklist內(nèi)部默認(rèn)單個(gè)ziplist長(zhǎng)度為8k字節(jié)，超出了這個(gè)字節(jié)數(shù)，就會(huì)新起一個(gè)ziplist。關(guān)于長(zhǎng)度可以使用list-max-ziplist-size決定。
壓縮深度
我們上面說(shuō)到了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，下面來(lái)介紹下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)該熟悉，在上面有講，使用來(lái)真正存儲(chǔ)key->value的地方 typedef struct dictEntry {// 鍵void *key;// 值union {// 指向具體redisObjectvoid *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是單線程的，無(wú)法承受這樣的耗時(shí)過(guò)程，所以采用了漸進(jìn)式rehash小步搬遷，雖然慢一點(diǎn)，但是可以搬遷完畢。
擴(kuò)容條件
我們的擴(kuò)容一般會(huì)在Hash表中的元素個(gè)數(shù)等于第一維數(shù)組的長(zhǎng)度的時(shí)候，就會(huì)開(kāi)始擴(kuò)容。擴(kuò)容的大小是原數(shù)組的兩倍。不過(guò)在redis在做bgsave（RDB持久化操作的過(guò)程），為了減少內(nèi)存頁(yè)的過(guò)多分離（Copy On Write），redis不會(huì)去擴(kuò)容。但是如果hash表的元素個(gè)數(shù)已經(jīng)到達(dá)了第一維數(shù)組長(zhǎng)度的5倍的時(shí)候，就會(huì)強(qiáng)制擴(kuò)容，不管你是否在持久化。
不擴(kuò)容主要是為了盡可能減少內(nèi)存頁(yè)過(guò)多分離，系統(tǒng)需要更多的開(kāi)銷去回收內(nèi)存。
縮容條件
當(dāng)我們的hash表元素逐漸刪除的越來(lái)越少的時(shí)候。redis于是就會(huì)對(duì)hash表進(jìn)行縮容來(lái)減少第一維數(shù)組長(zhǎng)度的空間占用。縮容的條件是元素個(gè)數(shù)低于數(shù)組長(zhǎng)度的10%，并且縮容不考慮是否在做redis持久化。
不用考慮bgsave主要是因?yàn)槲覀兊目s容的內(nèi)存都是已經(jīng)使用過(guò)的，縮容的時(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 開(kāi)始；
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 帶來(lái)的龐大計(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è)空白哈希表。
過(guò)程如下圖：
6 set數(shù)據(jù)結(jié)構(gòu)
Redis 的集合相當(dāng)于Java中的 HashSet，它內(nèi)部的鍵值對(duì)是無(wú)序、唯一的。它的內(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來(lái)實(shí)現(xiàn)set這種數(shù)據(jù)類型：
- 存儲(chǔ)的數(shù)據(jù)都是整數(shù)
- 存儲(chǔ)的數(shù)據(jù)元素個(gè)數(shù)小于512個(gè)
當(dāng)不能同時(shí)滿足這兩個(gè)條件的時(shí)候，Redis 就使用dict來(lái)存儲(chǔ)集合中的數(shù)據(jù)
hashtable在上面介紹過(guò)了，我們就只介紹inset。
inset結(jié)構(gòu)體
typedef struct intset {uint32_t encoding;// length就是數(shù)組的實(shí)際長(zhǎng)度uint32_t length;// contents 數(shù)組是實(shí)際保存元素的地方，數(shù)組中的元素有以下兩個(gè)特性：// 1.沒(méi)有重復(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來(lái)進(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)來(lái)保存，第一個(gè)節(jié)點(diǎn)保存元素的成員（member），而第二個(gè)元素則保存元素的分值（score）。
存儲(chǔ)結(jié)構(gòu)圖如下一目了然：
skiplist跳表
結(jié)構(gòu)體如下，skiplist是與dict結(jié)合來(lái)使用的，這個(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上加上索引：
這樣通過(guò)索引就能直接從node1查找到node5
redis跳躍表
讓我們?cè)倏聪聄edis的跳表結(jié)構(gòu)（圖太復(fù)雜，直接從網(wǎng)上找了張圖說(shuō)明）
- header:指向跳躍表的表頭節(jié)點(diǎn)，通過(guò)這個(gè)指針程序定位表頭節(jié)點(diǎn)的時(shí)間復(fù)雜度就為O(1)；
- tail:指向跳躍表的表尾節(jié)點(diǎn),通過(guò)這個(gè)指針程序定位表尾節(jié)點(diǎn)的時(shí)間復(fù)雜度就為O(1)；
- level:記錄目前跳躍表內(nèi),層數(shù)最大的那個(gè)節(jié)點(diǎn)的層數(shù)(表頭節(jié)點(diǎn)的層數(shù)不計(jì)算在內(nèi))，通過(guò)這個(gè)屬性可以再O(1)的時(shí)間復(fù)雜度內(nèi)獲取層高最好的節(jié)點(diǎn)的層數(shù)；
- length:記錄跳躍表的長(zhǎng)度,也即是,跳躍表目前包含節(jié)點(diǎn)的數(shù)量(表頭節(jié)點(diǎn)不計(jì)算在內(nèi))，通過(guò)這個(gè)屬性，程序可以再O(1)的時(shí)間復(fù)雜度內(nèi)返回跳躍表的長(zhǎng)度。
結(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)指針用于訪問(wè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í),訪問(wèn)會(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ì)象在字典序中的大小來(lái)進(jìn)行排序,成員對(duì)象較小的節(jié)點(diǎn)會(huì)排在前面(靠近表頭的方向),而成員對(duì)象較大的節(jié)點(diǎn)則會(huì)排在后面(靠近表尾的方向)。
五 三大特殊數(shù)據(jù)類型
1 geospatial（地理位置）
1.geospatial將指定的地理空間位置（緯度、經(jīng)度、名稱）添加到指定的key中。這些數(shù)據(jù)將會(huì)存儲(chǔ)到sorted set這樣的目的是為了方便使用GEORADIUS或者GEORADIUSBYMEMBER命令對(duì)數(shù)據(jù)進(jìn)行半徑查詢等操作。 2.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)制串） 3.有效的經(jīng)度是-180度到180度有效的緯度是-85.05112878度到85.05112878度應(yīng)用場(chǎng)景
2 Hyperloglog（基數(shù)）
什么是基數(shù)？ 不重復(fù)的元素
hyperloglog 是用來(lái)做基數(shù)統(tǒng)計(jì)的，其優(yōu)點(diǎn)是：輸入的提及無(wú)論多么大，hyperloglog使用的空間總是固定的12KB ，利用12KB，它可以計(jì)算2^64個(gè)不同元素的基數(shù)！非常節(jié)省空間！但缺點(diǎn)是估算的值，可能存在誤差應(yīng)用場(chǎng)景
網(wǎng)頁(yè)統(tǒng)計(jì)UV （瀏覽用戶數(shù)量，同一天同一個(gè)ip多次訪問(wèn)算一次訪問(wèn)，目的是計(jì)數(shù)，而不是保存用戶）
傳統(tǒng)的方式，set保存用戶的id，可以統(tǒng)計(jì)set中元素?cái)?shù)量作為標(biāo)準(zhǔn)判斷。
但如果這種方式保存大量用戶id，會(huì)占用大量?jī)?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的最大長(zhǎng)度是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ù)庫(kù)事務(wù)與redis事務(wù)
數(shù)據(jù)庫(kù)的事務(wù)
數(shù)據(jù)庫(kù)事務(wù)通過(guò)ACID（原子性、一致性、隔離性、持久性）來(lái)保證。
數(shù)據(jù)庫(kù)中除查詢操作以外，插入(Insert)、刪除(Delete)和更新(Update)這三種操作都會(huì)對(duì)數(shù)據(jù)造成影響，因?yàn)槭聞?wù)處理能夠保證一系列操作可以完全地執(zhí)行或者完全不執(zhí)行，因此在一個(gè)事務(wù)被提交以后，該事務(wù)中的任何一條SQL語(yǔ)句在被執(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ù)從開(kāi)始到執(zhí)行會(huì)經(jīng)歷開(kāi)始事務(wù)（muiti）、命令入隊(duì)和執(zhí)行事務(wù)(exec)三個(gè)階段，事務(wù)中的命令在加入時(shí)都沒(méi)有被執(zhí)行，直到提交時(shí)才會(huì)開(kāi)始執(zhí)行(Exec)一次性完成。
一組命令中存在兩種錯(cuò)誤不同處理方式
1.代碼語(yǔ)法錯(cuò)誤（編譯時(shí)異常）所有命令都不執(zhí)行
2.代碼邏輯錯(cuò)誤（運(yùn)行時(shí)錯(cuò)誤），其他命令可以正常執(zhí)行 （該點(diǎn)不保證事務(wù)的原子性）
為什么redis不支持回滾來(lái)保證原子性
這種做法的優(yōu)點(diǎn)：
- Redis 命令只會(huì)因?yàn)殄e(cuò)誤的語(yǔ)法而失敗（并且這些問(wèn)題不能在入隊(duì)時(shí)發(fā)現(xiàn)），或是命令用在了錯(cuò)誤類型的鍵上面：這也就是說(shuō)，從實(shí)用性的角度來(lái)說(shuō)，失敗的命令是由編程錯(cuò)誤造成的，而這些錯(cuò)誤應(yīng)該在開(kāi)發(fā)的過(guò)程中被發(fā)現(xiàn)，而不應(yīng)該出現(xiàn)在生產(chǎn)環(huán)境中。
- 因?yàn)椴恍枰獙?duì)回滾進(jìn)行支持，所以 Redis 的內(nèi)部可以保持簡(jiǎn)單且快速。
**鑒于沒(méi)有任何機(jī)制能避免程序員自己造成的錯(cuò)誤， 并且這類錯(cuò)誤通常不會(huì)在生產(chǎn)環(huán)境中出現(xiàn)， 所以 Redis 選擇了更簡(jiǎn)單、更快速的無(wú)回滾方式來(lái)處理事務(wù)。
事務(wù)監(jiān)控
悲觀鎖：認(rèn)為什么時(shí)候都會(huì)出現(xiàn)問(wèn)題，無(wú)論做什么操作都會(huì)加鎖。
樂(lè)觀鎖：認(rèn)為什么時(shí)候都不會(huì)出現(xiàn)問(wèn)題，所以不會(huì)上鎖！更新數(shù)據(jù)的時(shí)候去判斷一下，在此期間是否有人修改過(guò)這個(gè)數(shù)據(jù)。
使用cas實(shí)現(xiàn)樂(lè)觀鎖
redis使用watch key監(jiān)控指定數(shù)據(jù)，相當(dāng)于加樂(lè)觀鎖
watch保證事務(wù)只能在所有被監(jiān)視鍵都沒(méi)有被修改的前提下執(zhí)行， 如果這個(gè)前提不能滿足的話，事務(wù)就不會(huì)被執(zhí)行。
watch執(zhí)行流程
七 Redis持久化
Redis是一種內(nèi)存型數(shù)據(jù)庫(kù)，一旦服務(wù)器進(jìn)程退出，數(shù)據(jù)庫(kù)的數(shù)據(jù)就會(huì)丟失，為了解決這個(gè)問(wèn)題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í)行從而重建出原來(lái)的數(shù)據(jù)。寫操作命令記錄的格式跟Redis協(xié)議一致，以追加的方式進(jìn)行保存。
- Redis的持久化是可以禁用的，就是說(shuō)你可以讓數(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)過(guò)壓縮的二進(jìn)制文件，這個(gè)文件可以被保存到硬盤中，可以通過(guò)這個(gè)文件還原數(shù)據(jù)庫(kù)的狀態(tài)，它可以手動(dòng)執(zhí)行，也可以在redis.conf配置文件中配置，定時(shí)執(zhí)行。
工作原理
在進(jìn)行RDB時(shí)，redis的主進(jìn)程不會(huì)做io操作，會(huì)fork一個(gè)子進(jìn)程來(lái)完成該操作：
這種工作方式使得 Redis 可以從寫時(shí)復(fù)制（copy-on-write）機(jī)制中獲益(因?yàn)槭鞘褂米舆M(jìn)程進(jìn)行寫操作，而父進(jìn)程依然可以接收來(lái)自客戶端的請(qǐng)求)
觸發(fā)機(jī)制
在Redis中RDB持久化的觸發(fā)分為兩種：自己手動(dòng)觸發(fā)與自動(dòng)觸發(fā)。
主動(dòng)觸發(fā)
bgsave是異步進(jìn)行，進(jìn)行持久化的時(shí)候，redis還可以將繼續(xù)響應(yīng)客戶端請(qǐng)求
bgsave和save對(duì)比
自動(dòng)觸發(fā)
1、save自動(dòng)觸發(fā)配置，見(jiàn)下面配置，滿足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 yes2、從節(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，且沒(méi)有開(kāi)啟aof時(shí)
優(yōu)點(diǎn)：
1、RDB 的內(nèi)容為二進(jìn)制的數(shù)據(jù)，占用內(nèi)存更小，更緊湊，更適合做為備份文件；
2、RDB 對(duì)災(zāi)難恢復(fù)非常有用，它是一個(gè)緊湊的文件，可以更快的傳輸?shù)竭h(yuǎn)程服務(wù)器進(jìn)行 Redis 服務(wù)恢復(fù)；
3、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 等操作；
4、與 AOF 格式的文件相比，RDB 文件可以更快的重啟。
缺點(diǎn)：
1、因?yàn)?RDB 只能保存某個(gè)時(shí)間間隔的數(shù)據(jù)，如果中途 Redis 服務(wù)被意外終止了，則會(huì)丟失一段時(shí)間內(nèi)的 Redis 數(shù)據(jù)。
2、RDB 需要經(jīng)常 fork() 才能使用子進(jìn)程將其持久化在磁盤上。如果數(shù)據(jù)集很大，fork() 可能很耗時(shí)，并且如果數(shù)據(jù)集很大且 CPU 性能不佳，則可能導(dǎo)致 Redis 停止為客戶端服務(wù)幾毫秒甚至一秒鐘。
2 AOF（Append Only File）
以日志的形式來(lái)記錄每個(gè)寫的操作，將Redis執(zhí)行過(guò)的所有指令記錄下來(lái)（讀操作不記錄），只許追加文件但不可以改寫文件，redis啟動(dòng)之初會(huì)讀取該文件重新構(gòu)建數(shù)據(jù)，換言之，redis重啟的話就根據(jù)日志文件的內(nèi)容將寫指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復(fù)工作。
AOF配置項(xiàng)
# 默認(rèn)不開(kāi)啟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 noAOF的整個(gè)流程大體來(lái)看可以分為兩步，一步是命令的實(shí)時(shí)寫入（如果是appendfsync everysec 配置，會(huì)有1s損耗），第二步是對(duì)aof文件的重寫。
AOF 重寫機(jī)制
隨著Redis的運(yùn)行，AOF的日志會(huì)越來(lái)越長(zhǎng)，如果實(shí)例宕機(jī)重啟，那么重放整個(gè)AOF將會(huì)變得十分耗時(shí)，而在日志記錄中，又有很多無(wú)意義的記錄，比如我現(xiàn)在將一個(gè)數(shù)據(jù) incr一千次，那么就不需要去記錄這1000次修改，只需要記錄最后的值即可。所以就需要進(jìn)行 AOF 重寫。
Redis 提供了bgrewriteaof指令用于對(duì)AOF日志進(jìn)行重寫，該指令運(yùn)行時(shí)會(huì)開(kāi)辟一個(gè)子進(jìn)程對(duì)內(nèi)存進(jìn)行遍歷，然后將其轉(zhuǎn)換為一系列的 Redis 的操作指令，再序列化到一個(gè)日志文件中。完成后再替換原有的AOF文件，至此完成。
同樣的也可以在redis.config中對(duì)重寫機(jī)制的觸發(fā)進(jìn)行配置：
通過(guò)將no-appendfsync-on-rewrite設(shè)置為yes，開(kāi)啟重寫機(jī)制；auto-aof-rewrite-percentage 100意為比上次從寫后文件大小增長(zhǎng)了100%再次觸發(fā)重寫；
auto-aof-rewrite-min-size 64mb意為當(dāng)文件至少要達(dá)到64mb才會(huì)觸發(fā)制動(dòng)重寫。
觸發(fā)方式
優(yōu)點(diǎn)
1、數(shù)據(jù)安全，aof 持久化可以配置 appendfsync 屬性，有 always，每進(jìn)行一次 命令操作就記錄到 aof 文件中一次。
2、通過(guò) append 模式寫文件，即使中途服務(wù)器宕機(jī)，可以通過(guò) redis-check-aof 工具解決數(shù)據(jù)一致性問(wèn)題。
3、AOF 機(jī)制的 rewrite 模式。AOF 文件沒(méi)被 rewrite 之前（文件過(guò)大時(shí)會(huì)對(duì)命令 進(jìn)行合并重寫），可以刪除其中的某些命令（比如誤操作的 flushall）)
缺點(diǎn)
1、AOF 文件比 RDB 文件大，且恢復(fù)速度慢。
2、數(shù)據(jù)集大的時(shí)候，比 rdb 啟動(dòng)效率低。
3 rdb與aof對(duì)比
八 發(fā)布與訂閱
redis發(fā)布與訂閱是一種消息通信的模式：發(fā)送者（pub）發(fā)送消息，訂閱者（sub）接收消息。
redis通過(guò)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ā)布訂閱模式是通過(guò)字典數(shù)據(jù)類型實(shí)現(xiàn)的
struct redisServer {// ...dict *pubsub_channels;// ... };其中，字典的鍵為正在被訂閱的頻道， 而字典的值則是一個(gè)鏈表， 鏈表中保存了所有訂閱這個(gè)頻道的客戶端。
訂閱
當(dāng)使用subscribe訂閱時(shí)，在字典中找到頻道key（如沒(méi)有則創(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使用了通配符的方式來(lái)訂閱
通配符中?表示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ù)器。 2.前者稱為主節(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)（或者沒(méi)有），但一個(gè)從節(jié)點(diǎn)只有一個(gè)主主從復(fù)制的作用主要包括
- 數(shù)據(jù)冗余：主從復(fù)制實(shí)現(xiàn)了數(shù)據(jù)的熱備份，是持久化之外的一種數(shù)據(jù)冗余方式。
- 故障恢復(fù)：當(dāng)主節(jié)點(diǎn)出現(xiàn)問(wè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)景下，通過(guò)多個(gè)從節(jié)點(diǎn)分擔(dān)讀負(fù)載，可以大大提高Redis服務(wù)器的并發(fā)量。
- 高可用基石：除了上述作用以外，主從復(fù)制還是哨兵和集群能夠?qū)嵤┑幕A(chǔ)，因此說(shuō)主從復(fù)制是Redis高可用的基礎(chǔ)。
主從庫(kù)采用的是讀寫分離的方式
1 原理
分為全量復(fù)制與增量復(fù)制
全量復(fù)制：發(fā)生在第一次復(fù)制時(shí)
增量復(fù)制：只會(huì)把主從庫(kù)網(wǎng)絡(luò)斷連期間主庫(kù)收到的命令，同步給從庫(kù)
2 全量復(fù)制的三個(gè)階段
第一階段是主從庫(kù)間建立連接、協(xié)商同步的過(guò)程。
主要是為全量復(fù)制做準(zhǔn)備。從庫(kù)和主庫(kù)建立起連接，并告訴主庫(kù)即將進(jìn)行同步，主庫(kù)確認(rèn)回復(fù)后，主從庫(kù)間就可以開(kāi)始同步了。
具體來(lái)說(shuō)，從庫(kù)給主庫(kù)發(fā)送 psync 命令，表示要進(jìn)行數(shù)據(jù)同步，主庫(kù)根據(jù)這個(gè)命令的參數(shù)來(lái)啟動(dòng)復(fù)制。psync 命令包含了主庫(kù)的 runID 和復(fù)制進(jìn)度 offset 兩個(gè)參數(shù)。runID，是每個(gè) Redis 實(shí)例啟動(dòng)時(shí)都會(huì)自動(dòng)生成的一個(gè)隨機(jī) ID，用來(lái)唯一標(biāo)記這個(gè)實(shí)例。當(dāng)從庫(kù)和主庫(kù)第一次復(fù)制時(shí)，因?yàn)椴恢乐鲙?kù)的 runID，所以將 runID 設(shè)為“？”。offset，此時(shí)設(shè)為 -1，表示第一次復(fù)制。主庫(kù)收到 psync 命令后，會(huì)用 FULLRESYNC 響應(yīng)命令帶上兩個(gè)參數(shù)：主庫(kù) runID 和主庫(kù)目前的復(fù)制進(jìn)度 offset，返回給從庫(kù)。從庫(kù)收到響應(yīng)后，會(huì)記錄下這兩個(gè)參數(shù)。這里有個(gè)地方需要注意，FULLRESYNC 響應(yīng)表示第一次復(fù)制采用的全量復(fù)制，也就是說(shuō)，主庫(kù)會(huì)把當(dāng)前所有的數(shù)據(jù)都復(fù)制給從庫(kù)。
第二階段，主庫(kù)將所有數(shù)據(jù)同步給從庫(kù)。
從庫(kù)收到數(shù)據(jù)后，在本地完成數(shù)據(jù)加載。這個(gè)過(guò)程依賴于內(nèi)存快照生成的 RDB 文件。
具體來(lái)說(shuō)，主庫(kù)執(zhí)行 bgsave 命令，生成 RDB 文件，接著將文件發(fā)給從庫(kù)。從庫(kù)接收到 RDB 文件后，會(huì)先清空當(dāng)前數(shù)據(jù)庫(kù)，然后加載 RDB 文件。這是因?yàn)閺膸?kù)在通過(guò) replicaof 命令開(kāi)始和主庫(kù)同步前，可能保存了其他數(shù)據(jù)。為了避免之前數(shù)據(jù)的影響，從庫(kù)需要先把當(dāng)前數(shù)據(jù)庫(kù)清空。在主庫(kù)將數(shù)據(jù)同步給從庫(kù)的過(guò)程中，主庫(kù)不會(huì)被阻塞，仍然可以正常接收請(qǐng)求。否則，Redis 的服務(wù)就被中斷了。但是，這些請(qǐng)求中的寫操作并沒(méi)有記錄到剛剛生成的 RDB 文件中。為了保證主從庫(kù)的數(shù)據(jù)一致性，主庫(kù)會(huì)在內(nèi)存中用專門的 replication buffer，記錄 RDB 文件生成后收到的所有寫操作。
第三個(gè)階段，主庫(kù)會(huì)把第二階段執(zhí)行過(guò)程中新收到的寫命令，再發(fā)送給從庫(kù)。
具體的操作是，當(dāng)主庫(kù)完成 RDB 文件發(fā)送后，就會(huì)把此時(shí) replication buffer 中的修改操作發(fā)給從庫(kù)，從庫(kù)再重新執(zhí)行這些操作。這樣一來(lái)，主從庫(kù)就實(shí)現(xiàn)同步了。
十 哨兵機(jī)制
哨兵的核心功能是主節(jié)點(diǎn)的自動(dòng)故障轉(zhuǎn)移
下圖是一個(gè)典型的哨兵集群監(jiān)控的邏輯圖
Redis Sentinel包含了若個(gè)Sentinel節(jié)點(diǎn)，這樣做也帶來(lái)了兩個(gè)好處：
哨兵實(shí)現(xià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)。這一過(guò)程是通過(guò)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)控：
主觀/客觀下線
主觀下線
每個(gè)Sentinel節(jié)點(diǎn)，每隔1秒會(huì)對(duì)數(shù)據(jù)節(jié)點(diǎn)發(fā)送ping命令做心跳檢測(cè)，當(dāng)這些節(jié)點(diǎn)超過(guò)down-after-milliseconds沒(méi)有進(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ù)就是過(guò)半數(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來(lái)進(jìn)行實(shí)際的故障轉(zhuǎn)移工作。Redis使用了Raft算法來(lái)實(shí)現(xiàn)哨兵領(lǐng)導(dǎo)者選舉，大致思路如下：
故障轉(zhuǎn)移
選舉出的Leader Sentinel節(jié)點(diǎn)將負(fù)責(zé)故障轉(zhuǎn)移，也就是進(jìn)行master/slave節(jié)點(diǎn)的主從切換。故障轉(zhuǎn)移，首先要從slave節(jié)點(diǎn)中篩選出一個(gè)作為新的master，主要考慮以下slave信息：
接著，篩選完slave后， 會(huì)對(duì)它執(zhí)行slaveof no one命令，讓其成為主節(jié)點(diǎn)。
最后，Sentinel領(lǐng)導(dǎo)者節(jié)點(diǎn)會(huì)向剩余的slave節(jié)點(diǎn)發(fā)送命令，讓它們成為新的master節(jié)點(diǎn)的從節(jié)點(diǎn)，復(fù)制規(guī)則與parallel-syncs參數(shù)有關(guān)。
Sentinel節(jié)點(diǎn)集合會(huì)將原來(lái)的master節(jié)點(diǎn)更新為slave節(jié)點(diǎn)，并保持著對(duì)其關(guān)注，當(dāng)其恢復(fù)后命令它去復(fù)制新的主節(jié)點(diǎn)。
注：Leader Sentinel節(jié)點(diǎn)，會(huì)從新的master節(jié)點(diǎn)那里得到一個(gè)configuration epoch，本質(zhì)是個(gè)version版本號(hào)，每次主從切換的version號(hào)都必須是唯一的。其他的哨兵都是根據(jù)version來(lái)更新自己的master配置。
十一 緩存穿透、擊穿、雪崩
1 緩存穿透
- 問(wèn)題來(lái)源
緩存穿透是指緩存和數(shù)據(jù)庫(kù)中都沒(méi)有的數(shù)據(jù)，而用戶不斷發(fā)起請(qǐng)求。由于緩存是不命中時(shí)被動(dòng)寫的，并且出于容錯(cuò)考慮，如果從存儲(chǔ)層查不到數(shù)據(jù)則不寫入緩存，這將導(dǎo)致這個(gè)不存在的數(shù)據(jù)每次請(qǐng)求都要到存儲(chǔ)層去查詢，失去了緩存的意義。在流量大時(shí)，可能DB就掛掉了，要是有人利用不存在的key頻繁攻擊我們的應(yīng)用，這就是漏洞。
如發(fā)起為id為“-1”的數(shù)據(jù)或id為特別大不存在的數(shù)據(jù)。這時(shí)的用戶很可能是攻擊者，攻擊會(huì)導(dǎo)致數(shù)據(jù)庫(kù)壓力過(guò)大。
- 解決方案
2 緩存擊穿
- 問(wèn)題來(lái)源
緩存擊穿是指緩存中沒(méi)有但數(shù)據(jù)庫(kù)中有的數(shù)據(jù)（一般是緩存時(shí)間到期），這時(shí)由于并發(fā)用戶特別多，同時(shí)讀緩存沒(méi)讀到數(shù)據(jù)，又同時(shí)去數(shù)據(jù)庫(kù)去取數(shù)據(jù)，引起數(shù)據(jù)庫(kù)壓力瞬間增大，造成過(guò)大壓力。
- 解決方案
1、設(shè)置熱點(diǎn)數(shù)據(jù)永遠(yuǎn)不過(guò)期。
2、接口限流與熔斷，降級(jí)。重要的接口一定要做好限流策略，防止用戶惡意刷接口，同時(shí)要降級(jí)準(zhǔn)備，當(dāng)接口中的某些服務(wù)不可用時(shí)候，進(jìn)行熔斷，失敗快速返回機(jī)制。
3、加互斥鎖
3 緩存雪崩
- 問(wèn)題來(lái)源
緩存雪崩是指緩存中數(shù)據(jù)大批量到過(guò)期時(shí)間，而查詢數(shù)據(jù)量巨大，引起數(shù)據(jù)庫(kù)壓力過(guò)大甚至down機(jī)。和緩存擊穿不同的是，緩存擊穿指并發(fā)查同一條數(shù)據(jù)，緩存雪崩是不同數(shù)據(jù)都過(guò)期了，很多數(shù)據(jù)都查不到從而查數(shù)據(jù)庫(kù)。
- 解決方案
文章最后
每一項(xiàng)技術(shù)深挖都是一個(gè)龐大的體系，學(xué)海無(wú)涯，共勉。
原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?
總結(jié)
- 上一篇： 解读Batch Normalizatio
- 下一篇： eBPF技术应用云原生网络实践系列之基于