Redis 原理及混合持久化

作者：小汪哥 2021-10-04 21:11:18

redis 是單線程程序的，除了 Redis 之外，Node.js 也是單線程，Nginx 也是單線程，但是它們都是服務(wù)器高性能的典范。

上一篇文章我們對(duì)redis的基本類型及相應(yīng)的應(yīng)用場(chǎng)景做了了解，那你知道redis 為什么這么快嗎?redis 宕機(jī)了怎么辦?redis 的持久化方式有哪些?如果你是云服務(wù)廠商，你怎么優(yōu)化你的云版的redis呢?

本文將對(duì)redis 的相關(guān)原理進(jìn)行分析。

線程 IO 模型

redis 是單線程程序的，除了 Redis 之外，Node.js 也是單線程，Nginx 也是單線程，但是它們都是服務(wù)器高性能的典范。

redis 單線程也這么快，也要?dú)w功于非阻塞IO和多路復(fù)用器。

非阻塞IO

能讀多少讀多少，取決于內(nèi)核為套接字分配的讀緩沖區(qū)內(nèi)部的數(shù)據(jù)字節(jié)數(shù)。

能寫多少寫多少，取決于內(nèi)核為套接字分配的寫緩存區(qū)空閑空間的字節(jié)數(shù)。

事件輪詢(多路復(fù)用)

非阻塞 IO 有個(gè)問題，那就是線程要讀數(shù)據(jù)，結(jié)果讀了一部分就返回了，線程如何知道

何時(shí)才應(yīng)該繼續(xù)讀。也就是當(dāng)數(shù)據(jù)到來時(shí)，線程如何得到通知。寫也是一樣，如果緩沖區(qū)滿

了，寫不完，剩下的數(shù)據(jù)何時(shí)才應(yīng)該繼續(xù)寫，線程也應(yīng)該得到通知。

最簡(jiǎn)單的事件輪詢API，如下圖所示。select函數(shù)，它是操作系統(tǒng)提供的。在描述符特別多的情況下，性能特別差。現(xiàn)代的操作系統(tǒng)多路復(fù)用改為：epoll(linux) kqueue(freeBsd 和 macosx)。

目前支持I/O多路復(fù)用的系統(tǒng)調(diào)用有 select，pselect，poll，epoll，I/O多路復(fù)用就是通過一種機(jī)制，一個(gè)進(jìn)程可以監(jiān)視多個(gè)描述符，一旦某個(gè)描述符就緒(一般是讀就緒或者寫就緒)，能夠通知程序進(jìn)行相應(yīng)的讀寫操作。但select，pselect，poll，epoll本質(zhì)上都是同步I/O，因?yàn)樗麄兌夹枰谧x寫事件就緒后自己負(fù)責(zé)進(jìn)行讀寫，也就是說這個(gè)讀寫過程是阻塞的，而異步I/O則無需自己負(fù)責(zé)進(jìn)行讀寫，異步I/O的實(shí)現(xiàn)會(huì)負(fù)責(zé)把數(shù)據(jù)從內(nèi)核拷貝到用戶空間。

select 和epoll的區(qū)別

select

首先是垮平臺(tái)的，select本質(zhì)上是通過設(shè)置或者檢查存放fd標(biāo)志位的數(shù)據(jù)結(jié)構(gòu)來進(jìn)行下一步處理，

select最大的缺陷就是單個(gè)進(jìn)程所打開的FD是有一定限制的，它由FD_SETSIZE設(shè)置，默認(rèn)值是1024

對(duì)socket進(jìn)行掃描時(shí)是線性掃描，即采用輪詢的方法，效率較低。

epoll

是2.6 內(nèi)核提出的,是 select 和poll 的增強(qiáng)版，epoll使用一個(gè)文件描述符管理多個(gè)描述符，將用戶關(guān)系的文件描述符的事件存放到內(nèi)核的一個(gè)事件表中，這樣在用戶空間和內(nèi)核空間的copy只需一次。

