速度 快

正常情況下，Redis 執(zhí)行命令的速度 非常快，官方給出的數(shù)字是 讀寫性能 可以達(dá)到 10萬/秒，當(dāng)然這也取決于 機(jī)器的性能，但這里先不討論 機(jī)器性能上的差異，只分析一下是什么造就了 Redis 除此之外的 速度，可以大致歸納為以下四點(diǎn)：

• Redis 的 所有數(shù)據(jù) 都是 存放在 內(nèi)存 中的，表1-1是谷歌公司2009年給出的各層級(jí)硬件執(zhí)行速度，所以 把數(shù)據(jù)放在內(nèi)存 中是 Redis速度快 的最主要原因。
• Redis 使用 C語言 實(shí)現(xiàn)的，一般來說 C語言 實(shí)現(xiàn)的程序 “距離” 操作系統(tǒng)更近，執(zhí)行速度 相對(duì)會(huì)更快。
• Redis 使用了 單線程架構(gòu)，預(yù)防了 多線程 可能產(chǎn)生的 競爭問題。
• 作者對(duì)于 Redis源代碼 可以說是 精打細(xì)磨，曾經(jīng)有人評(píng)價(jià) Redis 是少有的 集性能和優(yōu)雅于一身 的 開源代碼。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-CZFzKuIB-1621301836851)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210513170503130.png)]

表1-1 谷歌公司給出的 各層級(jí) 硬件 執(zhí)行速度

基于 鍵值對(duì) 的數(shù)據(jù)結(jié)構(gòu) 服務(wù)器

幾乎所有的 編程語言 都提供了類似 字典 的功能，

例如Java里的 map、Python里的 dict，

類似于這種 組織數(shù)據(jù)的方式 叫做 基于鍵值 的方式，

與很多 鍵值對(duì) 數(shù)據(jù)庫 不同的是，

Redis 中的 值 不僅可以是 字符串，而且還可以是 具體的 數(shù)據(jù)結(jié)構(gòu)，

這樣不僅能 便于在許多應(yīng)用場景的開發(fā)，同時(shí)也能夠 提高開發(fā)效率。

Redis 的 全稱 是 Remote Dictionary Server，

它主要提供了 5種數(shù)據(jù)結(jié)構(gòu)：字符串、哈希、列表、集合、有序集合，

同時(shí)在 字符串 的 基礎(chǔ)之上 演變 出了 位圖（Bitmaps）和 HyperLogLog 兩種神奇的 “數(shù)據(jù)結(jié)構(gòu)”，

并且隨著 LBS（Location Based Service，基于位置服務(wù)）的不斷發(fā)展，Redis 3.2 版本 中加入有關(guān) GEO（地理信息定位）的功能，

總之在這些數(shù)據(jù)結(jié)構(gòu)的幫助下，開發(fā)者可以開發(fā)出各種“有意思”的應(yīng)用。

豐富的功能

除了 5種數(shù)據(jù)結(jié)構(gòu)，Redis 還提供了許多額外的功能：

• 提供了 鍵過期 功能，可以用來實(shí)現(xiàn) 緩存。
• 提供了 發(fā)布訂閱 功能，可以用來實(shí)現(xiàn) 消息系統(tǒng)。
• 支持 Lua腳本 功能，可以利用 Lua 創(chuàng)造出 新的Reds命令。
• 提供了簡單的 事務(wù) 功能，能在一定程度上保證 事務(wù)特性。
• 提供了 流水線（Pipeline）功能，這樣 客戶端 能將 一批命令 一次性 傳到 Redis，減少了 網(wǎng)絡(luò)的開銷。

簡單穩(wěn)定

Redis 的 簡單 主要表現(xiàn)在 三個(gè)方面。

首先，Redis 的 源碼 很少，早期版本 的代碼只有 2萬行左右，3.0版本 以后由于添加了 集群特性，代碼增至 5萬行左右，相對(duì)于很多 NoSQL數(shù)據(jù)庫 來說代碼量相對(duì)要少很多，也就意味著普通的開發(fā)和運(yùn)維人員完全可以“吃透”它。

其次，Redis 使用 單線程模型，這樣不僅使得 Redis服務(wù)端處理模型 變得簡單， 而且也使得 客戶端開發(fā) 變得簡單。

最后，Redis 不需要依賴于 操作系統(tǒng) 中的類庫（例如 Memcache 需要 依賴 libevent 這樣的 系統(tǒng)類庫），Redis 自己 實(shí)現(xiàn) 了 事件處理 的相關(guān)功能。

Redis 雖然很簡單，但是不代表它不穩(wěn)定。

以筆者維護(hù)的上千個(gè)Redis為例，沒有出現(xiàn)過因?yàn)镽edis自身bug而宕掉的情況。

客戶端語言 多

Redis 提供了 簡單的 TCP通信協(xié)議，很多 編程語言 可以很 方便地 接入到 Redis，并且由于 Redis 受到 社區(qū)和各大公司的 廣泛認(rèn)可，所以 支持Redis的客戶端語言 也非常 多，幾乎涵蓋了 主流的編程語言，例如Java、PHP、Python、C、C++、Nodejs等，第4章我們將對(duì) Redis的客戶端 進(jìn)行詳細(xì)說明。

持久化

通常看，將 數(shù)據(jù) 放在 內(nèi)存 中是 不安全的，一旦發(fā)生 斷電 或者 機(jī)器故障，重要的數(shù)據(jù) 可能就會(huì) 丟失，因此 Redis 提供了 兩種 持久化 方式：RDB 和 AOF，即可以用 兩種策略 將 內(nèi)存的數(shù)據(jù) 保存到 硬盤中（如圖1-1所示），這樣就 保證 了 數(shù)據(jù)的可持久性，第5章我們將對(duì) Redis的持久化 進(jìn)行詳細(xì)說明。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-1inDcMPh-1621301836855)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210513173702303.png)]

主從復(fù)制

Redis 提供了 復(fù)制 功能，實(shí)現(xiàn)了 多個(gè)相同數(shù)據(jù)的Redis副本（如圖1-2所示），復(fù)制 功能是 分布式Redis的基礎(chǔ)。第6章我們將會(huì)對(duì) Redis的復(fù)制 進(jìn)行詳細(xì)說明。

高可用 和 分布式

