您好,登錄后才能下訂單哦!
小編給大家分享一下分析redis原理及實現方法,希望大家閱讀完這篇文章后大所收獲,下面讓我們一起去探討吧!
redis是nosql(也是個巨大的map) 單線程,但是可處理1秒10w的并發(數據都在內存中)
使用java對redis進行操作類似jdbc接口標準對mysql,有各類實現他的實現類,我們常用的是druid
其中對redis,我們通常用Jedis(也為我們提供了連接池JedisPool)
在redis中,key就是byte[](string)
redis的數據結構(value):
String,list,set,orderset,hash
先安裝好redis,然后運行,在pom文件中引入依賴,在要使用redis緩存的類的mapper.xml文件配置redis的全限定名。引入redis的redis.properties文件(如果要更改配置就可以使用)
應用場景:
String :
1存儲json類型對象,2計數器,3優酷視頻點贊等
list(雙向鏈表)
1可以使用redis的list模擬隊列,堆,棧
2朋友圈點贊(一條朋友圈內容語句,若干點贊語句)
規定:朋友圈內容的格式:
1,內容: user:x:post:x content來存儲;
2,點贊: post:x:good list來存儲;(把相應頭像取出來顯示)
hash(hashmap)
1保存對象
2分組
3 string與hash的數據差別
在網路傳輸時候,必須要進行進行序列化,才可以進行網路傳輸,那么在使用string類型的類型的時候需要進行相關序列化,hash也是要進行相關的系列化,所以會存在很多序列化,在存儲的時候hash是可以存儲的更加豐富,但是在反序列化的時候,string的反序列化相對較低,而hash的序列化和返序列化是相對hash類更加復雜,所以看業務場景,如果是數據經常修改的那種,為了性能可以使用string,如果是數據不是經常改的那種就可以使用hash,由于hash,存儲數據時比較豐富,可以存儲多種數據類型
4 redis的持久化方式:
能,將內存中的數據異步寫入硬盤中,兩種方式:RDB(默認)和AOF
RDB持久化原理:通過bgsave命令觸發,然后父進程執行fork操作創建子進程,子進程創建RDB文件,根據父進程內存生成臨時快照文件,完成后對原有文件進行原子替換(定時一次性將所有數據進行快照生成一份副本存儲在硬盤中)
優點:是一個緊湊壓縮的二進制文件,Redis加載RDB恢復數據遠遠快于AOF的方式。
缺點:由于每次生成RDB開銷較大,非實時持久化,
AOF持久化原理:開啟后,Redis每執行一個修改數據的命令,都會把這個命令添加到AOF文件中。
優點:實時持久化。
缺點:所以AOF文件體積逐漸變大,需要定期執行重寫操作來降低文件體積,加載慢
5 redis單線程為什么這么快
redis是單線程的,但是為什么還是這么快呢,
原因1: 單線程,避免線程之間的競爭
原因2 :是內存中的,使用內存的,可以減少磁盤的io
原因3:多路復用模型,用了緩沖區的概念,selector模型來進行的
redis提供了哨兵模式,當主掛了,可以選舉其他的進行代替,哨兵模式的實現原理,就是三個定時任務監控,
6.1 每隔10s,每個S節點(哨兵節點)會向主節點和從節點發送info命令獲取最新的拓撲結構
6.2 每隔2s,每個S節點會向某頻道上發送該S節點對于主節點的判斷以及當前Sl節點的信息,
同時每個Sentinel節點也會訂閱該頻道,來了解其他S節點以及它們對主節點的判斷(做客觀下線依據)
6.3 每隔1s,每個S節點會向主節點、從節點、其余S節點發送一條ping命令做一次心跳檢測(心跳檢測機制),來確認這些節點當前是否可達
當三次心跳檢測之后,就會進行投票,當超過半數以上的時候就會將該節點當做主
redis集群在3.0以后提供了ruby腳本進行搭建,引入了糙的概念,
Redis集群內節點通過ping/pong消息實現節點通信,消息不但可以傳播節點槽信息,還可以傳播其他狀態如:主從狀態、節點故障等。因此故障發現也是通過消息傳播機制實現的,主要環節包括:主觀下線(pfail)和客觀下線(fail)
主客觀下線:
主觀下線:集群中每個節點都會定期向其他節點發送ping消息,接收節點回復pong消息作為響應。如果通信一直失敗,則發送節點會把接收節點標記為主觀下線(pfail)狀態。
客觀下線:超過半數,對該主節點做客觀下線
主節點選舉出某一主節點作為領導者,來進行故障轉移。
故障轉移(選舉從節點作為新主節點)
Redis的內存淘汰策略是指在Redis的用于緩存的內存不足時,怎么處理需要新寫入且需要申請額外空間的數據。
noeviction:當內存不足以容納新寫入數據時,新寫入操作會報錯。
allkeys-lru:當內存不足以容納新寫入數據時,在鍵空間中,移除最近最少使用的key。
allkeys-random:當內存不足以容納新寫入數據時,在鍵空間中,隨機移除某個key。
volatile-lru:當內存不足以容納新寫入數據時,在設置了過期時間的鍵空間中,移除最近最少使用的key。
volatile-random:當內存不足以容納新寫入數據時,在設置了過期時間的鍵空間中,隨機移除某個key。
volatile-ttl:當內存不足以容納新寫入數據時,在設置了過期時間的鍵空間中,有更早過期時間的key優先移除。
原因:就是別人請求數據的時候,很多數據在緩存中無法查詢到,直接進入數據查詢,
解決方法,對相關數據進行查詢的數據只查詢緩存,如果是一些特殊的可以進行數據庫查詢,
也可以采用布隆過濾器進行查詢
緩存雪崩的原因:一次性加入緩存的數據過多,導致內存過高,從而影響內存的使用導致服務宕機
解決方法:
1 redis集群,通過集群方式將數據放置
2 后端服務降級和限流:當一個接口請求次數過多,那么就會添加過多數據,可以對服務進行限流,限制訪問的數量,這樣就可以減少問題的出現
看完了這篇文章,相信你對分析redis原理及實現方法有了一定的了解,想了解更多相關知識,歡迎關注億速云行業資訊頻道,感謝各位的閱讀!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。