Redis資料庫 Redis（Remote Dictionary Server）是一個使用 C 語言編寫的，高性能非關係型的鍵值對資料庫。與傳統資料庫不同的是，Redis 的數據是存在記憶體中的，所以讀寫速度非常快，被廣泛應用於緩存方向。Redis可以將數據寫入磁碟中，保證了數據的安全不丟失，而且Re ...

Redis資料庫

Redis（Remote Dictionary Server）是一個使用 C 語言編寫的，高性能非關係型的鍵值對資料庫。與傳統資料庫不同的是，Redis 的數據是存在記憶體中的，所以讀寫速度非常快，被廣泛應用於緩存方向。Redis可以將數據寫入磁碟中，保證了數據的安全不丟失，而且Redis的操作是原子性的。

1. Redis 優缺點

優點：

基於記憶體操作，讀寫速度很快

支持多種數據類型，string，hash，list，set，zset等

支持持久化：Redis支持RDB和AOF兩種持久化機制，持久化功能可以有效地避免數據丟失問題。

支持事務：Redis的所有操作都是原子性的，同時Redis還支持對幾個操作合併後的原子性執行。

支持主從複製：主節點會自動將數據同步到從節點，可以進行讀寫分離。

Redis命令的處理是單線程的。Redis6.0引入了多線程，需要註意的是，多線程用於處理網路數據的讀寫和協議解析，Redis命令執行還是單線程的。

缺點

對結構化查詢的支持比較差。

資料庫容量受到物理記憶體的限制，不適合用作海量數據的高性能讀寫，因此Redis適合的場景主要局限在較小數據量的操作。

Redis 較難支持線上擴容，在集群容量達到上限時線上擴容會變得很複雜。

2. Redis快的原因

基於記憶體：Redis是使用記憶體存儲，沒有磁碟IO上的開銷。數據存在記憶體中，讀寫速度快。
IO多路復用模型：Redis 採用 IO 多路復用技術。Redis 使用單線程來輪詢描述符，將資料庫的操作都轉換成了事件，不在網路I/O上浪費過多的時間。
高效的數據結構：Redis 每種數據類型底層都做了優化，目的就是為了追求更快的速度。

3. 只用作緩存的原因

雖然Redis非常快，但它也有一些局限性，不能完全替代主資料庫。有以下原因：

事務處理：Redis只支持簡單的事務處理，對於複雜的事務無能為力，比如跨多個鍵的事務處理。

數據持久化：Redis是記憶體資料庫，數據存儲在記憶體中，如果伺服器崩潰或斷電，數據可能丟失。雖然Redis提供了數據持久化機制，但有一些限制。

數據處理：Redis只支持一些簡單的數據結構，比如字元串、列表、哈希表等。如果需要處理複雜的數據結構，比如關係型資料庫中的表，那麼Redis可能不是一個好的選擇。

數據安全：Redis沒有提供像主資料庫那樣的安全機制，比如用戶認證、訪問控制等等。

因此，雖然Redis非常快，但它還有一些限制，不能完全替代主資料庫。所以，使用Redis作為緩存是一種很好的方式，可以提高應用程式的性能，並減少資料庫的負載。

4. Redis的線程模型

Redis基於Reactor模式開發了網路事件處理器，這個處理器被稱為文件事件處理器。它的組成結構為4部分：多個套接字、IO多路復用程式、文件事件分派器、事件處理器。因為文件事件分派器隊列的消費是單線程的，所以Redis才叫單線程模型。

文件事件處理器使用I/O多路復用（multiplexing）程式來同時監聽多個套接字，並根據套接字目前執行的任務來為套接字關聯不同的事件處理器。
當被監聽的套接字準備好執行連接accept、read、write、close等操作時，與操作相對應的文件事件就會產生，這時文件事件處理器就會調用套接字之前關聯好的事件處理器來處理這些事件。

雖然文件事件處理器以單線程方式運行，但通過使用 I/O 多路復用程式來監聽多個套接字，文件事件處理器既實現了高性能的網路通信模型，又可以很好地與 redis 伺服器中其他同樣以單線程方式運行的模塊進行對接，這保持了 Redis 內部單線程設計的簡單性。