它的原理其實(shí)就是epoll支持水平觸發(fā)和邊緣觸發(fā)，最大的特點(diǎn)在于邊緣觸發(fā)，它只告訴進(jìn)程哪些fd剛剛變?yōu)榫途w態(tài)，并且只會(huì)通知一次。

還有一個(gè)特點(diǎn)是，epoll使用“事件”的就緒通知方式，通過epoll_ctl注冊(cè)fd，

一旦該fd就緒，內(nèi)核就會(huì)采用類似callback的回調(diào)機(jī)制來激活該fd，epoll_wait便可以收到通知。

它的有點(diǎn)優(yōu)點(diǎn)：

1、沒有最大并發(fā)連接的限制，能打開的FD的上限遠(yuǎn)大于1024(1G的內(nèi)存上能監(jiān)聽約10萬個(gè)端口)。

2、效率提升，不是輪詢的方式，不會(huì)隨著FD數(shù)目的增加效率下降。

內(nèi)存拷貝，利用mmap()文件映射內(nèi)存加速與內(nèi)核空間的消息傳遞;即epoll使用mmap減少?gòu)?fù)制開銷。

單線程如何處理相應(yīng)請(qǐng)求?

通過指令隊(duì)列，相應(yīng)隊(duì)列，和定時(shí)任務(wù)的設(shè)計(jì)來相應(yīng)請(qǐng)求。

指令隊(duì)列

客戶端指令通過隊(duì)列來排隊(duì)進(jìn)行順序處理，先到先服務(wù)

響應(yīng)隊(duì)列

等隊(duì)列里面有數(shù)據(jù)了再把客戶端fd 放進(jìn)去，避免浪費(fèi)cpu

定時(shí)任務(wù)

服務(wù)器處理要響應(yīng) IO 事件外，還要處理其它事情。比如定時(shí)任務(wù)就是非常重要的一件事。如果線程阻塞在 select 系統(tǒng)調(diào)用上，定時(shí)任務(wù)將無法得到準(zhǔn)時(shí)調(diào)度。

那 Redis 是如何解決這個(gè)問題的呢?

Redis 的定時(shí)任務(wù)會(huì)記錄在一個(gè)稱為最小堆的數(shù)據(jù)結(jié)構(gòu)中。這個(gè)堆中，最快要執(zhí)行的任務(wù)排在堆的最上方。在每個(gè)循環(huán)周期，Redis 都會(huì)將最小堆里面已經(jīng)到點(diǎn)的任務(wù)立即進(jìn)行處理。處理完畢后，將最快要執(zhí)行的任務(wù)還需要的時(shí)間記錄下來，這個(gè)時(shí)間就是 select 系統(tǒng)調(diào)用的 timeout 參數(shù)。因?yàn)?Redis 知道未來 timeout 時(shí)間內(nèi)，沒有其它定時(shí)任務(wù)需要處理，所以可以安心睡眠 timeout 的時(shí)間。

Nginx 和 Node 的事件處理原理和 Redis 也是類似的。

通信協(xié)議

Redis 的請(qǐng)求也相當(dāng)于一次rpc 的調(diào)用，rpc中，通信協(xié)議的設(shè)計(jì)是非常重要的。，Redis 的作者認(rèn)為數(shù)據(jù)庫(kù)系統(tǒng)的瓶頸一般不在于網(wǎng)絡(luò)流量，而是數(shù)據(jù)庫(kù)自身內(nèi)部邏輯處理上。所以即使 Redis 使用了浪費(fèi)流量的文本協(xié)議，依然可以取得極高的訪問性能。Redis

將所有數(shù)據(jù)都放在內(nèi)存，用一個(gè)單線程對(duì)外提供服務(wù)，單個(gè)節(jié)點(diǎn)在跑滿一個(gè) CPU 核心的情況下可以達(dá)到了 10w/s 的超高 QPS。

