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

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

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

單線程可以作為分布式鎖

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

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

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

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

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

//產(chǎn)生鎖
while lock!=1
 //過期時(shí)間是為了避免死鎖
 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)

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

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

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

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

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

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

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

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

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

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

其實(shí)解決這些問題基本就兩個(gè)方案：

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

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

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

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

總結(jié)

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