redis印象加深 redis理解

redis支援的資料結構以及使用場景

redis提供了rdb持久化和aof持久化

redis 雜湊槽的概念

快取雪崩

快取穿透

redis支援5中資料結構：

string資料結構是簡單的key-value型別，value不僅可以是string，也可以是數字。string字串資料結構最大容量為512m

使用場景：用來快取一些簡單的資訊，使用者id之類的，商品id等等。

key hashmap的形式，將一些結構化的資訊打包成hashmap，這裡的區別是value是以hashmap的形式儲存。

使用場景：儲存使用者資訊。對應為 key=使用者id, value=具體資訊(name,age,***...)

list說白了就是鍊錶（redis使用雙端鍊錶實現的list）。

list的另乙個應用就是訊息佇列，可以利用list的push操作，將任務存在list中，然後工作執行緒再用pop操作將任務取出進行執行。redis還提供了操作list中某一段元素的api，你可以直接查詢，刪除list中某一段的元素。

應用場景：主要應用於訊息佇列的實現，實現最新訊息排行等功能。

set就是乙個集合，集合的概念就是一堆不重複值的組合。利用redis提供的set資料結構，可以儲存一些集合性的資料。

和set相比，sorted set是將set中的元素增加了乙個權重引數score，使得集合中的元素能夠按score進行有序排列

rdb檔案儲存過程：

aof檔案儲存過程：

redis 集群有16384個雜湊槽,每個key通過crc16校驗後對16384取模來決定放置哪個槽.集群的每個節點負責一部分hash槽。這種結構很容易新增或者刪除節點，並且無論是新增刪除或者修改某乙個節點，都不會造成集群不可用的狀態。

使用雜湊槽的好處就在於可以方便的新增或移除節點。

當需要增加節點時，只需要把其他節點的某些雜湊槽挪到新節點就可以了；

當需要移除節點時，只需要把移除節點上的雜湊槽挪到其他節點就行了；

在這一點上，我們以後新增或移除節點的時候不用先停掉所有的 redis 服務。

資料未載入到快取，或者在同一時間快取大面積失效，從而導致所有請求在同一時間去查詢資料庫，引起資料庫cpu過高或者拓機。

比如乙個雪崩的簡單過程：

1、redis集群大面積故障

2、快取失效，但依然大量請求訪問快取服務redis

3、redis大量失效後，大量請求轉向到mysql資料庫

4、mysql的呼叫量暴增，很快就扛不住了，甚至直接宕機

5、由於大量的應用服務依賴mysql和redis的服務，這個時候很快會演變成各伺服器集群的雪崩，最後**徹底崩潰。

解決辦法：

快取層設計成高可用，防止快取大面積故障。即使個別節點、個別機器、甚至是機房宕掉，依然可以提供服務，例如 redis sentinel 和 redis cluster 都實現了高可用。

可以利用ehcache等本地快取(暫時使用)，但主要還需要對源服務訪問進行限流、資源隔離（熔斷）、降級等。

當訪問量劇增、服務出現問題仍然需要保證服務還是可用的。系統可以根據一些關鍵資料進行自動降級，也可以配置開關實現人工降級，這裡會涉及到運維的配合。

降級的最終目的是保證核心服務可用，即使是有損的。

快取穿透是指查詢乙個一不存在的資料。例如：從快取redis沒有命中，需要從mysql資料庫查詢，查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到資料庫去查詢，造成快取穿透。

解決思路

如果查詢資料庫也為空，直接設定乙個預設值存放到快取，這樣第二次到緩衝中獲取就有值了，而不會繼續訪問資料庫。設定乙個過期時間或者當有值的時候將快取中的值替換掉即可。

可以給key設定一些格式規則，然後查詢之前先過濾掉不符合規則的key。