5. Redis應用場景

緩存熱點數據，緩解資料庫的壓力。
利用 Redis 原子性的自增操作，可以實現計數器的功能，比如統計用戶點贊數、用戶訪問數等。
分散式鎖。在分散式場景下，無法使用單機環境下的鎖來對多個節點上的進程進行同步。可以使用 Redis 自帶的 SETNX 命令實現分散式鎖，除此之外，還可以使用官方提供的 RedLock 分散式鎖實現。
簡單的消息隊列，可以使用Redis自身的發佈/訂閱模式或者List來實現簡單的消息隊列，實現非同步操作。
限速器，可用於限制某個用戶訪問某個介面的頻率，比如秒殺場景用於防止用戶快速點擊帶來不必要的壓力。
好友關係，利用集合的一些命令，比如交集、並集、差集等，實現共同好友、共同愛好之類的功能。

6. Redis的數據類型

基本數據類型：

1、String：最常用的一種數據類型，String類型的值可以是字元串、數字或者二進位，但值最大不能超過512MB。

2、Hash：Hash 是一個鍵值對集合。

3、Set：無序去重的集合。Set 提供了交集、並集等方法，對於實現共同好友、共同關註等功能特別方便。

4、List：有序可重覆的集合，底層是依賴雙向鏈表實現的。

5、SortedSet：有序Set。內部維護了一個score的參數來實現。適用於排行榜和帶權重的消息隊列等場景。

特殊的數據類型：

1、Bitmap：點陣圖，可以認為是一個以位為單位數組，數組中的每個單元只能存0或者1，數組的下標在 Bitmap 中叫做偏移量。Bitmap的長度與集合中元素個數無關，而是與基數的上限有關。

2、Hyperloglog。HyperLogLog 是用來做基數統計的演算法，其優點是，在輸入元素的數量或者體積非常非常大時，計算基數所需的空間總是固定的、並且是很小的。典型的使用場景是統計獨立訪客。

3、Geospatial ：主要用於存儲地理位置信息，並對存儲的信息進行操作，適用場景如定位、附近的人等。

7. Redis事務支持隔離性嗎？

Redis 是單進程程式，並且它保證在執行事務時，不會對事務進行中斷，事務可以運行直到執行完所有事務隊列中的命令為止。因此，Redis 的事務是總是帶有隔離性的。

8. Redis事務保證原子性嗎，支持回滾嗎？

Redis單條命令是原子性執行的，但事務不保證原子性，且沒有回滾。事務中任意命令執行失敗，其餘的命令仍會被執行。

9. Redis有哪些部署方案？

單機版：單機部署，單機redis能夠承載的 QPS 大概就在上萬到幾萬不等。這種部署方式很少使用。存在的問題：1、記憶體容量有限 2、處理能力有限 3、無法高可用。

主從模式：一主多從，主負責寫，並且將數據複製到其它的 slave 節點，從節點負責讀。所有的讀請求全部走從節點。這樣也可以很輕鬆實現水平擴容，支撐讀高併發。master 節點掛掉後，需要手動指定新的 master，可用性不高，基本不用。

哨兵模式：主從複製存在不能自動故障轉移、達不到高可用的問題。哨兵模式解決了這些問題。通過哨兵機制可以自動切換主從節點。master 節點掛掉後，哨兵進程會主動選舉新的 master，可用性高，但是每個節點存儲的數據是一樣的，浪費記憶體空間。數據量不是很多，集群規模不是很大，需要自動容錯容災的時候使用。

Redis cluster：服務端分片技術，3.0版本開始正式提供。Redis Cluster並沒有使用一致性hash，而是採用slot(槽)的概念，一共分成16384個槽。將請求發送到任意節點，接收到請求的節點會將查詢請求發送到正確的節點上執行。主要是針對海量數據+高併發+高可用的場景，如果是海量數據，如果你的數據量很大，那麼建議就用Redis cluster，所有主節點的容量總和就是Redis cluster可緩存的數據容量。

10. 主從架構

