主頁 > 知識庫 > 深入解析Redis中常見的應(yīng)用場景

深入解析Redis中常見的應(yīng)用場景

熱門標簽:小紅書怎么地圖標注店 地圖標注費用 竹間科技AI電銷機器人 最簡單的百度地圖標注 西藏教育智能外呼系統(tǒng)價格 百度商家地圖標注怎么做 太原營銷外呼系統(tǒng) 玄武湖地圖標注 地圖標注如何即時生效

前言

Redis是一個key-value存儲系統(tǒng),現(xiàn)在在各種系統(tǒng)中的使用越來越多,大部分情況下是因為其高性能的特性,被當做緩存使用,這里介紹下Redis經(jīng)常遇到的使用場景。下面話不多說了,來一起看看詳細的介紹吧。

Redis特性

一個產(chǎn)品的使用場景肯定是需要根據(jù)產(chǎn)品的特性,先列舉一下Redis的特點:

  • 讀寫性能優(yōu)異
  • 持久化
  • 數(shù)據(jù)類型豐富
  • 單線程
  • 數(shù)據(jù)自動過期
  • 發(fā)布訂閱
  • 分布式

這里我們通過幾個場景,不同維度說下Redis的應(yīng)用。

高性能適合當做緩存

緩存是Redis最常見的應(yīng)用場景,之所有這么使用,主要是因為Redis讀寫性能優(yōu)異。而且逐漸有取代memcached,成為首選服務(wù)端緩存的組件。而且,Redis內(nèi)部是支持事務(wù)的,在使用時候能有效保證數(shù)據(jù)的一致性。
作為緩存使用時,一般有兩種方式保存數(shù)據(jù):

      1、讀取前,先去讀Redis,如果沒有數(shù)據(jù),讀取數(shù)據(jù)庫,將數(shù)據(jù)拉入Redis。

      2、插入數(shù)據(jù)時,同時寫入Redis。

方案一:實施起來簡單,但是有兩個需要注意的地方:

     1、避免緩存擊穿。(數(shù)據(jù)庫沒有就需要命中的數(shù)據(jù),導(dǎo)致Redis一直沒有數(shù)據(jù),而一直命中數(shù)據(jù)庫。)

     2、數(shù)據(jù)的實時性相對會差一點。

方案二:數(shù)據(jù)實時性強,但是開發(fā)時不便于統(tǒng)一處理。

當然,兩種方式根據(jù)實際情況來適用。如:方案一適用于對于數(shù)據(jù)實時性要求不是特別高的場景。方案二適用于字典表、數(shù)據(jù)量不大的數(shù)據(jù)存儲。

豐富的數(shù)據(jù)格式性能更高,應(yīng)用場景豐富

Redis相比其他緩存,有一個非常大的優(yōu)勢,就是支持多種數(shù)據(jù)類型。

數(shù)據(jù)類型 說明
string 字符串,最簡單的k-v存儲
hash hash格式,value為field和value,適合ID-Detail這樣的場景。
list 簡單的list,順序列表,支持首位或者末尾插入數(shù)據(jù)
set 無序list,查找速度快,適合交集、并集、差集處理
sorted set 有序的set

其實,通過上面的數(shù)據(jù)類型的特性,基本就能想到合適的應(yīng)用場景了。

  • string——適合最簡單的k-v存儲,類似于memcached的存儲結(jié)構(gòu),短信驗證碼,配置信息等,就用這種類型來存儲。
  • hash——一般key為ID或者唯一標示,value對應(yīng)的就是詳情了。如商品詳情,個人信息詳情,新聞詳情等。
  • list——因為list是有序的,比較適合存儲一些有序且數(shù)據(jù)相對固定的數(shù)據(jù)。如省市區(qū)表、字典表等。因為list是有序的,適合根據(jù)寫入的時間來排序,如:最新的***,消息隊列等。
  • set——可以簡單的理解為ID-List的模式,如微博中一個人有哪些好友,set最牛的地方在于,可以對兩個set提供交集、并集、差集操作。例如:查找兩個人共同的好友等。
  • Sorted Set——是set的增強版本,增加了一個score參數(shù),自動會根據(jù)score的值進行排序。比較適合類似于top 10等不根據(jù)插入的時間來排序的數(shù)據(jù)。

如上所述,雖然Redis不像關(guān)系數(shù)據(jù)庫那么復(fù)雜的數(shù)據(jù)結(jié)構(gòu),但是,也能適合很多場景,比一般的緩存數(shù)據(jù)結(jié)構(gòu)要多。了解每種數(shù)據(jù)結(jié)構(gòu)適合的業(yè)務(wù)場景,不僅有利于提升開發(fā)效率,也能有效利用Redis的性能。

單線程可以作為分布式鎖

談到Redis和Memcached 的區(qū)別,大家更多的是談到數(shù)據(jù)結(jié)構(gòu)和持久化這兩個特性,其實還有一個比較大的區(qū)別就是:

  • Redis 是單線程,多路復(fù)用方式提高處理效率。
  • Memcached 是多線程的,通過CPU線程切換來提高處理效率。

所以Redis單線程的這個特性,其實也是很重要的應(yīng)用場景,最常用的就是分布式鎖。

應(yīng)對高并發(fā)的系統(tǒng),都是用多服務(wù)器部署,每個技術(shù)框架針對數(shù)據(jù)鎖都有很好的處理方式,如 .net 的lock,java 的synchronized,都能通過鎖住某個對象來應(yīng)對線程導(dǎo)致的數(shù)據(jù)污染問題。但是畢竟,只能控制本服務(wù)器的線程,分布式部署

