在redis中使用 expire 命令設定乙個鍵的過期時間後redis會自動刪除它.
expire key seconds
(seconds單位是秒,必須是整數)
檢視見還有多久被刪除:ttl key
取消鍵的過期事件設定:persist key
為該鍵重新賦值也會清除鍵的過期時間
pexpire key msec
(msec單位是毫秒)
expireat key unix
(使用unix時間作為鍵的過期時間)
pexpireat key unix
(時間單位是毫秒)
127.0.0.1:6379> set foo '李白乘舟將欲行'
ok127.0.0.1:6379> expire foo 300
1127.0.0.1:6379> ttl foo
293127.0.0.1:6379> ttl foo
248127.0.0.1:6379> persist foo
1127.0.0.1:6379> ttl foo
-1
減輕伺服器壓力,限制每個使用者(以ip計)一段時間最大訪問量.
例如要限制每分鐘每個使用者最多只能訪問100個頁面:
對每個訪問使用者使用乙個名為 rate.limiting:使用者ip 的字串型別鍵,每次
使用者訪問則使用incr命令遞增該鍵的鍵值.如果遞增後的值是1(第一次訪問頁面),則
同時還要設定該鍵的過期時間為1分鐘.這樣每次使用者訪問頁面時都讀取該鍵的鍵
值,如果超過100就表明該使用者的訪問頻率超過了限制,需要提示使用者稍後訪問.該
鍵每分鐘會自動刪除,所以下一分鐘使用者的訪問次數又會重新計算.
偽**:
$iskeyexists = exists rate.limiting:$ip
if $iskeyexists is 1
$times = incr rate.limiting:$ip
if $times > 100
print 訪問頻率超過了限制,請稍後再試
exit
else
multi
incr rate.limiting:$ip
expire $keyname, 60
exec
4.2.2中偽**問題:只能限制從計數開始的這一分鐘內次數,不能限制任意一分鐘內訪
問次數.偽**:
$listlength = llen rate.limiting:$ip
if $listlength < 10
lpush rate.limiting:$ip, now()
else
$time = lindex rate.limiting:$ip, -1
if now() - $time < 60
print 訪問頻率超過了限制,請稍後再試
exit
else
lpush rate.limiting:$ip, now()
ltrim rate.limiting:$ip, 0, 9
問題:
占用較多的儲存空間
出現競態條件
為了提高**的負載能力,常常將一些訪問頻率較高但是對cpu或io資源消耗較大
的操作的結果快取起來,並希望這些快取過一段時間自動過期.
例如教務**對全校所有學生各個科目成績彙總排名,並在首頁顯示錢10名的學生
姓名,偽**:
$rank = get cache:rank
if not $rank
$rank = 計算排名
multi
set cache:rank, $rank
expire cache:rank 7200
exec
問題:
伺服器記憶體有限時,如果大量使用快取鍵且過期時間設定得過長會導致redis
佔滿記憶體
把redis快取鍵過期時間設得太短,導致快取命中率過低且大量記憶體閒置
表4-1 redis支援淘汰鍵的規則
規則說明
volatile-lru
使用lru演算法刪除乙個鍵(只對設定了過期時間的鍵)
allkeys-lru
使用lru演算法刪除乙個鍵
volatile-random
隨機刪除乙個鍵(只對設定了過期時間的鍵)
allkeys-random
隨機刪除乙個鍵
volatile-ttl
刪除過期時間最近的乙個鍵
noeviction
不刪除鍵,只返回錯誤
maxmemory-policy
支援的規則如上表所示.其中lru演算法即"最近最少使用".
redid過期策略 redis高階 過期刪除策略
講到redis的過期刪除策略,就不得不說一下redis是如何判斷鍵是否過期,讓我們首先來了解下redis內部結構是如何儲存鍵與過期時間之間的關係 過期字典 在redisclient裡redisdb結構中儲存著乙個expires字典 key value 專門用來儲存過期時間,如下所示 typedef ...
Redis自學筆記 4 4高階 訊息通知
傳遞任務的佇列.與任務佇列進行互動的實體有兩類,一類是生產者,一類是消費者.生產者將需要處理的任務放入任務佇列中,二消費者不斷從任務佇列中讀入任務 資訊並執行.優點 松耦合 生產者和消費者無需知道彼此實現的細節 易於擴充套件 消費者可以有多個,而且可以分布在不同伺服器 3.4.2節中的lpush和r...
redis 高階功能,過期事件監聽
不談應用場景的技術都是道聽途說 這個問題解決的方案就有多種了,我們可以通過mq來進行,現在大多的mq都帶有死信佇列的機制,我們可以通過這個機制來完成,其次也可以通過quartz的輪詢方式的完成,過程不表選擇合適的應對當前的需求即可。當然本次主要是解決第乙個需求,所以只談如何使用redis來解決。3....