單機的 redis，能夠承載的 QPS 大概就在上萬到幾萬不等。對於緩存來說，一般都是用來支撐讀高併發的。因此架構做成主從(master-slave)架構，一主多從，主負責寫，並且將數據複製到其它的 slave 節點，從節點負責讀。所有的讀請求全部走從節點。這樣也可以很輕鬆實現水平擴容，支撐讀高併發。

Redis的複製功能是支持多個資料庫之間的數據同步。主資料庫可以進行讀寫操作，當主資料庫的數據發生變化時會自動將數據同步到從資料庫。從資料庫一般是只讀的，它會接收主資料庫同步過來的數據。一個主資料庫可以有多個從資料庫，而一個從資料庫只能有一個主資料庫。

主從複製的原理？

當啟動一個從節點時，它會發送一個 PSYNC 命令給主節點；
如果是從節點初次連接到主節點，那麼會觸發一次全量複製。此時主節點會啟動一個後臺線程，開始生成一份 RDB 快照文件；
同時還會將從客戶端 client 新收到的所有寫命令緩存在記憶體中。RDB 文件生成完畢後，主節點會將RDB文件發送給從節點，從節點會先將RDB文件寫入本地磁碟，然後再從本地磁碟載入到記憶體中；
接著主節點會將記憶體中緩存的寫命令發送到從節點，從節點同步這些數據；
如果從節點跟主節點之間網路出現故障，連接斷開了，會自動重連，連接之後主節點僅會將部分缺失的數據同步給從節點。

11. 哨兵Sentinel

主從複製存在不能自動故障轉移、達不到高可用的問題。哨兵模式解決了這些問題。通過哨兵機制可以自動切換主從節點。

客戶端連接Redis的時候，先連接哨兵，哨兵會告訴客戶端Redis主節點的地址，然後客戶端連接上Redis併進行後續的操作。當主節點宕機的時候，哨兵監測到主節點宕機，會重新推選出某個表現良好的從節點成為新的主節點，然後通過發佈訂閱模式通知其他的從伺服器，讓它們切換主機。

工作原理

每個Sentinel以每秒鐘一次的頻率向它所知道的Master，Slave以及其他 Sentinel 實例發送一個 PING命令。
如果一個實例距離最後一次有效回覆 PING 命令的時間超過指定值，則這個實例會被 Sentine 標記為主觀下線。
如果一個Master被標記為主觀下線，則正在監視這個Master的所有 Sentinel 要以每秒一次的頻率確認Master是否真正進入主觀下線狀態。
當有足夠數量的 Sentinel（大於等於配置文件指定值）在指定的時間範圍內確認Master的確進入了主觀下線狀態，則Master會被標記為客觀下線。若沒有足夠數量的 Sentinel 同意 Master 已經下線， Master 的客觀下線狀態就會被解除。若 Master重新向 Sentinel 的 PING 命令返回有效回覆， Master 的主觀下線狀態就會被移除。
哨兵節點會選舉出哨兵 leader，負責故障轉移的工作。
哨兵 leader 會推選出某個表現良好的從節點成為新的主節點，然後通知其他從節點更新主節點信息。

12. Redis cluster

哨兵模式解決了主從複製不能自動故障轉移、達不到高可用的問題，但還是存在主節點的寫能力、容量受限於單機配置的問題。而cluster模式實現了Redis的分散式存儲，每個節點存儲不同的內容，解決主節點的寫能力、容量受限於單機配置的問題。

Redis cluster集群節點最小配置6個節點以上（3主3從），其中主節點提供讀寫操作，從節點作為備用節點，不提供請求，只作為故障轉移使用。

Redis cluster採用虛擬槽分區，所有的鍵根據哈希函數映射到0～16383個整數槽內，每個節點負責維護一部分槽以及槽所映射的鍵值數據。

工作原理：

通過哈希的方式，將數據分片，每個節點均分存儲一定哈希槽(哈希值)區間的數據，預設分配了16384 個槽位
每份數據分片會存儲在多個互為主從的多節點上
數據寫入先寫主節點，再同步到從節點(支持配置為阻塞同步)
同一分片多個節點間的數據不保持一致性
讀取數據時，當客戶端操作的key沒有分配在該節點上時，redis會返迴轉向指令，指向正確的節點
擴容時時需要需要把舊節點的數據遷移一部分到新節點

