'Redis的8大應用場景,你知道幾個?'

"
"
Redis的8大應用場景,你知道幾個?

Redis開創了一種新的數據存儲思路。使用Redis,我們不用在面對功能單調的數據庫時,把精力放在如何把大象放進冰箱這樣的問題上,而是利用Redis靈活多變的數據結構和數據操作,為不同的大象構建不同的冰箱。

一、為什麼使用?

解決應用服務器的CPU和內存壓力;
減少IO的讀操作,減輕IO的壓力;
關係型數據庫的擴展性不強,難以改變表結構;

二、優點:

Nosql數據庫沒有關聯關係,數據結構簡單,拓展表比較容易;
Nosql讀取速度快,對較大數據處理快;

1、緩存

緩存現在幾乎是所有中大型網站都在用的必殺技,合理的利用緩存不僅能夠提升網站訪問速度,還能大大降低數據庫的壓力。Redis提供了鍵過期功能,也提供了靈活的鍵淘汰策略,所以,現在Redis用在緩存的場合非常多。

2、排行榜

很多網站都有排行榜應用的,如淘寶的月度銷量榜單、商品按時間的上新排行榜等。Redis提供的有序集合數據類構能實現各種複雜的排行榜應用。

3、計數器

什麼是計數器,如電商網站商品的瀏覽量、視頻網站視頻的播放數等。為了保證數據實時效,每次瀏覽都得給+1,併發量高時如果每次都請求數據庫操作無疑是種挑戰和壓力。Redis提供的incr命令來實現計數器功能,內存操作,性能非常好,非常適用於這些計數場景。

4、分佈式會話

集群模式下,在應用不多的情況下一般使用容器自帶的session複製功能就能滿足,當應用增多相對複雜的系統中,一般都會搭建以Redis等內存數據庫為中心的session服務,session不再由容器管理,而是由session服務及內存數據庫管理。

5、分佈式鎖

在很多互聯網公司中都使用了分佈式技術,分佈式技術帶來的技術挑戰是對同一個資源的併發訪問,如全局ID、減庫存、秒殺等場景,併發量不大的場景可以使用數據庫的悲觀鎖、樂觀鎖來實現,但在併發量高的場合中,利用數據庫鎖來控制資源的併發訪問是不太理想的,大大影響了數據庫的性能。可以利用Redis的setnx功能來編寫分佈式的鎖,如果設置返回1說明獲取鎖成功,否則獲取鎖失敗,實際應用中要考慮的細節要更多。

6、 社交網絡

點贊、踩、關注/被關注、共同好友等是社交網站的基本功能,社交網站的訪問量通常來說比較大,而且傳統的關係數據庫類型不適合存儲這種類型的數據,Redis提供的哈希、集合等數據結構能很方便的的實現這些功能。

7、最新列表

Redis列表結構,LPUSH可以在列表頭部插入一個內容ID作為關鍵字,LTRIM可用來限制列表的數量,這樣列表永遠為N個ID,無需查詢最新的列表,直接根據ID去到對應的內容頁即可。

8、消息系統

消息隊列是大型網站必用中間件,如ActiveMQ、RabbitMQ、Kafka等流行的消息隊列中間件,主要用於業務解耦、流量削峰及異步處理實時性低的業務。Redis提供了發佈/訂閱及阻塞隊列功能,能實現一個簡單的消息隊列系統。另外,這個不能和專業的消息中間件相比。

Redis的8個應用場景

一:緩存—熱數據

熱點數據(經常會被查詢,但是不經常被修改或者刪除的數據),首選是使用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

三:隊列

相當於消息系統,ActiveMQ,RocketMQ等工具類似,如果對於數據一致性要求高的話還是用RocketMQ等專業系統。

由於redis把數據添加到隊列是返回添加元素在隊列的第幾位,所以可以做判斷用戶是第幾個訪問這種業務;隊列不僅可以把併發請求變成串行,並且還可以做隊列或者棧使用。

四:位操作(大數據處理)

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

想想一下騰訊10億用戶,要幾個毫秒內查詢到某個用戶是否在線,你能怎麼做?這裡要用到位操作——使用setbit、getbit、bitcount命令。

原理是:

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)

八: 適用場景:

數據高併發的讀寫;

海量數據的讀寫;

對擴展性要求高的數據。

最後:

如有錯誤歡迎指正!

個人公眾號:Java技術zhai

"

相關推薦

推薦中...