1. 數據庫

數據結構

/* Redis database representation. There are multiple databases identified* by integers from 0 (the default database) up to the max configured* database. The database number is the 'id' field in the structure. */ typedef struct redisDb {// 數據庫鍵空間，保存著數據庫中的所有鍵值對dict *dict; /* The keyspace for this DB */// 鍵的過期時間，字典的鍵為鍵，字典的值為過期事件 UNIX 時間戳dict *expires; /* Timeout of keys with a timeout set */// 正處于阻塞狀態(tài)的鍵dict *blocking_keys; /* Keys with clients waiting for data (BLPOP) */// 可以解除阻塞的鍵dict *ready_keys; /* Blocked keys that received a PUSH */// 正在被 WATCH 命令監(jiān)視的鍵dict *watched_keys; /* WATCHED keys for MULTI/EXEC CAS */struct evictionPoolEntry *eviction_pool; /* Eviction pool of keys */// 數據庫號碼int id; /* Database ID */// 數據庫的鍵的平均 TTL ，統計信息long long avg_ttl; /* Average TTL, just for stats */} redisDb;```### 切換數據庫默認情況下，Redis客戶端的目標數據庫為0號數據庫，但是客戶端可以通過SELECT n來切換目標數據庫。### 數據庫鍵空間鍵空間的鍵其實就是數據庫的鍵。 如：

SET message “hello world”
RPUSH alphabet “a” “b” “c”
HSET book name “Redis in Action”
HSET book name “Redis in Action”
HSET book name “Redis in Action”

dict是一個鍵空間，alpahbet是一個列表鍵，book是一個哈希表鍵，message是一個字符串鍵。### 數據庫的增刪改查以list對象作為例子：- 添加：rpush key value- 刪除：pop key- 查找：lindex key idx- 修改：lset key value- 長度：llen### 過期鍵的設置和刪除

PEXPIREAT x n
PERSIST x n
“`

過期鍵有三種刪除策略：
- 定時刪除:設置定時器，這樣很明顯會占cpu資源，但是對內存友好。
- 惰性刪除：下次拿出開始，檢查到鍵過期則刪除，這樣顯然對內存不友好對cpu友好。
- 定期刪除：一種介于兩者之間的策略。
-

AOF，RDB和復制功能對過期鍵的處理

RDB保存數據
- 生成RDB文件:通過SAVA命令或者BGSAVE可以創(chuàng)建一個RDB文件。過期的鍵不會保存到RDB文件中。
- 載入RDB文件:如果服務器是主服務器那么未過期的鍵會被載入到數據庫中，而過期的就會被忽略。從服務器則無論時候過期都會載入，然后主服務器進行數據同步時會清空從服務器中的數據。

AOF文件寫入
- aof文件主要是記錄數據寫入修改刪除操作
- 當過期鍵被刪除的時候，程序就會向aop文件
追加一條DEL命令來顯示記錄該鍵已經被刪除。

復制
- 主服務器，在刪除一個過期的鍵之后，會顯式地向所有的從服務器發(fā)送一個DEL來通知從服務器刪除這個過期鍵。
- 從服務器只有收到主服務器發(fā)來的DEL命令之后，才會刪除過期鍵，否則像處理未過期的鍵一樣處理。

2.RDB持久化

概述:Redis可以將數據庫狀態(tài)保存為RDB文件放在磁盤，服務器停機的情況下可以用RDB來還原數據庫狀態(tài)。

RDB的創(chuàng)建和載入

• 創(chuàng)建有兩種方式SAVE和BGSAVE，區(qū)別是SAVE阻塞，二BGSAVE非阻塞，這一點從偽代碼可以看出來。

• 載入的時機是服務器啟動時自動執(zhí)行的，但是前提是要關閉AOF的持久化功能。

RDB的文件結構

• REDIS部分長度為5字節(jié)，保存著REDIS這五個字符。
• db_version記錄著RDB的版本號。
• databases部分包含著多個數據庫。
• EOF常量的長度是1字節(jié)，標志著RDF文件內容結束。
• check_sum是檢驗和。

RDB的文件的databases部分的結構

• SELECTDB的長度是1字節(jié)，標志位。
• db_number保存著一個數據庫號碼。
• key_value_pairs保存了數據庫中所有鍵值對數據。

databases部分的key_value_pairs部分

然后每種類型的value又有不同的數據結構：

3.AOF的持久化

AOF持久化與RDB持久化通過保存數據庫中的鍵值對來記錄數據庫狀態(tài)不同，AOF持久化是通過保存Redis服務器所執(zhí)行的寫命令來記錄數據庫狀態(tài)的。

AOF的持久化分為三個步驟：

• 命令追加：將命令追加到aof_buf緩沖區(qū)中
• 寫入文件：將其寫入aof文件
• 文件同步：對aof文件進行同步

文件的寫入和同步可以由以下偽代碼表示：

如圖flushApendOnlyFile函數由appnedfsync這個值來決定同步的時機。

• always代表將緩存區(qū)的所有內容寫入同步。
• everysec表示超過一秒鐘就對aof進行同步。
• no表示只寫入而不同步。

AOF的重寫

aof的重寫是為了解決寫命令冗余導致aof文件膨脹的問題，redis的解決方法對aof文件進行重寫。
重寫的方法并不是對比前后兩個版本的aof文件，而是直接對比兩個版本的數據庫，直接根據數據的不同重寫aof文件。

這樣就產生了一個新的問題，重寫程序aof_rewrite函數可以創(chuàng)建一個新的AOF文件，但是這個函數進行大量的寫入操作，而且因為redis是單線程，所以會長時間阻塞！

為了解決這個問題，Redis把重寫操作放到了子進程中，讓父進程繼續(xù)去處理命令請求。但是又有一個新的問題，在子進程進行AOF重寫階段，服務器還要繼續(xù)處理命令請求，而新的命令可能對數據庫進行修改導致重寫后的AOF文件的狀態(tài)不一致。

為了解決這個問題，Redis設置了一個AOF重寫緩存區(qū)，這個緩存區(qū)在服務器創(chuàng)建子進程的時候使用，所以在子進程重寫階段，服務器只是多了一個步驟，將寫命令同時追加到AOF重寫緩存區(qū)中，當子進程對AOF重寫完成后，將重寫緩存區(qū)寫入到新的AOF文件中。

4.事件

文件事件

Reids的文件事件處理器是基于Reactor模式的，由四個部分組成

三個步驟：
- 連接應答處理器

當Redis服務器進行初始化的時候，程序會將這個連接應答處理器和服務器監(jiān)聽套接字的AE_READABLE事件關聯；當客戶端連接服務器監(jiān)聽套接字的時候，套接字就會產生AE_READABLE事件，引發(fā)連接應答處理器執(zhí)行相應操作。

• 命令請求處理器

  連接成功后，服務器會將客戶端套接字的AE_READABBLE事件和命令請求處理器關聯起來，當客戶端向服務器發(fā)送命令請求的時候，套接字就會產生AE_READABLE事件，引發(fā)命令請求處理器執(zhí)行。

• 命令回復處理器

  當服務器有命令回復客戶端時，服務端將客戶端套接字的AE_WRIABLE關聯起來，當客戶端準備好接收服務器傳回的命令回復的時候，就會產生AE_WRITABLE事件，引發(fā)命令回復處理器執(zhí)行。

如果大家不能理解，建議去看一下Linux的網絡通信模型。

時間事件

時間事件分兩種：定時事件和周期性事件。

實現：服務器將所有的時間事件放在一個無序鏈表中，每當時間事件執(zhí)行器運行時，它就遍歷整個鏈表，查找所有已到達的時間事件，并調用相應的事件執(zhí)行器。

總結

以上是生活随笔為你收集整理的Redis学习之单机数据库（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。