在 redis cluster 架構下，每個 redis 要放開兩個埠號，比如一個是 6379，另外一個就是加1w 的埠號，比如 16379。

16379 埠號是用來進行節點間通信的，也就是 cluster bus 的東西，cluster bus 的通信，用來進行故障檢測、配置更新、故障轉移授權。cluster bus 用了另外一種二進位的協議，gossip 協議，用於節點間進行高效的數據交換，占用更少的網路帶寬和處理時間。

13. Redis 怎麼實現消息隊列？

使用list類型保存數據信息，rpush生產消息，lpop消費消息，當lpop沒有消息時，可以sleep一段時間，然後再檢查有沒有信息，如果不想sleep的話，可以使用blpop, 在沒有信息的時候，會一直阻塞，直到信息的到來。

BLPOP queue 0  //0表示不限制等待時間

BLPOP和LPOP命令相似，唯一的區別就是當列表沒有元素時BLPOP命令會一直阻塞連接，直到有新元素加入。

redis可以通過pub/sub主題訂閱模式實現一個生產者，多個消費者，當然也存在一定的缺點，當消費者下線時，生產的消息會丟失。

PUBLISH channel1 hi
SUBSCRIBE channel1
UNSUBSCRIBE channel1 //退訂通過SUBSCRIBE命令訂閱的頻道。

PSUBSCRIBE channel?* 按照規則訂閱。PUNSUBSCRIBE channel?* 退訂通過PSUBSCRIBE命令按照某種規則訂閱的頻道。其中訂閱規則要進行嚴格的字元串匹配，PUNSUBSCRIBE *無法退訂channel?*規則。

14. Redis 怎麼實現延時隊列

使用sortedset，拿時間戳作為score，消息內容作為key，調用zadd來生產消息，消費者用zrangebyscore指令獲取N秒之前的數據輪詢進行處理。

15. Redis大key怎麼處理？

通常我們會將含有較大數據或含有大量成員、列表數的Key稱之為大Key。

以下是對各個數據類型大key的描述：

value是STRING類型，它的值超過5MB
value是ZSET、Hash、List、Set等集合類型時，它的成員數量超過1w個

上述的定義並不絕對，主要是根據value的成員數量和大小來確定，根據業務場景確定標準。

怎麼處理：

當vaule是string時，可以使用序列化、壓縮演算法將key的大小控制在合理範圍內，但是序列化和反序列化都會帶來更多時間上的消耗。或者將key進行拆分，一個大key分為不同的部分，記錄每個部分的key，使用multiget等操作實現事務讀取。
當value是list/set等集合類型時，根據預估的數據規模來進行分片，不同的元素計算後分到不同的片。

16. Redis常見性能問題和解決方案？

Master最好不要做任何持久化工作，包括記憶體快照和AOF日誌文件，特別是不要啟用記憶體快照做持久化。
如果數據比較關鍵，某個Slave開啟AOF備份數據，策略為每秒同步一次。
為了主從複製的速度和連接的穩定性，Slave和Master最好在同一個區域網內。
儘量避免在壓力較大的主庫上增加從庫
Master調用BGREWRITEAOF重寫AOF文件，AOF在重寫的時候會占大量的CPU和記憶體資源，導致服務load過高，出現短暫服務暫停現象。
為了Master的穩定性，主從複製不要用圖狀結構，用單向鏈表結構更穩定，即主從關係為：Master<–Slave1<–Slave2<–Slave3…，這樣的結構也方便解決單點故障問題，實現Slave對Master的替換，也即，如果Master掛了，可以立馬啟用Slave1做Master，其他不變。

17. 持久化機制

持久化就是把記憶體的數據寫到磁碟中，防止服務宕機導致記憶體數據丟失。

Redis支持兩種方式的持久化，一種是RDB的方式，一種是AOF的方式。前者會根據指定的規則定時將記憶體中的數據存儲在硬碟上，而後者在每次執行完命令後將命令記錄下來。一般將兩者結合使用。

RDB方式

