Redis常見的應用場景解析

Redis是一個key-value存儲系統，如今在各類系統中的使用愈來愈多，大部分狀況下是由於其高性能的特性，被當作緩存使用，這裏介紹下Redis常常遇到的使用場景。

Redis特性

一個產品的使用場景確定是須要根據產品的特性，先列舉一下Redis的特色：

• 讀寫性能優異
• 持久化
• 數據類型豐富
• 單線程
• 數據自動過時
• 發佈訂閱
• 分佈式

這裏咱們經過幾個場景，不一樣維度說下Redis的應用。

高性能適合當作緩存

緩存是Redis最多見的應用場景，之全部這麼使用，主要是由於Redis讀寫性能優異。並且逐漸有取代memcached，成爲首選服務端緩存的組件。並且，Redis內部是支持事務的，在使用時候能有效保證數據的一致性。
做爲緩存使用時，通常有兩種方式保存數據：

• 一、讀取前，先去讀Redis，若是沒有數據，讀取數據庫，將數據拉入Redis。
• 二、插入數據時，同時寫入Redis。

方案一：實施起來簡單，可是有兩個須要注意的地方：
一、避免緩存擊穿。（數據庫沒有就須要命中的數據，致使Redis一直沒有數據，而一直命中數據庫。）
二、數據的實時性相對會差一點。

方案二：數據實時性強，可是開發時不便於統一處理。
。

固然，兩種方式根據實際狀況來適用。如：方案一適用於對於數據實時性要求不是特別高的場景。方案二適用於字典表、數據量不大的數據存儲。

豐富的數據格式性能更高，應用場景豐富

Redis相比其餘緩存，有一個很是大的優點，就是支持多種數據類型。

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

其實，經過上面的數據類型的特性，基本就能想到合適的應用場景了。

• string——適合最簡單的k-v存儲，相似於memcached的存儲結構，短信驗證碼，配置信息等，就用這種類型來存儲。
• hash——通常key爲ID或者惟一標示，value對應的就是詳情了。如商品詳情，我的信息詳情，新聞詳情等。
• list——由於list是有序的，比較適合存儲一些有序且數據相對固定的數據。如省市區表、字典表等。由於list是有序的，適合根據寫入的時間來排序，如：最新的*，消息隊列等。
• set——能夠簡單的理解爲ID-List的模式，如微博中一我的有哪些好友，set最牛的地方在於，能夠對兩個set提供交集、並集、差集操做。例如：查找兩我的共同的好友等。
• Sorted Set——是set的加強版本，增長了一個score參數，自動會根據score的值進行排序。比較適合相似於top 10等不根據插入的時間來排序的數據。

如上所述，雖然Redis不像關係數據庫那麼複雜的數據結構，可是，也能適合不少場景，比通常的緩存數據結構要多。瞭解每種數據結構適合的業務場景，不只有利於提高開發效率，也能有效利用Redis的性能。

單線程能夠做爲分佈式鎖

談到Redis和Memcached 的區別，你們更多的是談到數據結構和持久化這兩個特性，其實還有一個比較大的區別就是：

• Redis 是單線程，多路複用方式提升處理效率。
• Memcached 是多線程的，經過CPU線程切換來提升處理效率。

因此Redis單線程的這個特性，其實也是很重要的應用場景，最經常使用的就是分佈式鎖。
應對高併發的系統，都是用多服務器部署，每一個技術框架針對數據鎖都有很好的處理方式，如 .net 的lock,java 的synchronized,都能經過鎖住某個對象來應對線程致使的數據污染問題。可是畢竟，只能控制本服務器的線程，分佈式部署之後數據污染問題，就比較難處理了。Redis的單線程這個特性，就很是符合這個需求，僞代碼以下：

//產生鎖
while lock!=1
    //過時時間是爲了不死鎖
    now = int(time.time())
    lock_timeout = now + LOCK_TIMEOUT + 1
    lock = redis_client.setnx(lock_key, lock_timeout)

//真正要處理的業務
doing() 

//釋放鎖
now = int(time.time())
if now < lock_timeout:
    redis_client.delete(lock_key)複製代碼

以上是一個只說明流程的僞代碼，其實總體的邏輯是很簡單的，只要考慮到死鎖時的狀況，就比較好處理了。Redis做爲分佈式鎖，由於其性能的優點，不會成爲瓶頸，通常會產生瓶頸的是真正的業務處理內容，仍是儘可能縮小鎖的範圍來確保系統性能。

自動過時能有效提高開發效率

Redis針對數據均可以設置過時時間，這個特色也是你們應用比較多的，過時的數據清理無需使用方去關注，因此開發效率也比較高，固然，性能也比較高。最多見的就是：短信驗證碼、具備時間性的商品展現等。無需像數據庫還要去查時間進行對比。由於使用比較簡單，就不贅述了。

分佈式和持久化有效應對海量數據和高併發

Redis初期的版本官方只是支持單機或者簡單的主從，大多應用則都是本身去開發集羣的中間件，可是隨着應用愈來愈普遍，用戶關於分佈式的呼聲愈來愈高，因此Redis 3.0版本時候官方加入了分佈式的支持，主要是兩個方面：

• Redis服務器主從熱備，確保系統穩定性
• Redis分片應對海量數據和高併發

並且Redis雖然是一個內存緩存，數據存在內存，可是Redis支持多種方式將數據持久化，寫入硬盤，全部，Redis數據的穩定性也是很是有保障的，結合Redis的集羣方案，有的系統已經將Redis當作一種NoSql數據存儲來適用。

示例：秒殺和Redis的結合

秒殺是如今互聯網系統中常見的營銷模式，做爲開發者，其實最不肯意這樣的活動，由於非技術人員沒法理解到其中的技術難度，致使在資源協調上老是有些誤差。秒殺其實常常會出現的問題包括：

• 併發過高致使程序阻塞。
• 庫存沒法有效控制，出現超賣的狀況。

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

• 數據儘可能緩存,阻斷用戶和數據庫的直接交互。
• 經過鎖來控制避免超賣現象。

如今說明一下，若是如今作一個秒殺，那麼，Redis應該如何結合進行使用?

• 提早預熱數據，放入Redis
• 商品列表放入Redis List
• 商品的詳情數據 Redis hash保存，設置過時時間
• 商品的庫存數據Redis sorted set保存
• 用戶的地址信息Redis set保存
• 訂單產生扣庫存經過Redis製造分佈式鎖，庫存同步扣除
• 訂單產生後發貨的數據，產生Redis list，經過消息隊列處理
• 秒殺結束後，再把Redis數據和數據庫進行同步

以上是一個簡略的秒殺系統和Redis結合的方案，固然實際可能還會引入http緩存，或者將消息對接用MQ代替等方案，也會出現業務遺漏的狀況，這個只是但願能拋磚引玉。

每一個技術都有屬於本身的應用場景，只有對技術的特色有必定清晰的認識，才能更好的利用技術，發揮其最大的優點。

---

歡迎你們關注個人公衆號交流、學習、第一時間獲取最新的文章。
微信號：itmifen