導讀一.redis簡介Redis是一個速度非常快的非關系型數據庫（non-relationaldatabase）/NoSQL數據庫。Redis不使用表，也不會預....

一. redis 簡介

Redis 是一個速度非常快的非關系型數據庫（non-relational database）/ NoSQL 數據庫。

Redis 不使用表，也不會預定義或者強制去要求用戶對 Redis 存儲不同的數據進行關聯。

Redis 為什么速度非常快？

• 純內存操作：數據存在內存中，類似于 HashMap。HashMap 的優勢就是查找和操作的時間復雜度都是 O(1)
• 數據結構簡單：不僅數據結構簡單，而且對數據操作也簡單
• 單線程：避免了頻繁的上下文切換，也不存在多進程或者多線程導致的切換而消耗 CPU 資源，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的性能消耗

二. Redis 數據結構

Redis 存儲鍵（key）和 5 種不同類型的值（value）之間的映射。這 5 中類型分別為：

STRING（字符串）、LIST（列表）、HASH（散列）、SET（集合）和 ZSET（有序集合）。

1. STRING（字符串）

字符串示例，鍵為 hello，值為 world：

①. 字符串命令：

②. 使用

127.0.0.1:6379> set hello worldOK127.0.0.1:6379> get hello"world"127.0.0.1:6379> del hello(integer) 1127.0.0.1:6379> get hello(nil)

127.0.0.1:6379> set num 1OK127.0.0.1:6379> incr num(integer) 2127.0.0.1:6379> get num"2"

2. LIST（列表）

list-key 是一個包含 3 個元素的列表鍵，列表中的元素是可以重復的：

①. 列表命令

②. 使用

127.0.0.1:6379> rpush list-key item(integer) 1127.0.0.1:6379> rpush list-key item2(integer) 2127.0.0.1:6379> rpush list-key item(integer) 3 # 返回的列表長度

127.0.0.1:6379> lrange list-key 0 -11) "item"2) "item2"3) "item"# 使用 0 為范圍的開始索引，-1 為范圍索引的結束索引，可以去除列表包含的所有元素127.0.0.1:6379> lindex list-key 1"item2"

127.0.0.1:6379> lpop list-key"item"127.0.0.1:6379> lrange list-key 0 -11) "item2"2) "item"

3. HASH（散列）

hash-key 是一個包含兩個鍵值對的散列鍵：

①. 散列命令

②. 使用

127.0.0.1:6379> hset hash-key sub-key1 value1(integer) 1127.0.0.1:6379> hset hash-key sub-key2 value2(integer) 1127.0.0.1:6379> hset hash-key sub-key1 value2(integer) 0127.0.0.1:6379> hgetall hash-key1) "sub-key1"2) "value2"3) "sub-key2"4) "value2"

127.0.0.1:6379> hdel hash-key sub-key2(integer) 1127.0.0.1:6379> hdel hash-key sub-key2(integer) 0127.0.0.1:6379> hget hash-key sub-key1"value2"127.0.0.1:6379> hgetall hash-key1) "sub-key1"2) "value2"

4. SET（集合）

set-key 是一個包含 3 個元素的集合鍵：

①. 集合命令

②. 使用

127.0.0.1:6379> sadd set-key item(integer) 1127.0.0.1:6379> sadd set-key item2(integer) 1127.0.0.1:6379> sadd set-key item3(integer) 1127.0.0.1:6379> sadd set-key item(integer) 0127.0.0.1:6379> smembers set-key1) "item"2) "item3"3) "item2"

127.0.0.1:6379> sismember set-key item4(integer) 0127.0.0.1:6379> sismember set-key item(integer) 1

127.0.0.1:6379> srem set-key item(integer) 1127.0.0.1:6379> srem set-key item(integer) 0127.0.0.1:6379> smembers set-key1) "item3"2) "item2"

5. ZSET（有序集合）

zset-key 是已一個包含 2 個元素的有序集合鍵：

①. 有序集合命令：

②. 使用

