首頁  >  文章  >  資料庫  >  redis適合哪些應用場景

redis適合哪些應用場景

anonymity
anonymity原創
2019-06-05 16:38:306186瀏覽

Redis是一個開源的使用ANSI C語言編寫、支援網路、可基於記憶體亦可持久化的日誌型、Key-Value資料庫,並提供多種語言的API。

redis適合哪些應用場景

Redis有許多應用程式場景,這個簡單先列舉7個應用場景:

一:快取——熱數據

熱點數據(經常會被查詢,但是不經常被修改或刪除的數據),首選是使用redis緩存,畢竟強大到冒泡的QPS和極強的穩定性不是所有類似工具都有的,而且相比於memcached還提供了豐富的資料型別可以使用,另外,記憶體中的資料也提供了AOF和RDB等持久化機制可以選擇,要冷、熱的還是忽冷忽熱的都可選。

結合特定應用程式需要注意一下:很多人用spring的AOP來建構redis快取的自動生產和清除,過程可能如下:

Select 資料庫前查詢redis,有的話使用redis數據,放棄select 資料庫,沒有的話,select 資料庫,然後將資料插入redis

update或delete資料庫錢,查詢redis是否存在該數據,存在的話先刪除redis中數據,然後再update或delete資料庫中的資料

上面這種操作,如果並發量很小的情況下基本沒問題,但是高並發的情況請注意下面場景:

為了update先刪掉了redis中的該數據,這時候另一個線程執行查詢,發現redis中沒有,瞬間執行了查詢SQL,並且插入到redis中一條數據,回到剛才那個update語句,這個悲催的線程壓根不知道剛才那個該死的select線程犯了一個彌天大錯!於是這個redis中的錯誤資料就永遠的存在了下去,直到下一個update或delete。

二:計數器

諸如統計點擊數等應用程式。由於單線程,可以避免並發問題,保證不會出錯,而且100%毫秒級效能!爽。

指令:INCRBY

別忘記持久化,畢竟是redis只是存了記憶體!

三:佇列

相當於訊息系統,ActiveMQ,RocketMQ等工具類似,但是個人覺得簡單用一下還行,如果對於資料一致性要求高的話還是用RocketMQ等專業系統。

由於redis把資料加入佇列是傳回新增元素在佇列的第幾位,所以可以做判斷使用者是第幾個存取這種業務

佇列不僅可以把並發請求變成串行,也可以做佇列或堆疊使用

四:位元運算(大資料處理)

用於資料量上億的場景下,例如數億用戶系統的簽到,去重登入次數統計,某用戶是否在線上狀態等等。

原理是:

redis內建立一個足夠長的數組,每個數組元素只能是0和1兩個值,然後這個數組的下標index用來表示我們上面例子裡面的使用者id(必須是數字哈),那麼很顯然,這個幾億長的大數組就能透過下標和元素值(0和1)來建構一個記憶系統,上面我說的幾個場景也就能夠實現。用到的指令是:setbit、getbit、bitcount

五:分散式鎖與單執行緒機制

驗證前端的重複請求(可以自由擴充類似情況) ,可以透過redis進行過濾:每次請求將request Ip、參數、介面等hash作為key儲存redis(冪等性請求),設定多長時間有效期,然後下次請求過來的時候先在redis中檢索有沒有這個key,進而驗證是不是一定時間內過來的重複提交

秒殺系統,基於redis是單線程特徵,防止出現資料庫「爆破」

##全域增量ID生成,類似「秒殺」


六:最新列表

例如新聞列表頁面最新的新聞列表,如果總數量很大的情況下,盡量不要使用select a from A limit 10這種low貨,試試redis的LPUSH指令建構List,一個個順序都塞進去就可以啦。不過萬一內存清掉了咋辦?也簡單,查詢不到儲存key的話,用mysql查詢並且初始化一個List到redis中就好了。

七:排行榜

誰得分高誰排名往上。指令:ZADD(有續集,sorted set)

以上是redis適合哪些應用場景的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn