共計 2611 個字符，預計需要花費 7 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

丸趣 TV 小編給大家分享一下分析 redis 原理及實現(xiàn)方法，希望大家閱讀完這篇文章后大所收獲，下面讓我們一起去探討吧！

1 什么是 redis

redis 是 nosql(也是個巨大的 map) 單線程，但是可處理 1 秒 10w 的并發(fā)（數(shù)據(jù)都在內存中）
使用 java 對 redis 進行操作類似 jdbc 接口標準對 mysql，有各類實現(xiàn)他的實現(xiàn)類，我們常用的是 druid
其中對 redis，我們通常用 Jedis(也為我們提供了連接池 JedisPool)

在 redis 中,key 就是 byte[](string)

redis 的數(shù)據(jù)結構 (value):

String,list,set,orderset,hash

2 redis 的使用

先安裝好 redis，然后運行，在 pom 文件中引入依賴，在要使用 redis 緩存的類的 mapper.xml 文件配置 redis 的全限定名。引入 redis 的 redis.properties 文件（如果要更改配置就可以使用）
應用場景:

String :
1 存儲 json 類型對象,2 計數(shù)器,3 優(yōu)酷視頻點贊等
list(雙向鏈表)
1 可以使用 redis 的 list 模擬隊列, 堆, 棧

2 朋友圈點贊 (一條朋友圈內容語句, 若干點贊語句)

規(guī)定: 朋友圈內容的格式:

1, 內容: user:x:post:x content 來存儲;

2, 點贊: post:x:good list 來存儲;(把相應頭像取出來顯示)

hash(hashmap)

1 保存對象

2 分組

3 string 與 hash 的數(shù)據(jù)差別

在網(wǎng)路傳輸時候，必須要進行進行序列化，才可以進行網(wǎng)路傳輸，那么在使用 string 類型的類型的時候需要進行相關序列化，hash 也是要進行相關的系列化，所以會存在很多序列化，在存儲的時候 hash 是可以存儲的更加豐富，但是在反序列化的時候，string 的反序列化相對較低，而 hash 的序列化和返序列化是相對 hash 類更加復雜，所以看業(yè)務場景，如果是數(shù)據(jù)經(jīng)常修改的那種，為了性能可以使用 string，如果是數(shù)據(jù)不是經(jīng)常改的那種就可以使用 hash，由于 hash，存儲數(shù)據(jù)時比較豐富，可以存儲多種數(shù)據(jù)類型

4 redis 的持久化方式：

能，將內存中的數(shù)據(jù)異步寫入硬盤中，兩種方式：RDB（默認）和 AOF

RDB 持久化原理：通過 bgsave 命令觸發(fā)，然后父進程執(zhí)行 fork 操作創(chuàng)建子進程，子進程創(chuàng)建 RDB 文件，根據(jù)父進程內存生成臨時快照文件，完成后對原有文件進行原子替換（定時一次性將所有數(shù)據(jù)進行快照生成一份副本存儲在硬盤中）

優(yōu)點：是一個緊湊壓縮的二進制文件，Redis 加載 RDB 恢復數(shù)據(jù)遠遠快于 AOF 的方式。

缺點：由于每次生成 RDB 開銷較大，非實時持久化，

AOF 持久化原理：開啟后，Redis 每執(zhí)行一個修改數(shù)據(jù)的命令，都會把這個命令添加到 AOF 文件中。

優(yōu)點：實時持久化。

缺點：所以 AOF 文件體積逐漸變大，需要定期執(zhí)行重寫操作來降低文件體積，加載慢

5 redis 單線程為什么這么快

redis 是單線程的，但是為什么還是這么快呢，

原因 1：單線程，避免線程之間的競爭

原因 2：是內存中的，使用內存的，可以減少磁盤的 io

原因 3：多路復用模型，用了緩沖區(qū)的概念，selector 模型來進行的

6 redis 主掛了怎么操作

redis 提供了哨兵模式，當主掛了，可以選舉其他的進行代替，哨兵模式的實現(xiàn)原理，就是三個定時任務監(jiān)控，

6.1 每隔 10s，每個 S 節(jié)點（哨兵節(jié)點）會向主節(jié)點和從節(jié)點發(fā)送 info 命令獲取最新的拓撲結構

6.2 每隔 2s，每個 S 節(jié)點會向某頻道上發(fā)送該 S 節(jié)點對于主節(jié)點的判斷以及當前 Sl 節(jié)點的信息，

同時每個 Sentinel 節(jié)點也會訂閱該頻道，來了解其他 S 節(jié)點以及它們對主節(jié)點的判斷（做客觀下線依據(jù)）

6.3 每隔 1s，每個 S 節(jié)點會向主節(jié)點、從節(jié)點、其余 S 節(jié)點發(fā)送一條 ping 命令做一次心跳檢測 (心跳檢測機制)，來確認這些節(jié)點當前是否可達

當三次心跳檢測之后，就會進行投票，當超過半數(shù)以上的時候就會將該節(jié)點當做主

7 redis 集群

redis 集群在 3.0 以后提供了 ruby 腳本進行搭建，引入了糙的概念，

Redis 集群內節(jié)點通過 ping/pong 消息實現(xiàn)節(jié)點通信，消息不但可以傳播節(jié)點槽信息，還可以傳播其他狀態(tài)如：主從狀態(tài)、節(jié)點故障等。因此故障發(fā)現(xiàn)也是通過消息傳播機制實現(xiàn)的，主要環(huán)節(jié)包括：主觀下線（pfail）和客觀下線（fail）
主客觀下線：

主觀下線：集群中每個節(jié)點都會定期向其他節(jié)點發(fā)送 ping 消息，接收節(jié)點回復 pong 消息作為響應。如果通信一直失敗，則發(fā)送節(jié)點會把接收節(jié)點標記為主觀下線（pfail）狀態(tài)。

客觀下線：超過半數(shù)，對該主節(jié)點做客觀下線

主節(jié)點選舉出某一主節(jié)點作為領導者，來進行故障轉移。

故障轉移（選舉從節(jié)點作為新主節(jié)點）

8 內存淘汰策略

Redis 的內存淘汰策略是指在 Redis 的用于緩存的內存不足時，怎么處理需要新寫入且需要申請額外空間的數(shù)據(jù)。

noeviction：當內存不足以容納新寫入數(shù)據(jù)時，新寫入操作會報錯。

allkeys-lru：當內存不足以容納新寫入數(shù)據(jù)時，在鍵空間中，移除最近最少使用的 key。

allkeys-random：當內存不足以容納新寫入數(shù)據(jù)時，在鍵空間中，隨機移除某個 key。

volatile-lru：當內存不足以容納新寫入數(shù)據(jù)時，在設置了過期時間的鍵空間中，移除最近最少使用的 key。

volatile-random：當內存不足以容納新寫入數(shù)據(jù)時，在設置了過期時間的鍵空間中，隨機移除某個 key。

volatile-ttl：當內存不足以容納新寫入數(shù)據(jù)時，在設置了過期時間的鍵空間中，有更早過期時間的 key 優(yōu)先移除。

9 緩存擊穿的解決方案：

原因：就是別人請求數(shù)據(jù)的時候，很多數(shù)據(jù)在緩存中無法查詢到，直接進入數(shù)據(jù)查詢，

解決方法，對相關數(shù)據(jù)進行查詢的數(shù)據(jù)只查詢緩存，如果是一些特殊的可以進行數(shù)據(jù)庫查詢，

也可以采用布隆過濾器進行查詢

10 緩存雪崩的解決方案：

緩存雪崩的原因：一次性加入緩存的數(shù)據(jù)過多，導致內存過高，從而影響內存的使用導致服務宕機

解決方法：

1 redis 集群，通過集群方式將數(shù)據(jù)放置

2 后端服務降級和限流：當一個接口請求次數(shù)過多，那么就會添加過多數(shù)據(jù)，可以對服務進行限流，限制訪問的數(shù)量，這樣就可以減少問題的出現(xiàn)

看完了這篇文章，相信你對分析 redis 原理及實現(xiàn)方法有了一定的了解，想了解更多相關知識，歡迎關注丸趣 TV 行業(yè)資訊頻道，感謝各位的閱讀！

丸趣 TV 網(wǎng) – 提供最優(yōu)質的資源集合！