RESP(Redis Serialization Protocol)

RESP 是 Redis 序列化協(xié)議的簡(jiǎn)寫。它是一種直觀的文本協(xié)議，優(yōu)勢(shì)在于實(shí)現(xiàn)異常簡(jiǎn)

單，解析性能極好。Redis 協(xié)議里有大量冗余的回車換行符，但是這不影響它成為互聯(lián)網(wǎng)技術(shù)領(lǐng)域非常受歡

迎的一個(gè)文本協(xié)議。有很多開源項(xiàng)目使用 RESP 作為它的通訊協(xié)議。在技術(shù)領(lǐng)域性能并不總

是一切，還有簡(jiǎn)單性、易理解性和易實(shí)現(xiàn)性，這些都需要進(jìn)行適當(dāng)權(quán)衡。

關(guān)于持久化

一款優(yōu)秀的中間件都會(huì)考慮到持久化，Redis 的數(shù)據(jù)全部在內(nèi)存里，如果突然宕機(jī)，數(shù)據(jù)就會(huì)全部丟失，因此必須有一種機(jī)制來保證 Redis 的數(shù)據(jù)不會(huì)因?yàn)楣收隙鴣G失，這種機(jī)制就是 Redis 的持久化機(jī)制

Redis 的持久化機(jī)制有兩種，第一種是RDB(快照)(Redis DataBase)，第二種是 AOF(Append Only File)日志。

RDB原理:

redis 使用操作系統(tǒng)的多進(jìn)程(cow copy on write【寫時(shí)復(fù)制】)機(jī)制來實(shí)現(xiàn)快照的持久化;手動(dòng)命令save,bgsave;配置文件設(shè)置.

fork 多進(jìn)程

調(diào)用glibc 的函數(shù) fork產(chǎn)生一個(gè)子進(jìn)程,快照持久化交個(gè)子進(jìn)程處理.子進(jìn)程剛剛產(chǎn)生時(shí)和父進(jìn)程共享代碼段和數(shù)據(jù)段,隨著父進(jìn)程修改操作持續(xù)進(jìn)行，more 共享頁面被分離出來,創(chuàng)建進(jìn)程變快;內(nèi)存增長(zhǎng)，不會(huì)超過原來的2倍.另外一個(gè) Redis 實(shí)例里冷數(shù)據(jù)占的比例往往是比較高的，所以很少會(huì)出現(xiàn)所有的頁面都會(huì)被分離，被分離的往往只有其中一部分頁面。每個(gè)頁面的大小只有 4K，一個(gè) Redis 實(shí)例里面一般都會(huì)有成千上萬的頁面子進(jìn)程的數(shù)據(jù)沒有變化，可以安心的遍歷數(shù)據(jù)，進(jìn)行序列化寫磁盤。

AOF原理

AOF 日志存儲(chǔ)的是 Redis 服務(wù)器的順序指令序列，AOF 日志只記錄對(duì)內(nèi)存進(jìn)行修改的指令記錄。隨著操作的進(jìn)行，指令文本會(huì)越來越大。需要對(duì)AOF 重寫，進(jìn)行日志瘦身，redis 提供bgrewriteaof 指令對(duì)AOF 進(jìn)行瘦身,原理是開辟一個(gè)子進(jìn)程對(duì)內(nèi)存進(jìn)行遍歷，序列化一個(gè)新的aof+這段時(shí)間的增量。Linux 的glibc 提供了 fsync(int fd) 強(qiáng)制從內(nèi)核緩存刷到磁盤，fsync 很慢，一般生產(chǎn)環(huán)境每隔一秒執(zhí)行一次，可配置。

redis 是先執(zhí)行指令再寫日志，leveldb\hbase 相反。

