前言

Redis是一個key-value儲存系統，現在在各種系統中的使用越來越多，大部分情況下是因為其高效能的特性，被當做快取使用，這裡介紹下Redis經常遇到的使用場景。下面話不多說了，來一起看看詳細的介紹吧。

Redis特性

一個產品的使用場景肯定是需要根據產品的特性，先列舉一下Redis的特點：

• 讀寫效能優異
• 持久化
• 資料型別豐富
• 單執行緒
• 資料自動過期
• 釋出訂閱
• 分散式

這裡我們通過幾個場景，不同維度說下Redis的應用。

高效能適合當做快取

快取是Redis最常見的應用場景，之所有這麼使用，主要是因為Redis讀寫效能優異。而且逐漸有取代memcached，成為首選服務端快取的元件。而且，Redis內部是支援事務的，在使用時候能有效保證資料的一致性。

1、讀取前，先去讀Redis，如果沒有資料，讀取資料庫，將資料拉入Redis。

2、插入資料時，同時寫入Redis。

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

1、避免快取擊穿。（資料庫沒有就需要命中的資料，導致Redis一直沒有資料，而一直命中資料庫。）

2、資料的實時性相對會差一點。

方案二：資料實時性強，但是開發時不便於統一處理。

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

豐富的資料格式效能更高，應用場景豐富

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的結合

秒殺是現在網際網路系統中常見的營銷模式，作為開發者，其實最不願意這樣的活動，因為非技術人員無法理解到其中的技術難度，導致在資源協調上總是有些偏差。秒殺其實經常會出現的問題包括：

1. 併發太高導致程式阻塞。
2. 庫存無法有效控制，出現超賣的情況。

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

• 資料儘量快取,阻斷使用者和資料庫的直接互動。
• 通過鎖來控制避免超賣現象。

現在說明一下，如果現在做一個秒殺，那麼，Redis應該如何結合進行使用?

• 提前預熱資料，放入Redis
• 商品列表放入Redis List
• 商品的詳情資料 Redis hash儲存，設定過期時間
• 商品的庫存資料Redis sorted set儲存
• 使用者的地址資訊Redis set儲存
• 訂單產生扣庫存通過Redis製造分散式鎖，庫存同步扣除
• 訂單產生後發貨的資料，產生Redis list，通過訊息佇列處理
• 秒殺結束後，再把Redis資料和資料庫進行同步

以上是一個簡略的秒殺系統和Redis結合的方案，當然實際可能還會引入http快取，或者將訊息對接用MQ代替等方案，也會出現業務遺漏的情況，這個只是希望能拋磚引玉。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者使用工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對我們的支援。