
一、memcached與redis的區別?
1.存儲方式不同。memcached把數據全部存在內存之中,斷電之后會掛掉,而redis雖然也用到了內存,但是會有部分數據存在硬盤中,保證數據持久性。
2.數據支持類型不同。memcached對數據支持比較簡單,而redis支持數據類型較豐富,如string、list、set、sorted set、hash。
3.底層實現不同。一般調用系統函數,會消耗比較多的時間去請求,redis自己構建了vm,速度會更快。
二、redis數據的淘汰策略?
1.volatile-lru:從已經設置過期時間的數據集中,挑選最近最少使用的數據淘汰。
2.volatile-ttl:從已經設置過期時間的數據集中,挑選即將要過期的數據淘汰。
3.volatile-random:從已經設置過期時間的數據集中,隨機挑選數據淘汰。
4.allkeys-lru:從所有的數據集中,挑選最近最少使用的數據淘汰。
5.allkeys-random:從所有的數據集中,隨機挑選數據淘汰。
6。no-enviction:禁止淘汰數據。
三、為什么redis把所有數據都放到內存中?
redis為了達到最快的讀寫速度,將數據都讀到內存中,並通過異步的方式將數據寫入磁盤。如果不將數據放在內存中,磁盤IO速度會嚴重影響redis的性能。
四、redis的並發競爭問題如何解決?
首先redis為單進程單線程模式,采用隊列模式將並發訪問變為串行訪問。redis本身時沒有鎖的概念的,redis對多個客戶端連接並不存在競爭,但是在Jedis客戶端對redis進行並發訪問時會產生一系列問題,這些問題時由於客戶端連接混亂造成的。有兩種方案解決。
1.在客戶端,對連接進行池化,同時對客戶端讀寫redis操作采用內部鎖synchronized。
2.在服務器角度,利用setnx實現鎖。
五、redis過期鍵的刪除策略?
1.定時刪除:在設置鍵的過期時間的同時,創建一個timer,讓定時器在鍵的過期時間到達時,立即執行對鍵的刪除操作。(主動刪除)
對內存友好,但是對cpu時間不友好,有較多過期鍵的而情況下,刪除過期鍵會占用相當一部分cpu時間。
2.惰性刪除:放任過期鍵不管,但是每次從鍵空間中獲取鍵時,都檢查取到的鍵是否過去,如果過期就刪除,如果沒過期就返回該鍵。(被動刪除)
對cpu時間友好,程序只會在取出鍵的時候才會對鍵進行過期檢查,這不會在刪除其他無關過期鍵上花費任何cpu時間,但是如果一個鍵已經過期,而這個鍵又保留在數據庫中,那么只要這個過期鍵不被刪除,他所占用的內存就不會釋放,對內存不友好。
3.定期刪除:每隔一段時間就對數據庫進行一次檢查,刪除里面的過期鍵。(主動刪除)
采用對內存和cpu時間折中的方法,每個一段時間執行一次刪除過期鍵操作,並通過限制操作執行的時長和頻率來減少對cpu時間的影響。難點在於,選擇一個好的策略來設置刪除操作的時長和執行頻率。
六、redis與一般db的同步過程?
有兩種方式。
第一種,先去redis中判斷數據是否存在,如果存在,則直接返回緩存好的數據,如果不存在,去db中讀取數據,並把數據緩存一份到redis中。適用與數據里比較大,但是不經常更新的情況,如用戶排行。

第二種,先去redis中判斷數據是否存在,如果存在,則直接更新對應數據(這一步會記錄下更新的key,並把更新后的數據返回給頁面,如果不存在,先去數據庫中更新內容,然后把數據保存一份到redis中。再往后,后台會進行一系列操作,把redis中更新的key讀取出來,找到數據庫中對應的數據,並更新數據庫。這種方式是把redis當作數據庫使用,適合大數據的頻繁變動。但是對redis的依賴很大,要做好掛掉之后的數據備份。

七、簡述redis的哨兵模式
哨兵是對redis進行實時的監控,主要有兩個功能。
1.監測主數據庫和從數據庫是否正常運行。2.當主數據庫出現故障的時候,可以自動將一個從數據庫轉換為主數據庫,實現自動切換。
八、redis的哨兵的監控機制是怎樣的?
哨兵監控也是有集群的,會有多個哨兵進行監控,當判斷發生故障的哨兵達到一定數量的時候才進行修復。一個健壯的部署至少需要三個哨兵實例。
每個Sentinel以每秒鍾一次的頻率向它所知的Master,Slave以及其他 Sentinel 實例發送一個 PING 命令
2.如果一個實例(instance)距離最后一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值, 則這個實例會被 Sentinel 標記為主觀下線。
3.如果一個Master被標記為主觀下線,則正在監視這個Master的所有 Sentinel 要以每秒一次的頻率確認Master的確進入了主觀下線狀態。
4.當有足夠數量的 Sentinel(大於等於配置文件指定的值)在指定的時間范圍內確認Master的確進入了主觀下線狀態, 則Master會被標記為客觀下線
5.在一般情況下, 每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有Master,Slave發送 INFO 命令
6.當Master被 Sentinel 標記為客觀下線時,Sentinel 向下線的 Master 的所有 Slave 發送 INFO 命令的頻率會從 10 秒一次改為每秒一次
7.若沒有足夠數量的 Sentinel 同意 Master 已經下線, Master 的客觀下線狀態就會被移除。若 Master 重新向 Sentinel 的 PING 命令返回有效回復, Master 的主觀下線狀態就會被移除。
擴展閱讀