Redis 從 2.8版本 正式提供了 高可用 實(shí)現(xiàn)Redis Sentinel，它能夠保證 Redis節(jié)點(diǎn) 的 故障發(fā)現(xiàn) 和 故障自動(dòng)轉(zhuǎn)移。

Redis 從 3.0版本 正式提供了 分布式 實(shí)現(xiàn) Redis Cluster，它是 Redis 真正的 分布式實(shí)現(xiàn)，提供了 高可用、讀寫 和 容量的擴(kuò)展性。

緩存

緩存機(jī)制 幾乎在所有的大型網(wǎng)站 都有使用，合理地使用緩存 不僅可以 加快數(shù)據(jù)的訪問速度，而且能夠 有效地降低后端數(shù)據(jù)源的壓力。

Redis 提供了 鍵值過期時(shí)間設(shè)置，并且也提供了 靈活控制最大內(nèi)存 和 內(nèi)存溢出后的淘汰策略。

可以這么說，一個(gè) 合理的緩存設(shè)計(jì) 能夠?yàn)?一個(gè)網(wǎng)站的穩(wěn)定 保駕護(hù)航。第11章將對(duì) 緩存的設(shè)計(jì)與使用 進(jìn)行詳細(xì)說明。

排行榜系統(tǒng)

排行榜系統(tǒng) 幾乎存在于所有的網(wǎng)站，例如 按照熱度排名的排行榜，按照發(fā)布時(shí)間的排行榜，按照各種復(fù)雜維度計(jì)算出的排行榜，Redis 提供了 列表 和 有序集合 數(shù)據(jù)結(jié)構(gòu)，合理地使用 這些 數(shù)據(jù)結(jié)構(gòu) 可以很 方便地構(gòu)建各種排行榜系統(tǒng)。

計(jì)數(shù)器應(yīng)用

計(jì)數(shù)器 在網(wǎng)站中的作用 至關(guān)重要，例如 視頻網(wǎng)站有 播放數(shù)、電商網(wǎng)站有 瀏覽數(shù)，為了保證 數(shù)據(jù)的實(shí)時(shí)性，每一次 播放和瀏覽 都要做 加1 的操作，如果 并發(fā)量很大 對(duì)于 傳統(tǒng)關(guān)系型數(shù)據(jù)庫的性能 是一種挑戰(zhàn)。

Redis 天然支持 計(jì)數(shù)功能 而且 計(jì)數(shù)的性能 也非常好，可以說是 計(jì)數(shù)器系統(tǒng) 的重要選擇。

社交網(wǎng)絡(luò)

贊/踩、粉絲、共同好友/喜好、推送、下拉刷新等是 社交網(wǎng)站的必備功能，由于社交網(wǎng)站 訪問量通常比較大，而且 傳統(tǒng)的關(guān)系型數(shù)據(jù)庫 不太適合保存這種類型的數(shù)據(jù)，Redis 提供的 數(shù)據(jù)結(jié)構(gòu) 可以相對(duì)比較容易地實(shí)現(xiàn)這些功能。

消息隊(duì)列系統(tǒng)

消息隊(duì)列系統(tǒng) 可以說是 一個(gè)大型網(wǎng)站的必備基礎(chǔ)組件，因?yàn)槠渚哂?業(yè)務(wù) 解耦、非實(shí)時(shí)業(yè)務(wù) 削峰等特性。

Redis 提供了 發(fā)布訂閱 和 阻塞隊(duì)列 的功能，雖然和專業(yè)的消息隊(duì)列比還不夠足夠強(qiáng)大，但是對(duì)于一般的消息隊(duì)列基本可以滿足。

切勿當(dāng)做 黑盒 使用，開發(fā)與運(yùn)維同樣重要

很多使用 Redis 的開發(fā)者認(rèn)為只要會(huì)用 API 開發(fā)相應(yīng)的功能就可以，更有甚者認(rèn)為 Redis 就是 get、set、del，不需要知道 Redis 的 原理。

但是在我們實(shí)際運(yùn)維和使用 Redis 的過程中發(fā)現(xiàn)，很多線上的故障和問題都是由于完全把 Redis 當(dāng)做 黑盒 造成的，

如果不了解 Redis的單線程模型，有些開發(fā)者會(huì)在 上千萬個(gè)鍵的Redis上 執(zhí)行 keys * 操作，

如果不了解 持久化的相關(guān)原理，會(huì)在一個(gè) 寫操作量很大的Redis上 配置自動(dòng)保存RDB。

而且在很多公司內(nèi)只有專職的 關(guān)系型數(shù)據(jù)庫DBA，并沒有 NoSQL 的相關(guān)運(yùn)維人員，也就是說開發(fā)者很有可能會(huì)自己運(yùn)維 Redis，對(duì)于 Redis 的開發(fā)者來說既是好事又是壞事。

站在好的方面看，開發(fā)人員可以通過 運(yùn)維 Redis 真正了解 Redis 的一些原理，不單純停留在開發(fā)上。

站在壞的方面看，Redis 的開發(fā)人員不僅要支持開發(fā)，還要承擔(dān)運(yùn)維的責(zé)任，而且由于運(yùn)維經(jīng)驗(yàn)不足可能會(huì)造成線上故障。

但是從實(shí)際經(jīng)驗(yàn)來看，運(yùn)維足夠規(guī)模的 Redis 會(huì)對(duì)用好 Redis 更加有幫助。

閱讀源碼

我們在前面提到過，Redis 是 開源項(xiàng)目，由于作者對(duì) Redis代碼 的極致追求，Redis的代碼量 相對(duì)于許多 NoSQL數(shù)據(jù)庫 來說是非常 小 的，也就意味著作為普通的開發(fā)和運(yùn)維人員也是可以 “吃透”的。

通過閱讀優(yōu)秀的源碼，不僅能夠加深我們對(duì) Redis 的理解，而且還能提高自身的需求，例如新浪微博在 Redis的早期版本 上做了很多的 定制化 來滿足自身的需求，豌豆莢也開源基于 Proxy 的 Redis 分布式 實(shí)現(xiàn) Codis。

在Linux上安裝Redis

Redis 能夠 兼容 絕大部分的 POSIX 系統(tǒng)，例如 Linux、OS X、OpenBSD、NetBSD 和 FreeBSD，

其中比較典型的是 Linux 操作系統(tǒng)（例如 CentOS、Redhat、Ubuntu、Debian、OS X等）。

在 Linux 安裝軟件通常有 兩種方法，

