redis應(yīng)用場景總結(jié)redis平時我們用到的地方蠻多的竿滨，下面就了解的應(yīng)用場景做個總結(jié)：
1温峭、熱點數(shù)據(jù)的緩存
由于redis訪問速度塊攻泼、支持的數(shù)據(jù)類型比較豐富揖赴，所以redis很適合用來存儲熱點數(shù)據(jù)，另外結(jié)合expire竭钝，我們可以設(shè)置過期時間然后再進行緩存更新操作梨撞，這個功能最為常見，我們幾乎所有的項目都有所運用蜓氨。
2聋袋、限時業(yè)務(wù)的運用
redis中可以使用expire命令設(shè)置一個鍵的生存時間，到時間后redis會刪除它穴吹。利用這一特性可以運用在限時的優(yōu)惠活動信息幽勒、手機驗證碼等業(yè)務(wù)場景。
3港令、計數(shù)器相關(guān)問題
redis由于incrby命令可以實現(xiàn)原子性的遞增啥容，所以可以運用于高并發(fā)的秒殺活動锈颗、分布式序列號的生成、具體業(yè)務(wù)還體現(xiàn)在比如限制一個手機號發(fā)多少條短信咪惠、一個接口一分鐘限制多少請求击吱、一個接口一天限制調(diào)用多少次等等。
4遥昧、排行榜相關(guān)問題
關(guān)系型數(shù)據(jù)庫在排行榜方面查詢速度普遍偏慢覆醇，所以可以借助redis的SortedSet進行熱點數(shù)據(jù)的排序。
在奶茶活動中炭臭，我們需要展示各個部門的點贊排行榜永脓， 所以我針對每個部門做了一個SortedSet,然后以用戶的openid作為上面的username,以用戶的點贊數(shù)作為上面的score, 然后針對每個用戶做一個hash,通過zrangebyscore就可以按照點贊數(shù)獲取排行榜，然后再根據(jù)username獲取用戶的hash信息鞋仍，這個當時在實際運用中性能體驗也蠻不錯的常摧。
5、分布式鎖
這個主要利用redis的setnx命令進行威创，setnx："set if not exists"就是如果不存在則成功設(shè)置緩存同時返回1落午，否則返回0 ，這個特性在俞你奔遠方的后臺中有所運用肚豺，因為我們服務(wù)器是集群的溃斋，定時任務(wù)可能在兩臺機器上都會運行，所以在定時任務(wù)中首先 通過setnx設(shè)置一個lock详炬，如果成功設(shè)置則執(zhí)行盐类，如果沒有成功設(shè)置寞奸，則表明該定時任務(wù)已執(zhí)行呛谜。 當然結(jié)合具體業(yè)務(wù)，我們可以給這個lock加一個過期時間枪萄，比如說30分鐘執(zhí)行一次的定時任務(wù)隐岛，那么這個過期時間設(shè)置為小于30分鐘的一個時間 就可以，這個與定時任務(wù)的周期以及定時任務(wù)執(zhí)行消耗時間相關(guān)瓷翻。
當然我們可以將這個特性運用于其他需要分布式鎖的場景中聚凹，結(jié)合過期時間主要是防止死鎖的出現(xiàn)。
6齐帚、延時操作
這個目前我做過相關(guān)測試妒牙，但是還沒有運用到我們的實際項目中，下面我舉個該特性的應(yīng)用場景对妄。 比如在訂單生產(chǎn)后我們占用了庫存湘今，10分鐘后去檢驗用戶是夠真正購買，如果沒有購買將該單據(jù)設(shè)置無效剪菱，同時還原庫存摩瞎。 由于redis自2.8.0之后版本提供Keyspace Notifications功能拴签，允許客戶訂閱Pub/Sub頻道，以便以某種方式接收影響Redis數(shù)據(jù)集的事件旗们。 所以我們對于上面的需求就可以用以下解決方案蚓哩，我們在訂單生產(chǎn)時，設(shè)置一個key上渴，同時設(shè)置10分鐘后過期岸梨， 我們在后臺實現(xiàn)一個監(jiān)聽器，監(jiān)聽key的實效稠氮，監(jiān)聽到key失效時將后續(xù)邏輯加上盛嘿。 當然我們也可以利用rabbitmq、activemq等消息中間件的延遲隊列服務(wù)實現(xiàn)該需求括袒。
7次兆、分頁、模糊搜索
redis的set集合中提供了一個zrangebylex方法锹锰，語法如下：
ZRANGEBYLEX key min max [LIMIT offset count]
通過ZRANGEBYLEX zset - + LIMIT 0 10 可以進行分頁數(shù)據(jù)查詢芥炭，其中- +表示獲取全部數(shù)據(jù)
zrangebylex key min max 這個就可以返回字典區(qū)間的數(shù)據(jù)，利用這個特性可以進行模糊查詢功能恃慧，這個也是目前我在redis中發(fā)現(xiàn)的唯一一個支持對存儲內(nèi)容進行模糊查詢的特性园蝠。
前幾天我通過這個特性，對學(xué)校數(shù)據(jù)進行了模擬測試痢士，學(xué)校數(shù)據(jù)60萬左右彪薛，響應(yīng)時間在700ms左右，比mysql的like查詢稍微快一點怠蹂，但是由于它可以避免大量的數(shù)據(jù)庫io操作善延，所以總體還是比直接mysql查詢更利于系統(tǒng)的性能保障。
8城侧、點贊易遣、好友等相互關(guān)系的存儲
Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在于set是可以自動排重的嫌佑，當你需要存儲一個列表數(shù)據(jù)豆茫，又不希望出現(xiàn)重復(fù)數(shù)據(jù)時，set是一個很好的選擇屋摇，并且set提供了判斷某個成員是否在一個set集合內(nèi)的重要接口揩魂，這個也是list所不能提供的。 又或者在微博應(yīng)用中炮温，每個用戶關(guān)注的人存在一個集合中火脉，就很容易實現(xiàn)求兩個人的共同好友功能。
這個在奶茶活動中有運用，就是利用set存儲用戶之間的點贊關(guān)聯(lián)的忘分，另外在點贊前判斷是否點贊過就利用了sismember方法棋枕，當時這個接口的響應(yīng)時間控制在10毫秒內(nèi)，十分高效妒峦。
9重斑、隊列
由于redis有l(wèi)ist push和list pop這樣的命令，所以能夠很方便的執(zhí)行隊列操作肯骇。