以后數(shù)據(jù)污染問題,就比較難處理了。Redis的單線程這個特性,就非常符合這個需求,偽代碼如下:

//產(chǎn)生鎖
while lock!=1
 //過期時間是為了避免死鎖
 now = int(time.time())
 lock_timeout = now + LOCK_TIMEOUT + 1
 lock = redis_client.setnx(lock_key, lock_timeout)

//真正要處理的業(yè)務(wù)
doing()

//釋放鎖
now = int(time.time())
if now  lock_timeout:
 redis_client.delete(lock_key)

以上是一個只說明流程的偽代碼,其實整體的邏輯是很簡單的,只要考慮到死鎖時的情況,就比較好處理了。Redis作為分布式鎖,因為其性能的優(yōu)勢,不會成為瓶頸,一般會產(chǎn)生瓶頸的是真正的業(yè)務(wù)處理內(nèi)容,還是盡量縮小鎖的范圍來確保系統(tǒng)性能。

自動過期能有效提升開發(fā)效率

Redis針對數(shù)據(jù)都可以設(shè)置過期時間,這個特點也是大家應(yīng)用比較多的,過期的數(shù)據(jù)清理無需使用方去關(guān)注,所以開發(fā)效率也比較高,當然,性能也比較高。最常見的就是:短信驗證碼、具有時間性的商品展示等。無需像數(shù)據(jù)庫還要去查時間進行對比。因為使用比較簡單,就不贅述了。

分布式和持久化有效應(yīng)對海量數(shù)據(jù)和高并發(fā)

Redis初期的版本官方只是支持單機或者簡單的主從,大多應(yīng)用則都是自己去開發(fā)集群的中間件,但是隨著應(yīng)用越來越廣泛,用戶關(guān)于分布式的呼聲越來越高,所以Redis 3.0版本時候官方加入了分布式的支持,主要是兩個方面:

  • Redis服務(wù)器主從熱備,確保系統(tǒng)穩(wěn)定性
  • Redis分片應(yīng)對海量數(shù)據(jù)和高并發(fā)

而且Redis雖然是一個內(nèi)存緩存,數(shù)據(jù)存在內(nèi)存,但是Redis支持多種方式將數(shù)據(jù)持久化,寫入硬盤,所有,Redis數(shù)據(jù)的穩(wěn)定性也是非常有保障的,結(jié)合Redis的集群方案,有的系統(tǒng)已經(jīng)將Redis當做一種NoSql數(shù)據(jù)存儲來適用。

示例:秒殺和Redis的結(jié)合

秒殺是現(xiàn)在互聯(lián)網(wǎng)系統(tǒng)中常見的營銷模式,作為開發(fā)者,其實最不愿意這樣的活動,因為非技術(shù)人員無法理解到其中的技術(shù)難度,導(dǎo)致在資源協(xié)調(diào)上總是有些偏差。秒殺其實經(jīng)常會出現(xiàn)的問題包括:

  1. 并發(fā)太高導(dǎo)致程序阻塞。
  2. 庫存無法有效控制,出現(xiàn)超賣的情況。

其實解決這些問題基本就兩個方案:

  • 數(shù)據(jù)盡量緩存,阻斷用戶和數(shù)據(jù)庫的直接交互。
  • 通過鎖來控制避免超賣現(xiàn)象。

現(xiàn)在說明一下,如果現(xiàn)在做一個秒殺,那么,Redis應(yīng)該如何結(jié)合進行使用?

  • 提前預(yù)熱數(shù)據(jù),放入Redis
  • 商品列表放入Redis List
  • 商品的詳情數(shù)據(jù) Redis hash保存,設(shè)置過期時間
  • 商品的庫存數(shù)據(jù)Redis sorted set保存
  • 用戶的地址信息Redis set保存
  • 訂單產(chǎn)生扣庫存通過Redis制造分布式鎖,庫存同步扣除
  • 訂單產(chǎn)生后發(fā)貨的數(shù)據(jù),產(chǎn)生Redis list,通過消息隊列處理
  • 秒殺結(jié)束后,再把Redis數(shù)據(jù)和數(shù)據(jù)庫進行同步

以上是一個簡略的秒殺系統(tǒng)和Redis結(jié)合的方案,當然實際可能還會引入http緩存,或者將消息對接用MQ代替等方案,也會出現(xiàn)業(yè)務(wù)遺漏的情況,這個只是希望能拋磚引玉。

總結(jié)

以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學(xué)習(xí)或者使用工作具有一定的參考學(xué)習(xí)價值,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。

您可能感興趣的文章:
  • redis數(shù)據(jù)類型及應(yīng)用場景知識點總結(jié)
  • 淺談Redis在微服務(wù)架構(gòu)中的幾種應(yīng)用場景
  • Redis的11種Web應(yīng)用場景簡介
  • Redis數(shù)據(jù)庫的應(yīng)用場景介紹
  • 淺談Redis在直播場景的實踐方案
  • 淺談redis五大數(shù)據(jù)結(jié)構(gòu)和使用場景
  • Redis數(shù)據(jù)庫的使用場景介紹(避免誤用Redis)
  • Redis中5種數(shù)據(jù)結(jié)構(gòu)的使用場景介紹
  • 了解Redis常見應(yīng)用場景

標簽:廣東 澳門 香港 林芝 唐山 贛州 揚州 景德鎮(zhèn)

巨人網(wǎng)絡(luò)通訊聲明:本文標題《深入解析Redis中常見的應(yīng)用場景》,本文關(guān)鍵詞  深入,解析,Redis,中,常見,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《深入解析Redis中常見的應(yīng)用場景》相關(guān)的同類信息!
  • 本頁收集關(guān)于深入解析Redis中常見的應(yīng)用場景的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章