第一種是通過 各個(gè)操作系統(tǒng)的軟件管理軟件 進(jìn)行安裝，例如 CentOS 有 yum 管理工具，Ubuntu 有 apt。

但是由于 Redis 的更新速度相對(duì)較快，而這些管理工具不一定能更新到最新的版本，同時(shí)前面提到 Redis的安裝 本身不是很復(fù)雜，所以一般推薦使用第二種方式：源碼的方式 進(jìn)行安裝，整個(gè)安裝只需一下 六步 即可完成，以 3.0.7 版本 為例：

下載 Redis 指定版本的 源碼壓縮包 到當(dāng)前目錄。

解壓縮 Redis 源碼壓縮包。

建立一個(gè) redis 目錄 的軟連接，指向 redis-3.0.7

進(jìn)入 redis 目錄

編譯（編譯之前確保操作系統(tǒng)已經(jīng)安裝 gcc）

安裝

啟動(dòng) Redis

有 三種方法 啟動(dòng)Redis：默認(rèn)配置、運(yùn)行配置、配置文件啟動(dòng)。

（1）默認(rèn)配置

這種方法會(huì)使用 Redis的默認(rèn)配置 來啟動(dòng)，下面就是 redis-server 執(zhí)行后輸出的相關(guān)日志。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-bRAOIMuK-1621301836858)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210514142427083.png)]

可以看到直接使用 redis-server 啟動(dòng) Redis 后，會(huì)打印一些日志，通過日志可以看到一些信息，上例中可以看到：

• 當(dāng)前的 Redis版本 是 3.0.7。
• Redis 的 默認(rèn)端口 是 6379。
• Redis 建議要 使用配置文件 來啟動(dòng)。

因?yàn)?直接啟動(dòng) 無法自定義配置，所以這種方式是不會(huì)在生產(chǎn)環(huán)境中使用的。

（2）運(yùn)行啟動(dòng)

redis-server 加上 要修改配置名和值（可以是多對(duì)），沒有設(shè)置的配置將使用默認(rèn)配置：

例如，如果要用 6380 作為 端口 啟動(dòng) Redis，那么可以執(zhí)行：

雖然 運(yùn)行配置 可以 自定義配置，但是如果 需要修改的配置較多 或者 希望將配置保存到文件中，不建議使用這種方式。

（3）配置文件啟動(dòng)

將 配置 寫到 指定文件 里，例如我們將配置寫到了 /opt/redis/redis.conf 中，那么只需要執(zhí)行如下命令即可啟動(dòng) Redis：

Redis 有 60 多個(gè)配置，這里只給出一些重要的配置（參見表 1-3），其他配置會(huì)隨著不斷深入學(xué)習(xí)進(jìn)行介紹，第14章會(huì)將所有的配置說明進(jìn)行匯總。

表 1-3 Redis的基礎(chǔ)配置

運(yùn)維提示

Redis 目錄下都會(huì)有一個(gè) redis.conf 配置文件，里面就是 Redis的 默認(rèn)配置，通常來講我們會(huì)在 一臺(tái)機(jī)器上啟動(dòng)多個(gè)Redis，并且將 配置集中管理在指定目錄下，而且 配置不是完全手寫的，而是將 redis.conf 作為模板進(jìn)行修改。

顯然通過 配置文件啟動(dòng)的方式 提供了 更大的靈活性，所以大部分生產(chǎn)環(huán)境會(huì)使用這種方式啟動(dòng)Redis。

Redis 命令行客戶端

現(xiàn)在我們已經(jīng)啟動(dòng)了 Redis 服務(wù)，下面將介紹如何使用 redis-cli 連接，操作 Redis 服務(wù)。

redis-cli 可以使用 兩種方式 連接Redis服務(wù)器。

• 第一種是 交互式方式

  通過 redis-cli -h {host} -p {port}的方式連接到 Redis服務(wù)，之后所有的操作都是通過 交互的方式 實(shí)現(xiàn)，不需要再執(zhí)行 redis-cli 了，例如：

  redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> set hello world OK 127.0.0.1:6379> get hello "world"

• 第二種是 命令方式

  用 redis-cli -h ip {host} -p {port} {command}就可以直接得到 命令的返回結(jié)果，例如：

  redis-cli -h 127.0.0.1 -p 6379 get hello "world"

  這里有 兩點(diǎn) 要注意：

  1）如果沒有 -h 參數(shù)，那么 默認(rèn)連接 127.0.0.1 ；

  ? 如果沒有 -p ，那么 默認(rèn) 6379 端口，也就是說如果 -h 和 -p 都沒寫就是連接 127.0.0.1:6379 這個(gè)Redis實(shí)例。

  2）redis-cli 是學(xué)習(xí) Redis 的重要工具，后面的很多章節(jié)都是用它作講解，同時(shí) redis-cli 還提供了很多有價(jià)值的參數(shù)，可以幫助解決很多問題，有關(guān)于 redis-cli 的強(qiáng)大功能將在第3章進(jìn)行詳細(xì)介紹。

停止 Redis 服務(wù)

Redis 提供了 shutdown 命令來 停止Redis服務(wù)，例如要停掉 127.0.0.1 上 6379 端口上的 Redis 服務(wù)，可以執(zhí)行如下操作：

可以看到 Redis 的日志輸出如下：

當(dāng)使用 redis-cli 再次連接該 Redis 服務(wù)時(shí)，看到 Redis 已經(jīng) “失聯(lián)”。

這里有 三點(diǎn) 需要注意一下：

1）Redis 關(guān)閉的過程：斷開與客戶端的連接、持久化文件生成，是一種相對(duì)優(yōu)雅的關(guān)閉方式。

2）除了可以通過 shutdown 命令 關(guān)閉Redis服務(wù) 以外，還可以通過 kill 進(jìn)程號(hào) 的方式關(guān)閉掉 Redis，但是不要 粗暴地 使用 kill -9 強(qiáng)制殺死 Redis服務(wù)，不但 不會(huì)做 持久化操作，還會(huì) 造成 緩沖區(qū)等資源不能被優(yōu)雅關(guān)閉，極端情況會(huì)造成 AOF和復(fù)制丟失數(shù)據(jù) 的情況。

3）shutdown 還有一個(gè)參數(shù)，代表 是否在關(guān)閉Redis前，生成持久化文件：

Redis 2.6