關(guān)于redis 運(yùn)維的一些經(jīng)驗(yàn)，不要在主節(jié)點(diǎn)進(jìn)行持久化，要在從節(jié)點(diǎn)進(jìn)行持久化，因?yàn)槌志没且粋€(gè)很耗時(shí)的IO操作。

關(guān)于混合持久化

為什么要進(jìn)行混合持久化?首先fork 動(dòng)作需要copy 頁表，大內(nèi)存場(chǎng)景下阻塞server，百ms 或秒級(jí) latency spike(延遲尖峰)，比較適合每天定時(shí)的全備場(chǎng)景。部分云廠商的方案比如：redis+rocksDB。從以下幾個(gè)方面來分析。

數(shù)據(jù)寫入

寫入Redis 內(nèi)存，并記錄增量，后臺(tái)線程異步應(yīng)用增量到RocksDB

數(shù)據(jù)可靠性

RocksDB 包含全量數(shù)據(jù)，徹底避免Fork 調(diào)用，啟動(dòng)時(shí)，從RocksDB 加載全量索引信息到內(nèi)存

數(shù)據(jù)讀取

數(shù)據(jù)在redis 內(nèi)存，直接讀取，數(shù)據(jù)不在Redis 內(nèi)存，整體換入Redis 再讀取，針對(duì)簡(jiǎn)單命令，可以直接從Rocks DB 讀取。

關(guān)于RcoksDB，RcoksDB可嵌入的，持久型的key-value 存儲(chǔ)，

RocksDB項(xiàng)目起源于Facebook的一個(gè)實(shí)驗(yàn)項(xiàng)目,該項(xiàng)目旨在開發(fā)一個(gè)與快速存儲(chǔ)器(尤其是閃存)存儲(chǔ)數(shù)據(jù)性能相當(dāng)?shù)臄?shù)據(jù)庫(kù)軟件，以應(yīng)對(duì)高負(fù)載服務(wù)。這是一個(gè)c++庫(kù),可用于存儲(chǔ)鍵和值,可以是任意大小的字節(jié)流。它支持原子讀和寫。RocksDB具有高度靈活的配置功能,可以通過配置使其運(yùn)行在各種各樣的生產(chǎn)環(huán)境,包括純內(nèi)存,Flash,硬盤或HDFS。它支持各種壓縮算法，并提供了便捷的生產(chǎn)環(huán)境維護(hù)和調(diào)試工具。

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

每個(gè)key對(duì)應(yīng)一個(gè)RocksDB metakey,存儲(chǔ)key 的元數(shù)據(jù)。所有的metakey 相鄰存儲(chǔ)，啟動(dòng)加載效率高，復(fù)雜key的每個(gè)元素在RocksDB 里面對(duì)應(yīng)一個(gè)Datakey，元素在RocksDB 相鄰存儲(chǔ)，訪問效率高。簡(jiǎn)化String 類型，metakey 與Datakey 合并優(yōu)化IO。

數(shù)據(jù)交換模型(SWAP MODE)

內(nèi)存數(shù)據(jù)換出：后臺(tái)定期檢查是否超哥內(nèi)存使用閥值，根據(jù)訪問評(píng)率、大小等選擇key 預(yù)備淘汰。

磁盤數(shù)據(jù)換入：某個(gè)key 被頻繁讀取或有o(n) 的讀取操作，整個(gè)key 換入的RocksDB,加速訪問;key 寫入時(shí)，數(shù)據(jù)不再內(nèi)存，整體換入內(nèi)存;默認(rèn)后臺(tái)多線程異步換入。

主備同步&遷移

全量同步：使用RocksDB checkoutpoint 代替RDB,避免fork 系統(tǒng)調(diào)用，備接收到checkoutpoint 數(shù)據(jù)只需加載meta key

增量同步：從 checkoutpoint 對(duì)應(yīng)aof binlog 位點(diǎn)繼續(xù)增量同步，增量同步斷開，直接從斷開位置繼續(xù)同步，無需觸發(fā)全量同步。