Redis應用場景:緩存,快速讀寫,分佈式鎖等.
Redis優勢:內存,約束少.
Redis核心問題:數據一致性,訪問控制.
在Java中是Redis有兩種方式,一種是使用Redis官方推薦的Jedis API,或者使用Spring的RedisTemplate.
使用連接池後,如果要使用同一個連接來操作需要使用SessionCallback接口.
Redis的六種數據類型
String字符串(KV結構)
List列表(支持兩端操作的雙端隊列(物理結構:鏈表))
Set集合(無序,不重複)
Hash散列表(KV無序列表)
zset(有序)
HyperLogLog基數(只提供運算,不提供返回).
Redis的事務
一般而言,可以在multi命令之前使用watch命令監控某些鍵值對,然後使用multi命令開啓事務,執行各類對數據結構進行操作的命令,這個時候這些命令就會進入隊列.當Redis使用exec命令執行事務的時候,它首先回去比對被watch命令所監控的鍵值對,如果沒有發生變化,那麼它會執行事務隊列中的命令,提交事務;如果發生變化,那麼它不會執行任何事務中的命令,而去事務回滾.無論事務是否回滾,Redis都會去取消執行事務前的watch命令.
- multi開啓事務.
- watch key1 [key2...]監聽某些鍵,在事務執行前被修改,則會回滾.
- unwatch key1 [key2...]取消監聽某些鍵.
- exec執行事務.
- discard回滾事務.
Redis的操作具有原子性(單線程).
Redis事務的三個階段:開啓事務,命令進入隊列,執行事務.
Redis監聽某些鍵,決定是否回滾,採用樂觀鎖,且不存在ABA問題(版本號解決).使用multi命令後,使用get等方法的返回值一律爲空,只有在執行exec後纔會將所有命令的返回結果一起返回(List接收).
Redis事務遇到命令格式正確而數據類型不符合的情況下,除了本條命令外,其他命令都會被執行,不會被回滾.需要注意.
批量執行命令,可以使用Redis的流水線Pipeline功能.Redis的流水線是一種通信協議.需要注意返回的執行結果的大小,如果太大,可能導致內存不足,進而引發JVM溢出異常.可以考慮使用迭代的方式處理.
Redis發佈訂閱模式
SUBSCRIBE name.訂閱一個渠道/頻道.
publish name "hh" 向渠道發送消息.
Spring中如何使用:提供接受消息的類,它實現MessageListener接口,並重寫onMessage方法.配置RedisMessageListenerContainer監聽容器,用來監聽消息.RedisTemplate的convertAndSend方法可以向渠道發送消息.
Redis的超時回收
如果key超時了,Redis不會立刻回收該key,而是標識哪些鍵值對超時了(因爲如果太大,會導致長時間停頓).然後根據配置決定使用定時回收還是惰性回收.
定時回收就是在某個時間觸發一段代碼,回收超時的鍵值對.
惰性回收就是當一個超時的鍵,被再次用get命令訪問是,將觸發Redis將其從內存中清空.
Redis持久化
Redis備份的兩種方式:RDB(數據快照,適合備份數據),AOF(追加文件,適合主從複製時同步寫緩存中的數據).
save同步保存命令,執行時不允許客戶端對Redis進行讀寫操作,存儲格式爲RDB.
bgsave是一個異步保存命令,用於把Redis數據保存到對應的數據文件中,它允許執行時,客戶端同時讀寫Redis,存儲格式爲RDB.
Redis內存回收策略
Redis內存回收策略在Redis內存即將溢出時觸發.
noeviction：不淘汰鍵值對,內存滿時,申請內存的命令將會報錯.
allkeys-lru：最近最少使用的鍵(包括沒有設置超時時間的)會被淘汰.
volatile-lru：最近最少使用的鍵(設置了超時時間的)會被淘汰.
allkeys-random：隨機淘汰鍵(包括沒有設置超時時間的).
volatile-random：隨機淘汰鍵(包括沒有設置超時時間的)
volatile-ttl：優先淘汰剩餘存活時間短的鍵(設置了超時時間的).
Redis4.0後新增兩種:
volatile-lfu：優先淘汰最不常用的鍵(設置了超時時間的).
allkeys-lfu：優先淘汰最不常用的鍵(包括沒有設置超時時間的).
Redis主從複製
主服務器負責寫操作,從服務器負責讀操作.主服務器執行寫命令後,將寫入數據的命令發送給從服務器,從服務器執行命令,使得竹筒數據同步.如果主服務器宕機,則進行主從切換,從從服務器中選舉一臺服務器當做主服務器,原先的主服務器恢復後變爲從服務器.
如果出現多臺同步,可能會出現頻繁等待和頻繁操作bgsave命令的情況,導致主機在較長時間裏性能不佳,這時候可以考慮使用主從鏈進行同步.
哨兵模式
哨兵是一個獨立的進程,它會發送命令,等待Redis服務器響應,從而監控運行的多個Redis實例,當檢測到master宕機,哨兵會發起故障切換操作,將slave切換成master,然後通過發佈訂閱模式通知其他從服務器修改配置,完成客觀下線.還可以使用多個哨兵進行監控,防止哨兵掛掉,多哨兵情況下,單個哨兵檢測到master宕機稱爲主觀下線,當有一定數量的哨兵將master標爲主觀下線後,將由一個哨兵發起故障切換,完成客觀下線.
Redis哨兵默認超時3分鐘後纔會進行投票切換主機.
Redis分片
Redis分片是實現水平擴容的一種方式,將數據拆分存放在不同的Redis實例上.採用一致性哈希算法,一致性哈希算法由客戶端實現(Jedis的ShardedJedis).服務器端其實沒有任何改變.
一致性哈希算法會對key和節點名同時哈希,然後進行映射匹配,節點減少時,不會產生由於重新匹配造成對所有數據重新哈希,一致性哈希算法隻影響相鄰節點的分配.爲了避免一致性哈希算法對相鄰節點分配造成壓力,ShardedJedis會對每個節點根據名字虛擬化出160個虛擬節點進行散列,在節點增加或減少時,讓key在節點之間的移動分配更加均勻,而不是隻對相鄰節點有影響.
Redis集羣
Redis集羣採用哈希槽來映射數據,對key進行散列(CRC16後%16384),將數據放入某一個槽中,每個節點負責一部分哈希槽,當節點增加或減少時,需要對哈希槽進行重新分配到節點中,槽中的數據也要進行遷移.集羣要保證16384個哈希槽都能正常工作,所以將節點配置爲主從結構,如果主節點失效,集羣會根據選舉算法選出一個從節點升級爲主節點,整個集羣繼續對外提供服務,以實現自動故障轉移.如果客戶端操作的key沒有分配在該客戶端連接的節點上,服務器會返回轉向指令,指向正確的節點.
Redis集羣選舉原理:每個節點都會保存集羣中所有的主從狀態信息,節點間通過互相的ping-pong判斷對方的存活狀態.如果有半數以上的節點去ping一個節點的時候沒有成功,集羣就認爲這個節點宕機,然後去連接該節點的備用節點.
使用Spring緩存機制整合Redis
Spring提供了緩存管理器接口CacheManager來支持Redis.
spring-data-redis.jar提供的則是RedisCacheManager接口.
@EnableCaching
@Cacheable
@CachePut
@CacheEvict
要注意自調用失效的問題.和spring的事務管理一樣,因爲底層採用的是動態代理.