RDB是 Redis 預設的持久化方案。RDB持久化時會將記憶體中的數據寫入到磁碟中，在指定目錄下生成一個dump.rdb文件。Redis 重啟會載入dump.rdb文件恢複數據。

bgsave是主流的觸發 RDB 持久化的方式，執行過程如下：

執行BGSAVE命令

Redis 父進程判斷當前是否存在正在執行的子進程，如果存在，BGSAVE命令直接返回。

父進程執行fork操作創建子進程，fork操作過程中父進程會阻塞。

父進程fork完成後，父進程繼續接收並處理客戶端的請求，而子進程開始將記憶體中的數據寫進硬碟的臨時文件；

當子進程寫完所有數據後會用該臨時文件替換舊的 RDB 文件。

Redis啟動時會讀取RDB快照文件，將數據從硬碟載入記憶體。通過 RDB 方式的持久化，一旦Redis異常退出，就會丟失最近一次持久化以後更改的數據。

觸發 RDB 持久化的方式：

手動觸發：用戶執行SAVE或BGSAVE命令。SAVE命令執行快照的過程會阻塞所有客戶端的請求，應避免在生產環境使用此命令。BGSAVE命令可以在後臺非同步進行快照操作，快照的同時伺服器還可以繼續響應客戶端的請求，因此需要手動執行快照時推薦使用BGSAVE命令。
被動觸發：根據配置規則進行自動快照，如SAVE 100 10，100秒內至少有10個鍵被修改則進行快照。如果從節點執行全量複製操作，主節點會自動執行BGSAVE生成 RDB 文件併發送給從節點。預設情況下執行shutdown命令時，如果沒有開啟 AOF 持久化功能則自動執行·BGSAVE·。

AOF方式

AOF（append only file）持久化：以獨立日誌的方式記錄每次寫命令，Redis重啟時會重新執行AOF文件中的命令達到恢複數據的目的。AOF的主要作用是解決了數據持久化的實時性，AOF 是Redis持久化的主流方式。

預設情況下Redis沒有開啟AOF方式的持久化，可以通過appendonly參數啟用：appendonly yes。開啟AOF方式持久化後每執行一條寫命令，Redis就會將該命令寫進aof_buf緩衝區，AOF緩衝區根據對應的策略向硬碟做同步操作。

預設情況下系統每30秒會執行一次同步操作。為了防止緩衝區數據丟失，可以在Redis寫入AOF文件後主動要求系統將緩衝區數據同步到硬碟上。可以通過appendfsync參數設置同步的時機。

appendfsync always //每次寫入aof文件都會執行同步，最安全最慢，不建議配置
appendfsync everysec  //既保證性能也保證安全，建議配置
appendfsync no //由操作系統決定何時進行同步操作

所有的寫入命令會追加到 AOP 緩衝區中。
AOF 緩衝區根據對應的策略向硬碟同步。
隨著 AOF 文件越來越大，需要定期對 AOF 文件進行重寫，達到壓縮文件體積的目的。AOF文件重寫是把Redis進程內的數據轉化為寫命令同步到新AOF文件的過程。
當 Redis 伺服器重啟時，可以載入 AOF 文件進行數據恢復。

AOF可以更好的保護數據不丟失，可以配置 AOF 每秒執行一次fsync操作，如果Redis進程掛掉，最多丟失1秒的數據。

AOF以append-only的模式寫入，所以沒有磁碟定址的開銷，寫入性能非常高。

對於同一份文件AOF文件比RDB數據快照要大。

數據恢複比較慢。

Redis 載入 RDB 恢複數據遠遠快於 AOF 的方式。

使用單獨子進程來進行持久化，主進程不會進行任何 IO 操作，保證了 Redis 的高性能。

RDB方式數據無法做到實時持久化。因為BGSAVE每次運行都要執行fork操作創建子進程，屬於重量級操作，頻繁執行成本比較高。

RDB 文件使用特定二進位格式保存，Redis 版本升級過程中有多個格式的 RDB 版本，存在老版本 Redis 無法相容新版 RDB 格式的問題。

本文來自博客園，作者：ivanlee717，轉載請註明原文鏈接：https://www.cnblogs.com/ivanlee717/p/17270100.html

redis面試小結