127.0.0.1:6379> zadd zset-key 728 member1(integer) 1127.0.0.1:6379> zadd zset-key 982 member2(integer) 1127.0.0.1:6379> zadd zset-key 982 member2(integer) 0127.0.0.1:6379> zrange zset-key 0 -1 withscores1) "member1"2) "728"3) "member2"4) "982"

127.0.0.1:6379> zrangebyscore zset-key 0 800 withscores1) "member1"2) "728"

127.0.0.1:6379> zrem zset-key member1(integer) 1127.0.0.1:6379> zrem zset-key member1(integer) 0127.0.0.1:6379> zrange zset-key 0 -1 withscores1) "member2"2) "982"

三. Redis 與 Memcached

兩者都是非關系型內存鍵值數據庫，主要有以下不同：

1. 數據類型

• Redis 支持五種不同的數據類型，可以更靈活地解決問題
• Memcached 僅支持字符串類型

2. 數據持久化

• Redis 支持兩種持久化策略：RDB 快照和 AOF 日志
• Memcached 不支持持久化。

3. 分布式

1. Redis Cluster 實現了分布式的支持
2. Memcached 不支持分布式，只能通過在客戶端使用一致性哈希來實現分布式存儲，這種方式在存儲和查詢時都需要先在客戶端計算一次數據所在的節點。

4. 內存管理機制

• 在 Redis 中，并不是所有數據都一直存儲在內存中，可以將一些很久沒用的 value 交換到磁盤，而 Memcached 的數據則會一直在內存中。
• Memcached 將內存分割成特定長度的塊來存儲數據，以完全解決內存碎片的問題。但是這種方式會使得內存的利用率不高，例如塊的大小為 128 bytes，只存儲 100 bytes 的數據，那么剩下的 28 bytes 就浪費掉了。

5. 線程模型

• Redis 使用單線程的多路 IO 復用模型
• Memcached 是多線程，非阻塞IO復用的網絡模型

四. Redis持久化

Redis 是內存型數據庫，為了保證數據斷電后不丟失，需要將內存中的數據持久化到磁盤上；另一方面，保存中間結果，不必重新計算。

持久化有 2 種：

• 快照持久化：將存在某一時刻的所有數據都寫入磁盤中
• AOF 持久化：在執行寫命令時，將被執行的寫命令復制到文件中

Redis 提供的持久化配置選項：

# 快照持久化save 60 1000stop-writes-on-bgsave-error yesrdbcompression no# AOF 持久化appendonly yesappendfsync always # 同步選項auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb# 共享選項，決定了快照文件和 AOF 文件的保存位置dir ./

1. 快照持久化

快照持久化是通過創建快照來獲得 Redis 存儲在內存中數據在某個時間點上的副本。在創建快照后，用戶可對快照備份，可將快照留在原地以便重啟 Redis 時使用。

①. 快照持久化配置

save 60 10000 # 在60秒(1分鐘)之后，如果至少有10000個鍵發生變化，Redis 就會自動觸發 BGSAVE 命令創建快照。stop-writes-on-bgsave-error yes # 表示備份進程出錯的時候，主進程就停止接收新的寫入操作，是為了保護持久化數據的一致性。rdbcompression no# RDB 的壓縮設置為 no，因為壓縮會占用更多的 CPU 資源。

②. 創建快照的方法

• BGAVSE 命令：客戶端向 Redis 發送 BGSAVE 命令來創建一個快照。對于支持 BGSAVE 命令的平臺來說（基本上所有平臺支持，除了Windows平臺），Redis 會調用 fork 來創建一個子進程，然后子進程負責將快照寫入硬盤，而主進程則繼續處理命令請求。
• 用戶設置 save 配置選項

save 60 10000# 從 redis 最近一次創建快照之后算起，滿足 “60 s 內 10000 次寫入”，Redis 會自動觸發 BGSAVE 命令

③. 存在的問題

• 如果系統發生故障，將會丟失最近一次創建快照之后的數據
• 如果數據量很大，保存快照的時間會很長

2. AOF 持久化