Redis 2.6 在 2012 年正式發(fā)布，經(jīng)歷了 17 個(gè)版本，到 2.6.17 版本，相比于 Redis 2.4，主要特性如下：

1）服務(wù)端 支持 Lua 腳本。

2）去掉 虛擬內(nèi)存 相關(guān)功能。

3）放開對(duì) 客戶端連接數(shù) 的硬編碼限制。

4）鍵 的 過期時(shí)間 支持毫秒。

5）從結(jié)點(diǎn) 提供 只讀功能。

6）兩個(gè)新的 位圖命令：bitcount 和 bitop 。

7）增強(qiáng)了 redis-benchmark 的功能：支持 定制化的壓測，CSV輸出 等功能。

8）基于 浮點(diǎn)數(shù) 自增命令：incrbyfloat 和 hincrbyfloat。

9）redis-cli 可以使用 --eval 參數(shù)實(shí)現(xiàn) Lua腳本執(zhí)行。

10）shutdown 命令增強(qiáng)。

11）info 可以按照 section 輸出，并且添加了一些統(tǒng)計(jì)項(xiàng)。

12）重構(gòu)了大量的核心代碼，所有 集群相關(guān)的代碼 都去掉了，cluster 功能 將會(huì)是 3.0版本 最大的亮點(diǎn)。

13）sort 命令優(yōu)化。

Redis 2.8

Redis 2.8 在 2013 年 11 月 22 日正式發(fā)布，經(jīng)歷了 24 個(gè)版本，到 2.8.24 版本，相比于 Redis 2.6，主要特性如下：

1）添加部分 主從復(fù)制 的功能，在一定程度上 降低了 由于 網(wǎng)絡(luò)問題，造成頻繁 全量復(fù)制生成RDB 對(duì)系統(tǒng)造成的壓力。

2）嘗試性地支持 IPv6。

3）可以通過 config set 命令設(shè)置 maxclients。

4）可以用 bind 命令 綁定 多個(gè) IP地址。

5）Redis 設(shè)置 了明顯的 進(jìn)程名，方便使用 ps 命令 查看系統(tǒng)進(jìn)程。

6）config rewrite 命令可以將 config set 持久化到 Redis配置文件 中。

7）發(fā)布訂閱 添加了 pubsub 命令。

8）Redis Sentinel 第二版，相比于 Redis 2.6 的 Redis Sentinel，此版本已經(jīng)變成 生產(chǎn)可用。

Redis 3.0

Redis 3.0 在 2015 年 4 月 1 日 正式發(fā)布，截止到本書完成已經(jīng)到 3.0.7 版本，相比于 Redis 2.8 主要特性如下：

Redis 3.0 最大的改動(dòng)就是添加 Redis的分布式 實(shí)現(xiàn) Redis Cluster，填補(bǔ)了 Redis 官方?jīng)]有 分布式 實(shí)現(xiàn)的空白。

Redis Cluster 經(jīng)歷了 4 年才正式發(fā)布也是有原因的，具體可以參考 Redis Cluster 的開發(fā)日志（http://antirez.com/news/79）。

1）Redis Cluster：Redis 的 官方 分布式實(shí)現(xiàn)。

2）全新的 embedded string 對(duì)象編碼結(jié)果，優(yōu)化 小對(duì)象 內(nèi)存訪問，在特定的工作負(fù)載下 速度大幅提升。

3）lur 算法大幅提升。

4）migrate 連接緩存，大幅提升 鍵遷移的速度。

5）migrate 命令 兩個(gè)新的參數(shù) copy 和 replace。

6）新的 client pause 命令，在指定時(shí)間內(nèi)停止處理客戶端請(qǐng)求。

7）bitcount 命令性能提升。

8）config set 設(shè)置 maxmemory 時(shí)候可以 設(shè)置不同的單位（之前只能是字節(jié)），例如 config set maxmemory 1gb。

9）Redis 日志小做調(diào)整：日志中會(huì)反應(yīng) 當(dāng)前實(shí)例的角色（master 或者 slave）。

10）incr 命令 性能提升。

Redis 3.2

Redis 3.2 在 2016 年 5 月 6 日正式發(fā)布，相比于 Redis 3.0 主要特征如下：

1）添加 GEO 相關(guān)功能。

2）SDS 在 速度 和 節(jié)省空間 上都做了優(yōu)化。

3）支持用 upstart 或者 systemd 管理 Redis 進(jìn)程。

4）新的 List 編碼類型：quicklist。

5）從結(jié)點(diǎn) 讀取 過期數(shù)據(jù) 保證一致性。

6）添加了 hstrlen 命令。

7）增強(qiáng)了 debug 命令，支持了更多的參數(shù)。

8）Lua 腳本功能增強(qiáng)。

9）添加了 Lua Debugger。

10）config set 支持更多的配置參數(shù)。

11）優(yōu)化了 Redis 崩潰 后的相關(guān)報(bào)告。

12）新的 RDB 格式，但是仍然兼容舊的 RDB。

13）加速 RDB 的加載速度。

14）spop 命令支持 個(gè)數(shù) 參數(shù)。

15）cluster nodes 命令得到 加速。

16）Jemalloc 更新到 4.0.3 版本。

Redis 4.0

可能出乎很多人的意料，Redis 3.2 之后的版本是 4.0，而不是 3.4、3.6、3.8。

一般這種 重大版本號(hào) 的 升級(jí) 也意味著 軟件或者工具本身發(fā)生了重大變革，直到本書截稿前，Redis 發(fā)布了 4.0-RC2，下面列出 Redis 4.0 的新特性：

1）提供了 模塊系統(tǒng)，方便第三方開發(fā)者 拓展 Redis 的功能，更多模塊詳見：http://redismodules.com。

2）PSYNC 2.0：優(yōu)化了之前版本中，主從節(jié)點(diǎn)切換 必然引起 全量復(fù)制 的問題。

3）提供了新的 緩存剔除 算法：LFU（Last Frequently Used），并對(duì)已有算法進(jìn)行了優(yōu)化。

4）提供了 非阻塞 del 和 flushall/flushdb 功能，有效解決 刪除 bigkey 可能造成的 Redis 阻塞。

5）提供了 RDB-AOF 混合持久式 格式，充分利用了 AOF 和 RDB 各自優(yōu)勢。

6）提供 memory 命令，實(shí)現(xiàn) 對(duì)內(nèi)存更為全面的監(jiān)控統(tǒng)計(jì)。

