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

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/548669.html

標籤：其它

上一篇：讀SQL進階教程筆記02_三值邏輯和NULL

下一篇：一種自平衡解決資料傾斜的分表方法

redis面試小結