AOF 持久化將被執行的寫命令寫到 AOF 文件末尾，記錄數據發生的變化。Redis 值要從頭到尾重新執行一次 AOF

文件包含的所有寫命令，就可恢復 AOF 文件所記錄的數據。

默認情況下，Redis 沒有開啟 AOF（append only file）方式的持久化，可以通過 appendonly 參數開啟：

appendonly yes

①. 快照持久化配置

appendonly yesappendfsync always # 同步選項auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

②. 同步選項

使用 AOF 持久化需要設置同步選項，從而確保寫命令什么時候會同步到磁盤文件上。

3. 重寫 / 壓縮 AOF 文件

AOF 持久化存在的問題：

• 隨著 Redis 不斷運行，AOF 文件的體積會不斷增長，占用更多的磁盤空間
• 若 AOF 文件體積非常大，則恢復的時間可能會比較長

為了解決 AOF 文件不斷增大的問題，我們采用重寫 / 壓縮 AOF 文件的方式：

用戶 Redis 發送 BGREWRITEAOF 命令，通過移除 AOF 文件中冗余命令來重寫 AOF 文件來減小 AOF 文件的體積。

（新的 AOF 文件和原有的 AOF 文件所保存的數據狀態是一致的，但是體積更小）。

BGREWRITEAOF 原理：

Redis 維護 AOF 重寫緩沖區和 AOF 緩沖區。子進程創建新的 AOF 文件期間，記錄服務器執行的所有寫命令會同時寫入 2 個緩沖區中，使得新舊兩個 AOF 文件中所保存的數據狀態一致。

4. 對比

5. 優化

Redis 4.0 以后將快照和 AOF 混合持久化（默認關閉，使用 aof-user-rdb-preamble開啟），AOF 重寫時將快照寫入 AOF 文件開頭。

這樣做的好處是可以結合 RDB 和 AOF 的優點, 快速加載同時避免丟失過多的數據，當然缺點也是有的， AOF 里面的 RDB 部分是壓縮格式不再是 AOF 格式，可讀性較差。

五. Redis事務

1. 命令

• MULTI命令：將客戶端從非事務狀態切換到事務狀態，標志著事務的開始。
• EXEC命令：客戶端向服務端發送該命令后，服務器會遍歷這個客戶端的事務隊列，并將所有命令的執行結果返回給客戶端。
• WATCH命令：樂觀鎖，可以在EXEC命令執行之前，監視任意數量的數據庫鍵，并在EXEC命令執行的時候，檢查被監視的鍵是否至少有一個已經被修改過了，如果有，服務器將拒絕執行該事務，并向客戶端返回代表事務執行失敗的空回復。

2. 簡述

Redis 通過 MULTI、EXEC、WATCH 等命令來實現事務功能。

事務提供了一種將多個命令請求打包，然后一次性、按順序地執行多個命令的機制。服務器在執行事務期間，不會改去執行其它客戶端的命令請求，它會將事務中的所有命令都執行完畢，然后才去處理其他客戶端的命令請求。

事務中的多個命令被一次性發送給服務器，而不是一條一條發送，這種方式被稱為pipeline。

注意：

• Redis 最簡單的事務實現方式是使用 MULTI 和 EXEC 命令將事務操作包圍起來。
• 使用 pineline 的好處：Redis 使用的是客戶端 / 服務器（C/S）模型和請求/響應協議的 TCP 服務器。Redis 客戶端與 Redis 服務器之間使用 TCP 協議進行連接，一個客戶端可以通過一個 Socket 連接發起多個請求命令。每個請求命令發出后客戶端通常會阻塞并等待 Redis 服務器處理，Redis 處理完請求命令后會將結果通過響應報文返回給客戶端，因此當執行多條命令的時候都需要等待上一條命令執行完畢才能執行。
• pipeline 可以一次性發送多條命令并在執行完后一次性將結果返回，可以減少客戶端與服務器之間的網絡通信次數從而提升性能，并且 pineline 基于隊列，而隊列的特點是先進先出，這樣就保證數據的順序性。
• Redis 的事務和傳統關系型數據庫事務的最大區別在于，Redis 不支持事務回滾機制（rollback），即使事務隊列中的某個命令在執行期間出現了錯誤，整個事務也會繼續執行下去，直到將事務隊列中的所有命令都執行完畢為止。因為其作者認為，Redis 事務執行時錯誤通常都是編程錯誤產生的，這種錯誤通常只會出現在開發環境中，而很少會在實際的生產環境中出現，所以他任務沒有必要開發 Redis 的回滾功能。