7）提供了 交互數(shù)據(jù)庫 功能，實(shí)現(xiàn) Redis 內(nèi)部數(shù)據(jù)庫之間的 數(shù)據(jù)置換。

8）Redis Cluster 兼容 NAT 和 Docker。

查看所有鍵

keys *

下面插入了 3對(duì) 字符串類型的鍵值對(duì)：

keys * 命令會(huì) 將所有的鍵輸出：

鍵總數(shù)

dbsize

下面插入一個(gè) 列表類型的鍵值對(duì)（值 是多個(gè)元素組成）

dbsize 命令會(huì)返回 當(dāng)前數(shù)據(jù)庫中鍵的總數(shù)。

例如 當(dāng)前數(shù)據(jù)庫有 4 個(gè)鍵，分別是 hello、java、python、mylist，所以 dbsize 的結(jié)果是 4：

dbsize 命令在 計(jì)算鍵總數(shù) 時(shí) 不會(huì)遍歷所有鍵，而是 直接獲取 Redis 內(nèi)置的 鍵總數(shù) 變量，所以 dbsize 命令的 時(shí)間復(fù)雜度 是 O(1)。

而 keys 命令會(huì) 遍歷所有鍵，所以它的 時(shí)間復(fù)雜度 是 O(n)，當(dāng) Redis 保存了 大量鍵時(shí)，線上環(huán)境 禁止使用。

檢查鍵是否存在

exists key

如果 鍵存在 則返回1，不存在則返回0。

刪除鍵

del key [key ...]

del 是一個(gè)通用命令，無論值是什么數(shù)據(jù)結(jié)構(gòu)類型，del 命令 都可以將其刪除，例如下面將 字符串類型的鍵 java 和 列表類型的鍵 mylist 分別刪除：

返回結(jié)果為 成功刪除鍵的個(gè)數(shù)，假設(shè)刪除一個(gè)不存在的鍵，就會(huì)返回0：

同時(shí) del 命令可以支持 刪除多個(gè)鍵：

鍵過期

expire key seconds

Redis 支持對(duì) 鍵 添加過期時(shí)間，當(dāng)超過 過期時(shí)間 后，會(huì)自動(dòng)刪除 鍵，例如為 鍵 hello 設(shè)置了 10秒過期時(shí)間：

ttl 命令會(huì)返回 鍵的剩余過期時(shí)間，它有 3種返回值：

• 大于等于0 的整數(shù)：鍵剩余的過期時(shí)間。
• -1：鍵沒設(shè)置過期時(shí)間。
• -2：鍵不存在。

可以通過 ttl 命令觀察鍵 hello 的剩余過期時(shí)間：

有關(guān) 鍵過期 更為詳細(xì)的使用以及原理會(huì)在 2.7 節(jié)介紹。

引出單線程模型

現(xiàn)在開啟了 三個(gè) redis-cli 客戶端 同時(shí)執(zhí)行命令、

客戶端1 設(shè)置一個(gè) 字符串鍵值對(duì)：

客戶端2 對(duì) counter 做自增操作：

客戶端3 對(duì) counter 做自增操作：

Redis 客戶端 與 服務(wù)端 的模型可以簡化成 圖2-3，每次 客戶端調(diào)用都經(jīng)歷了 發(fā)送命令、執(zhí)行命令、返回結(jié)果 三個(gè)過程。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-oAqoELf9-1621301836863)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210517124231618.png)]

其中 第2步 是重點(diǎn)要討論的，因?yàn)?Redis 是 單線程 來處理命令的，所以 一條命令從客戶端 到達(dá) 服務(wù)端 不會(huì)立刻被執(zhí)行，所有命令都會(huì)進(jìn)入一個(gè) 隊(duì)列 中，然后 逐個(gè)被執(zhí)行。

所以上面 3個(gè)客戶端 命令的執(zhí)行順序是不確定的（如圖2-4所示），但是可以確定 不會(huì)有兩條命令被同時(shí)執(zhí)行（如圖2-5所示），所以 incr 命令無論怎么執(zhí)行最終結(jié)果都是 2，不會(huì)產(chǎn)生并發(fā)問題，這就是 Redis 單線程的基本模型。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-4uukxun5-1621301836864)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210517124353808.png)]

但是像 發(fā)送命令、返回結(jié)果、命令排隊(duì) 肯定不像描述的這么簡單，Redis 使用了 I/O多路復(fù)用技術(shù) 來解決 I/O 的問題，下一節(jié)將進(jìn)行介紹。

為什么單線程還能這么快

通常來講，單線程處理能力 要比 多線程 差，

例如有 10 000 斤貨物，每輛車的運(yùn)載能力是每次 200斤，那么要50次才能完成，

但是如果有 50輛車，只要安排合理，只需一次就可以完成任務(wù)。

那么為什么 Redis 使用 單線程模型 會(huì)達(dá)到每秒萬級(jí)別的處理能力 呢？

可以將其歸結(jié)為三點(diǎn)：

第一，純內(nèi)存訪問，Redis 將 所有數(shù)據(jù)放在 內(nèi)存 中，內(nèi)存 的 響應(yīng)時(shí)長 大約為 100納秒，這是 Redis 達(dá)到每秒 萬級(jí)別 訪問的重要基礎(chǔ)。

第二，非阻塞I/O，Redis 使用 epoll 作為 I/O 多路復(fù)用技術(shù) 的 實(shí)現(xiàn)，再加上 Redis 自身的 事件處理模型 將 epoll 中的 連接、讀寫、關(guān)閉 都轉(zhuǎn)換為 事件，不在 網(wǎng)絡(luò) I/O 上浪費(fèi)過多的時(shí)間，如圖 2-6 所示：

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-8LbJKfu9-1621301836865)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210517124935714.png)]

第三，單線程 避免了 線程切換 和 競態(tài)產(chǎn)生 的消耗。

既然采用 單線程 就能達(dá)到如此高的性能，那么也不失為一種不錯(cuò)的選擇，

因此單線程能帶來幾個(gè)好處：

? 第一，單線程 可以 簡化 數(shù)據(jù)結(jié)構(gòu)和算法 的實(shí)現(xiàn)。如果對(duì)高級(jí)編程語言熟悉的讀者應(yīng)該了解 并發(fā)數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn) 不但困難 而且 開發(fā)測試比較麻煩。

