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的結合
秒殺是現在互聯網系統中常見的營銷模式，作為開發者，其實最不願意這樣的活動，因為非技術人員無法理解到其中的技術難度，導致在資源協調上總是有些偏差。秒殺其實經常會出現的問題包括：
併發太高導致程序阻塞。
庫存無法有效控制，出現超賣的情況。
其實解決這些問題基本就兩個方案：
數據儘量緩存,阻斷用戶和數據庫的直接交互。
通過鎖來控制避免超賣現象。
現在說明一下，如果現在做一個秒殺，那麼，Redis應該如何結合進行使用?
提前預熱數據，放入Redis
商品列表放入Redis List
商品的詳情數據 Redis hash保存，設置過期時間
商品的庫存數據Redis sorted set保存
用戶的地址信息Redis set保存
訂單產生扣庫存通過Redis製造分佈式鎖，庫存同步扣除
訂單產生後發貨的數據，產生Redis list，通過消息隊列處理
秒殺結束後，再把Redis數據和數據庫進行同步
以上是一個簡略的秒殺系統和Redis結合的方案，當然實際可能還會引入http緩存，或者將消息對接用MQ代替等方案，也會出現業務遺漏的情況，這個只是希望能拋磚引玉。
每個技術都有屬於自己的應用場景，只有對技術的特點有一定清晰的認識，才能更好的利用技術，發揮其最大的優勢。
作者：IT米粉
相關推薦