六. 深入理解Redis

1. 為何選擇Redis?
2. 高級鍵管理與數據結構
3. 內存管理的建議與技巧
4. Redis編程第一.部分: Redis 核心、客戶端和編程語言
5. Redis編程第二部分: Lua 腳本、管理與DevOps
6. 可伸縮性: Redis 集群和Sentinel
7. Redis與互補的NoSQL技術
8. Docker容器與云端部署
9. 任務管理與消息隊列
10. 信息流的測量與管理

七. Redis面試題

1. 什么是Redis？簡述它的優缺點？

Redis的全稱是：Remote Dictionary.Server，本質上是一個Key-Value類型的內存數據庫，很像 memcached，整個數據庫統統加載在內存當中進行操作，定期通過異步操作把數據庫數據flush到硬盤 上進行保存。

因為是純內存操作，Redis的性能非常出色，每秒可以處理超過 10萬次讀寫操作，是已知性能最快的 Key-Value DB。

Redis的出色之處不僅僅是性能，Redis最大的魅力是支持保存多種數據結構，此外單個value的最大限 制是1GB，不像 memcached只能保存1MB的數據，因此Redis可以用來實現很多有用的功能。

比方說用他的List來做FIFO雙向鏈表，實現一個輕量級的高性 能消息隊列服務，用他的Set可以做高 性能的tag系統等等。

另外Redis也可以對存入的Key-Value設置expire時間，因此也可以被當作一 個功能加強版的 memcached來用。 Redis的主要缺點是數據庫容量受到物理內存的限制，不能用作海量數據的高性能 讀寫，因此Redis適合的場景主要局限在較小數據量的高性能操作和運算上。

2. Redis與memcached相比有哪些優勢？

• memcached所有的值均是簡單的字符串，redis作為其替代者，支持更為豐富的數據類型
• redis的速度比memcached快很多redis的速度比memcached快很多
• redis可以持久化其數據redis可以持久化其數據

3. Redis支持哪幾種數據類型？

String、List、Set、Sorted Set、hashes

4. Redis主要消耗什么物理資源？

內存。

5. Redis有哪幾種數據淘汰策略？

• noeviction:返回錯誤當內存限制達到，并且客戶端嘗試執行會讓更多內存被使用的命令。
• allkeys-lru: 嘗試回收最少使用的鍵（LRU），使得新添加的數據有空間存放。
• volatile-lru: 嘗試回收最少使用的鍵（LRU），但僅限于在過期集合的鍵,使得新添加的數據有空間存 放。
• allkeys-random: 回收隨機的鍵使得新添加的數據有空間存放。
• volatile-random: 回收隨機的鍵使得新添加的數據有空間存放，但僅限于在過期集合的鍵。
• volatile-ttl: 回收在過期集合的鍵，并且優先回收存活時間（TTL）較短的鍵,使得新添加的數據有空間 存放。

6. Redis官方為什么不提供Windows版本？

因為目前Linux版本已經相當穩定，而且用戶量很大，無需開發windows版本，反而會帶來兼容性等問 題。

7. 一個字符串類型的值能存儲最大容量是多少？

512M

8. 為什么Redis需要把所有數據放到內存中？

Redis為了達到最快的讀寫速度將數據都讀到內存中，并通過異步的方式將數據寫入磁盤。 所以redis具有快速和數據持久化的特征，如果不將數據放在內存中，磁盤I/O速度為嚴重影響redis的 性能。 在內存越來越便宜的今天，redis將會越來越受歡迎， 如果設置了最大使用的內存，則數據已有記錄數達 到內存限值后不能繼續插入新值。