? 第二，單線程 避免了 線程切換 和 競態(tài)產(chǎn)生 的消耗，對(duì)于 服務(wù)端開發(fā) 來說，鎖 和 線程切換 通常是 性能殺手。

但是 單線程 會(huì)有一個(gè)問題：對(duì)于 每個(gè)命令的執(zhí)行時(shí)間 是有要求的。如果某個(gè)命令 執(zhí)行過長，會(huì)造成 其他命令的 阻塞，對(duì)于 Redis 這種 高性能的服務(wù) 來說是致命的，所以 Redis 是面向 快速執(zhí)行 場景的數(shù)據(jù)庫。

單線程機(jī)制 很容易被初學(xué)者忽視，但筆者認(rèn)為 Redis 單線程機(jī)制 是 開發(fā)和運(yùn)維人員 使用和理解 Redis 的核心之一，隨著后面的學(xué)習(xí)，相信讀者會(huì)逐步理解。

常用命令

（1）設(shè)置值

下面操作 設(shè)置鍵為hello，值為world的鍵值對(duì)，返回結(jié)果為 OK 代表設(shè)置成功：

set 命令 有幾個(gè)選項(xiàng)：

• ex seconds ：為 鍵 設(shè)置 秒級(jí) 過期時(shí)間。
• px milliseconds：為 鍵 設(shè)置 毫秒級(jí) 過期時(shí)間。
• nx：鍵 必須不存在，才可以設(shè)置成功，用于添加。
• xx：與 nx 相反，鍵必須存在，才可以設(shè)置成功，用于更新。

除了 set 選項(xiàng)，Redis 還提供了 setex 和 setnx 兩個(gè)命令：

它們的作用和 ex 和 nx 選項(xiàng)是一樣的。

下面的例子說明了 set、setnx、set xx 的區(qū)別。

當(dāng)前 鍵 hello 不存在：

設(shè)置 鍵為hello， 值為world 的鍵值對(duì)：

因?yàn)殒I hello 已存在，所以 setnx 失敗，返回結(jié)果為 0：

因?yàn)殒I hello 已存在，所以 set xx 成功，返回結(jié)果為 OK。

setnx 和 setxx 在實(shí)際使用中有什么應(yīng)用場景嗎？

以 setnx 命令為例子，由于 Redis 的 單線程命令處理機(jī)制，如果有 多個(gè)客戶端 同時(shí)執(zhí)行 setnx key value，根據(jù) setnx 的特性 只有一個(gè)客戶端能設(shè)置成功，setnx 可以作為 分布式鎖 的一種實(shí)現(xiàn)方案，Redis 官方給出了使用 setnx 實(shí)現(xiàn)分布式鎖 的方法：http://redis.io/topics/distlock。

（2）獲取值

下面操作 獲取鍵hello的值：

如果 要獲取的鍵 不存在，則返回 nil（空）：

（3）批量設(shè)置值

下面操作通過 mset 命令一次性設(shè)置 4個(gè)鍵值對(duì)：

（4）批量獲取值

下面操作批量獲取了鍵 a、b、c、d的值：

如果有些 鍵 不存在，那么它的值 為 nil（空），結(jié)果是按照 傳入鍵 的順序 返回：

批量操作 命令 可以 有效提高開發(fā)效率，假如沒有 mget 這樣的命令，要執(zhí)行 n 次 get 命令 需要按照?qǐng)D 2-8 的方式來執(zhí)行，具體耗時(shí)如下：

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-tpk8mJqK-1621301836867)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210517133127643.png)]

使用 mget 命令后，要執(zhí)行 n 次 get 命令操作 只需要按照?qǐng)D 2-9 的方式來完成，具體耗時(shí)如下：

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-KrQD9scU-1621301836868)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210517133254794.png)]

Redis 可以支撐 每秒數(shù)萬 的讀寫操作，但是這指的是 Redis 服務(wù)端的處理能力，

對(duì)于客戶端來說，一次命令除了 命令時(shí)間 還有 網(wǎng)絡(luò)時(shí)間，假設(shè) 網(wǎng)絡(luò)時(shí)間為 1 毫秒，命令時(shí)間為 0.1 毫秒（按照每秒處理 1 萬條命令算），那么執(zhí)行 1000次 get 命令 和 1次 mget 命令的區(qū)別 如表 2-1，因?yàn)?Redis 的處理能力已經(jīng)足夠高，對(duì)于開發(fā)人員來說，網(wǎng)絡(luò) 可能會(huì)成為 性能 的瓶頸。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-7z4vsnzX-1621301836869)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210517133726771.png)]

學(xué)會(huì)使用 批量操作，有助于 提高業(yè)務(wù)處理效率，但是要注意的是 每次批量操作 所發(fā)送的命令數(shù) 不是無節(jié)制的，如果數(shù)量過多 可能造成 Redis 阻塞 或者 網(wǎng)絡(luò)擁塞。

（5）計(jì)數(shù)

incr 命令用于對(duì)值 做自增操作，返回結(jié)果分為三種情況：

• 值不是整數(shù)，返回錯(cuò)誤。
• 值是整數(shù)，返回自增后的結(jié)果。
• 鍵不存在，按照值為0 自增，返回結(jié)果為1。

例如對(duì)一個(gè) 不存在的鍵 執(zhí)行 incr 操作后，返回結(jié)果是1：

再次對(duì)鍵 執(zhí)行 incr 命令，返回結(jié)果是 2：

如果值 不是整數(shù)，那么會(huì) 返回錯(cuò)誤。

除了 incr 命令，Redis 提供了 decr（自減）、incrby（自增指定數(shù)字）、decrby（自減指定數(shù)字）、incrbyfloat（自增浮點(diǎn)數(shù)）：

很多 存儲(chǔ)系統(tǒng)和編程語言內(nèi)部 使用 CAS機(jī)制實(shí)現(xiàn)計(jì)數(shù)功能，會(huì)有一定的CPU開銷，但在 Redis 中完全不存在這個(gè)問題，因?yàn)?Redis 是單線程架構(gòu)，任何命令到了 Redis 服務(wù)端 都要 順序執(zhí)行。

不常用命令

（1）追加值

append 可以向 字符串尾部 追加值，例如：

（2）字符串長度

例如，當(dāng)前值為 redisworld，所以返回值為10：