9. Redis集群方案應該怎么做？都有哪些方案？

• codis
• 目前用的最多的集群方案，基本和twemproxy一致的效果，但它支持在節點數量改變情況下，舊節點 數據可恢復到新hash節點。 redis cluster3.0自帶的集群，特點在于他的分布式算法不是一致性hash，而是hash槽的概念，以及自 身支持節點設置從節點。具體看官方文檔介紹。
• 在業務代碼層實現，起幾個毫無關聯的redis實例，在代碼層，對key進行hash計算，然后去對應的 redis實例操作數據。這種方式對hash層代碼要求比較高，考慮部分包括，節點失效后的替代算法方 案，數據震蕩后的自動腳本恢復，實例的監控，等等。

10. Redis集群方案什么情況下會導致整個集群不可用？

有A，B，C三個節點的集群,在沒有復制模型的情況下,如果節點B失敗了，那么整個集群就會以為缺少 5501-11000這個范圍的槽而不可用。

11. Redis有哪些適合的場景？

• 會話緩存（Session Cache）：最常用的一種使用Redis的情景是會話緩存（sessioncache），用Redis緩存會話比其他存儲（如 Memcached）的優勢在于：Redis提供持久化。當維護一個不是嚴格要求一致性的緩存時，如果用戶的 購物車信息全部丟失，大部分人都會不高興的，現在，他們還會這樣嗎？ 幸運的是，隨著 Redis 這些年的改進，很容易找到怎么恰當的使用Redis來緩存會話的文檔。甚至廣為 人知的商業平臺Magento也提供Redis的插件。
• 全頁緩存（FPC）：除基本的會話token之外，Redis還提供很簡便的FPC平臺。回到一致性問題，即使重啟了Redis實 例，因為有磁盤的持久化，用戶也不會看到頁面加載速度的下降，這是一個極大改進，類似PHP本地 FPC。 再次以Magento為例，Magento提供一個插件來使用Redis作為全頁緩存后端。 此外，對WordPress的用戶來說，Pantheon有一個非常好的插件wp-redis，這個插件能幫助你以最快 速度加載你曾瀏覽過的頁面。
• 隊列：Reids在內存存儲引擎領域的一大優點是提供list和set操作，這使得Redis能作為一個很好的消息隊列 平臺來使用。Redis作為隊列使用的操作，就類似于本地程序語言（如Python）對 list 的 push/pop 操作。 如果你快速的在Google中搜索“Redis queues”，你馬上就能找到大量的開源項目，這些項目的目的 就是利用Redis創建非常好的后端工具，以滿足各種隊列需求。例如，Celery有一個后臺就是使用 Redis作為broker，你可以從這里去查看。
• 排行榜/計數器：Redis在內存中對數字進行遞增或遞減的操作實現的非常好。集合（Set）和有序集合（SortedSet）也使 得我們在執行這些操作的時候變的非常簡單，Redis只是正好提供了這兩種數據結構。 所以，我們要從排序集合中獲取到排名最靠前的10個用戶–我們稱之為“user_scores”，我們只需要像 下面一樣執行即可： 當然，這是假定你是根據你用戶的分數做遞增的排序。如果你想返回用戶及用戶的分數，你需要這樣執 行： ZRANGE user_scores 0 10 WITHSCORES Agora Games就是一個很好的例子，用Ruby實現的，它的排行榜就是使用Redis來存儲數據的，你可 以在這里看到。
• 發布/訂閱： 最后（但肯定不是最不重要的）是Redis的發布/訂閱功能。發布/訂閱的使用場景確實非常多。我已看見 人們在社交網絡連接中使用，還可作為基于發布/訂閱的腳本觸發器，甚至用Redis的發布/訂閱功能來建 立聊天系統！

Java程序員福利：我把2019近一年經歷過的Java崗位面試，和一些刷過的面試題都做成了PDF，PDF都是可以免費分享給大家的，關注私信我：【101】，免費領取！