下面操作返回結(jié)果為 6，因?yàn)?每個(gè)中文占用 3個(gè)字節(jié)：

（3）設(shè)置并返回原值

getset 和 set 一樣會(huì) 設(shè)置值，但是不同的是，它同時(shí)會(huì) 返回鍵原來的值，例如：

（4）設(shè)置 指定位置 的 字符

下面操作將由 pest 變?yōu)榱?best：

（5）獲取 部分字符串

start 和 end 分別是 開始 和 結(jié)束的 偏移量（[start, end]），偏移量 從 0 開始計(jì)算，例如下面操作獲取了 值 best 的 前兩個(gè)字符。

表 2-2 是 字符串類型命令的 時(shí)間復(fù)雜度，開發(fā)人員可以參考此表，結(jié)合自身業(yè)務(wù)需求 和 數(shù)據(jù)大小 選擇合適的命令。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-bA8PTUZ3-1621301836874)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210517141143590.png)]

緩存功能

圖 2-10 是比較典型的 緩存使用場景，其中 Redis 作為 緩存層，MySQL 作為 存儲(chǔ)層，絕大部分請(qǐng)求的數(shù)據(jù)都是從 Redis 中獲取。

由于 Redis 具有支撐 高并發(fā) 的特性，所以 緩存 通常能起到 加速讀寫 和 降低后端壓力 的作用。

下面?zhèn)未a模擬了 圖 2-10 的訪問過程：

1） 該函數(shù)用于 獲取用戶的基礎(chǔ)信息：

2）首先從 Redis 獲取用戶信息：

開發(fā)提示

與 MySQL 等關(guān)系型數(shù)據(jù)庫不同的是，Redis 沒有 命令空間，而且也沒有對(duì) 鍵名 有強(qiáng)制要求（除了 不能使用一些特殊字符）。

但 設(shè)計(jì)合理的鍵名，有利于 防止鍵沖突 和 項(xiàng)目的可維護(hù)性，比較推薦的方式是使用 “業(yè)務(wù)名 : 對(duì)象名 : id : [ 屬性 ]” 作為 鍵名（也可以不是分號(hào)）。

例如 MySQL 的 數(shù)據(jù)庫名為 vs，用戶表名為 user，那么對(duì)應(yīng)的鍵可以用 “vs:user:1”，“vs:user:1:name"來表示，例如"user : {uid} : friends : messages : {mid}”，可以在 能描述鍵含義的前提下 適當(dāng)減少鍵的長度，例如變?yōu)?“u : {uid} : fr : m : {mid}”，從而 減少由于 鍵過長的內(nèi)存浪費(fèi)。

3）如果沒有從 Redis 獲取到用戶信息，需要從 MySQL 中進(jìn)行獲取，并將結(jié)果回寫到 Redis，添加 1小時(shí)（3600秒）過期時(shí)間：

整個(gè)功能的偽代碼如下：

計(jì)數(shù)

許多應(yīng)用都會(huì)使用 Redis 作為計(jì)數(shù)的 基礎(chǔ)工具，它可以實(shí)現(xiàn) 快速計(jì)數(shù)、查詢緩存的功能，同時(shí) 數(shù)據(jù) 可以 異步落地 到 其他數(shù)據(jù)源。

例如筆者所在團(tuán)隊(duì)的 視頻播放數(shù)系統(tǒng) 就是使用 Redis 作為視頻播放數(shù) 計(jì)數(shù)的基礎(chǔ)組件，用戶每播放一次視頻，相應(yīng)的視頻播放數(shù) 就會(huì) 自增1。

開發(fā)提示

實(shí)際上一個(gè)真實(shí)的 計(jì)數(shù)系統(tǒng) 要考慮的問題會(huì)很多：防作弊、按照不同維度計(jì)數(shù)，數(shù)據(jù)持久化到底層數(shù)據(jù)源等。

共享Session

如圖 2-11 所示，一個(gè) 分布式 Web 服務(wù) 將用戶的 Session信息 （例如用戶登錄信息）保存在各自服務(wù)器中，這樣會(huì)造成一個(gè)問題，出于負(fù)載均衡的考慮，分布式服務(wù) 會(huì)將 用戶的訪問 均衡到不同服務(wù)器上，用戶刷新一次訪問 可能會(huì)發(fā)現(xiàn) 需要重新登錄，這個(gè)問題是 用戶無法容忍的。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-cRZQHxM6-1621301836877)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210517150020342.png)]

為了解決這個(gè)問題，可以使用 Redis 將用戶的Session進(jìn)行集中管理，如圖 2-12 所示，在這種模式下 只要保證 Redis是 高可用 和 擴(kuò)展性 的，每次用戶更新或者查詢登錄信息 都是直接從 Redis 中集中獲取。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-jG7RsGBG-1621301836878)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210517150425297.png)]

限速

很多應(yīng)用處于安全的考慮，會(huì)在每次進(jìn)行登錄時(shí)，讓用戶輸入手機(jī)驗(yàn)證碼，從而確定是否是用戶本人。

但是為了 短信接口 不被頻繁訪問，會(huì)限制 用戶每分鐘獲取驗(yàn)證碼的頻率，例如一分鐘不能超過 5次，如圖 2-13 所示。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-ZEaLrmw9-1621301836879)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210517150617130.png)]

此功能可以使用 Redis 來實(shí)現(xiàn)，下面的偽代碼給出了基本實(shí)現(xiàn)思路：

上述就是利用 Redis 實(shí)現(xiàn)了 限速功能，例如一些網(wǎng)站限制一個(gè) IP地址 不能在一秒鐘之內(nèi)訪問超過 n次 也可以采用類似的思路。

除了上面介紹的幾種使用場景，字符串還有非常多的使用場景，開發(fā)人員可以結(jié)合字符串提供的相應(yīng)命令充分發(fā)揮自己的想象力。

添加操作

（1）從右邊插入元素

下面代碼 從右向左 插入元素 c、b、a：

lrange 0 -1 命令可以獲取 從左到右 獲取列表的所有元素：

（2）從左邊插入元素

使用方法和 rpush 相同，只不過從左側(cè)插入，這里不再贅述。

（3）向 某個(gè)元素 前 或者 后 插入元素

linsert 命令會(huì)從 列表 中 找到等于 pivot 的元素，在其 前（before） 或者 后（after） 插入一個(gè)新的元素 value，例如下面操作會(huì)在列表的元素 b 前 插入 java：

返回結(jié)果為 4，代表 當(dāng)前列表的長度，當(dāng)前列表變?yōu)?#xff1a;

查找

（1） 獲取 指定范圍內(nèi)的元素列表

lrange 操作會(huì) 獲取列表 指定索引范圍 所有的元素。

索引下標(biāo) 有 兩個(gè)特點(diǎn)：

第一，索引下標(biāo) 從左到右 分別是 0 到 N-1，但是 從右到左 分別是 -1 到 -N。

第二，lrange 中的 end 選項(xiàng)包含了自身，這個(gè)和很多編程語言不包含 end 不太相同，例如想獲取 列表的第2到第4個(gè)元素，可以執(zhí)行如下操作：

（2）獲取 列表 指定索引下標(biāo) 的元素

例如 當(dāng)前列表 最后一個(gè)元素為a：

（3） 獲取列表長度

例如，下面示例 當(dāng)前列表長度為 4：

刪除

（1）從列表左側(cè) 彈出 元素

如下操作將 列表最左側(cè)的元素 c 會(huì)被彈出，彈出后列表變?yōu)?java、b、a：

（2）從列表右側(cè)彈出

它的使用方法和 lpop 是一樣的，只不過從 列表 右側(cè)彈出，這里不再贅述。

（3）刪除指定元素

lrem 命令會(huì)從 列表中找到等于 value 的元素進(jìn)行刪除，根據(jù) count 的不同 分為 三種情況：

• count > 0 ，從左到右，刪除最多 count 個(gè)元素。
• count < 0，從右到左，刪除最多 count 絕對(duì)值個(gè)元素。
• count = 0，刪除所有。

例如向 列表 從左向右 插入 5個(gè)a，那么當(dāng)前列表變?yōu)?“a a a a a java b a”，下面操作將從 列表左邊開始刪除4個(gè)為a 的元素：

（4）按照索引范圍 修剪 列表

例如，下面操作會(huì) 只保留 列表 listkey 第2個(gè)到第4個(gè)元素：

修改

修改指定索引下標(biāo)的元素：

下面操作會(huì)將 列表 listkey 中的 第3個(gè) 元素設(shè)置為 python：

阻塞操作

阻塞式彈出 如下：

blpop 和 brpop 是 lpop 和 rpop 的 阻塞版本，它們除了 彈出方向不同，使用方法基本相同，所以下面以 brpop 命令進(jìn)行說明，brpop 命令包含 兩個(gè)參數(shù)：

• key [key …]：多個(gè)列表的鍵。
• timeout：阻塞時(shí)間（單位：秒）

1）列表為空：

如果 timeout = 3，那么 客戶端 要等到 3 秒后返回，

如果 timeout = 0，那么 客戶端 一直阻塞等下去：

如果此期間添加了數(shù)據(jù) element1，客戶端立即返回：

2）列表不為空：客戶端會(huì)立即返回。

在使用 brpop 時(shí)，有 兩點(diǎn) 需要注意。

第一點(diǎn)，如果是 多個(gè)鍵，那么 brpop 會(huì) 從左至右 遍歷鍵，一旦有一個(gè)鍵 能彈出元素，客戶端立即返回：

此時(shí) 另一個(gè)客戶端 分別向 list:2 和 list:3 插入元素：

客戶端會(huì) 立即返回 list:2 中的element2 ，因?yàn)?list:2 最先有可以彈出的元素：

第二點(diǎn)，如果 多個(gè)客戶端 對(duì) 同一個(gè)鍵執(zhí)行 brpop，那么 最先執(zhí)行 brpop 命令的客戶端 可以獲取到 彈出的值。

客戶端1：

客戶端2：

客戶端3：

此時(shí)另一個(gè)客戶端 lpush 一個(gè)元素到 list:test 列表中：

那么 客戶端1 最先會(huì)獲取到元素，因?yàn)?客戶端1 最先執(zhí)行 brpop，而客戶端2 和 客戶端3繼續(xù)阻塞：

有關(guān) 列表 的 基礎(chǔ)命令 已經(jīng)介紹完了，表 2-5 是這些命令的時(shí)間復(fù)雜度，開發(fā)人員可以參考此表 選擇合適的命令。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-55GHVUyL-1621301872089)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210517214858071.png)]

消息隊(duì)列

如圖 2-21所示，Redis的 lpush+brpop 命令組合即可實(shí)現(xiàn) 阻塞隊(duì)列，生產(chǎn)者客戶端 使用 lpush 從列表左側(cè)插入元素，多個(gè)消費(fèi)者客戶端使用 brpop 命令阻塞式的 “搶” 列表尾部的元素，多個(gè)客戶端 保證了 消費(fèi)的負(fù)載均衡 和 高可用性。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-kzgBPzc3-1621301872090)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20210517222037844.png)]

文章列表

每個(gè)用戶有屬于自己的 文章列表，現(xiàn)需要 分頁展示 文章列表。

此時(shí)可以考慮使用 列表，因?yàn)?列表 不但是 有序的，同時(shí) 支持按照 索引范圍 獲取元素。

1）每篇文章使用 哈希結(jié)構(gòu) 存儲(chǔ)，例如每篇文章有 3個(gè)屬性 title、timestamp、content：

2）向 用戶文章列表 添加文章，user : {id} : articles 作為 用戶文章列表 的鍵：

3）分頁 獲取 用戶文章列表，例如下面?zhèn)未a獲取用戶 id=1 的前 10 篇文章：

使用 列表類型保存 和 獲取文章列表 會(huì)存在兩個(gè)問題。

第一，如果 每次分頁獲取的文章個(gè)數(shù)較多，需要執(zhí)行多次 hgetall 操作，此時(shí)可以考慮使用 Pipeline（第3章會(huì)介紹）批量獲取，或者考慮 將文章數(shù)據(jù)序列化為字符串，使用 mget 批量獲取。

第二，分頁獲取文章列表時(shí)，lrange 命令在列表兩端性能較好，但是如果 列表較大，獲取列表中間范圍的元素 性能會(huì)變差，此時(shí)可以考慮將 列表做二級(jí)拆分，或者使用 Redis 3.2 的quicklist 內(nèi)部編碼實(shí)現(xiàn)，它結(jié)合 ziplist 和 linkedlist 的特點(diǎn)，獲取 列表中間范圍的元素 時(shí)也可以高效完成。