從一個小需求感受Redis的獨特魅力(需求設(shè)計)-創(chuàng)新互聯(lián)

分享一個簡單的小需求應(yīng)該怎么設(shè)計實現(xiàn)以及有關(guān)Redis的使用

成都創(chuàng)新互聯(lián)從2013年成立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目網(wǎng)站設(shè)計、成都網(wǎng)站制作網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元鐵力做網(wǎng)站,已為上家服務(wù),為鐵力各地企業(yè)和個人服務(wù),聯(lián)系電話:13518219792

Redis在實際應(yīng)用中使用的非常廣泛，本篇文章就從一個簡單的需求說起，為你講述一個需求是如何從頭到尾開始做的，又是如何一步步完善的。之前寫過一篇《如何實現(xiàn)頁面廣告隨時上下線、過期自動下線及到時自動上線》，也涉及到了Redis在項目中的實際應(yīng)用，有興趣的可以看一下。

需求

設(shè)定，現(xiàn)在我們有一個APP，產(chǎn)品新提出一個叫“程序員樹洞”的功能，具體功能就不說了，其中這個功能有一點需要做的是在使用該功能時，如果是首次進入會展示一個協(xié)議頁面，用戶需要勾選后點確定才能進入功能，此后再進該功能，不再顯示協(xié)議頁直接進入該功能。如下圖所示，

需求分析

需求就是這么的簡單，我們來分析一下。

1、用戶點擊該功能時前端需要知道該給用戶顯示哪個頁面，這一步需要請求后端接口，后臺告訴前端這個用戶有沒有同意過協(xié)議。

2、用戶勾選協(xié)議點確定，后端需要記錄這步操作(記錄用戶已經(jīng)同意協(xié)議)，這一步需在點確定時前端請求后端接口。

概要設(shè)計

前面需求分析里說了，后端需要告訴前端用戶有沒有統(tǒng)一過協(xié)議，所以后端需要把這個信息記錄下來，最好是記錄到數(shù)據(jù)庫保存，那就需要一張表來記錄同意過協(xié)議的用戶。表結(jié)構(gòu)大致是：id，客戶號，插入時間。

詳細設(shè)計

1、記錄客戶是否已同意過協(xié)議并提供查詢功能（查詢是否同意過協(xié)議）

2、沒有同意過的和同意過的用戶信息怎么存儲

3、如何高效的查詢是否同意過

4、怎么保證高并發(fā)下服務(wù)的可用性，數(shù)據(jù)庫的可用性

功能實現(xiàn)

后端提供兩個接口，

1、hasAgree()，查詢該用戶是否已同意協(xié)議

2、recordAgree()，記錄用戶已同意協(xié)議

第一版 Just DB

很容易嘛！不就是CRUD嗎，小意思。用戶進來先查數(shù)據(jù)庫有沒有記錄，沒有返回用戶沒有同意過協(xié)議，前端給用戶展示協(xié)議頁，否則展示功能頁；用戶點同意后，后臺記錄用戶已點了同意協(xié)議，記錄到庫。一個查詢一個插入，5分鐘搞定嘛。

第二版 引入Redis緩存

考慮到每次查庫很浪費，那我們使用緩存好不好? 進來先查緩存有沒有對應(yīng)的數(shù)據(jù)，緩存里有就直接返回，沒有則查庫，庫里有就存緩存。這樣redis就分擔(dān)了一部分數(shù)據(jù)庫的壓力。

第三版 解決緩存穿透

隨著客戶量的增加，點擊這個功能的次數(shù)、頻率越來越高，假如有人頻繁點擊該功能，彈出協(xié)議后，退出，再點，再退出…就是不點確定

這樣的話后臺緩存中沒有，數(shù)據(jù)庫中也沒有，每次都會走數(shù)據(jù)庫，繞過了緩存，直接都走數(shù)據(jù)庫，這類請求量多了也是個問題，這就是緩存穿透。所以第三版，我們來解決緩存穿透的問題。

解決緩存穿透：因為是數(shù)據(jù)庫和緩存都沒有，我們可以讓數(shù)據(jù)庫沒有的也存到redis。需要改變redis的數(shù)據(jù)類型，由set改為map，目的是記錄狀態(tài)值。

第四版 緩存預(yù)熱防止緩存擊穿

另一個關(guān)于緩存的問題，那就是緩存擊穿。

何為緩存擊穿？假如該功能在前期宣傳力度比較大，或預(yù)計該功能上線后點擊量比較大的話，那么在功能上線后很可能就會一瞬間大量用戶來點擊這個功能，因為我們前面的邏輯是首次進入該功能的用戶展示協(xié)議頁，我們的后臺處理雖然加了redis緩存，但是新上的功能所有用戶都沒有點過，那么redis里就沒有緩存，是不是所有用戶的請求都落到數(shù)據(jù)庫了？一旦瞬間流量非常大，數(shù)據(jù)庫安全性就存在隱患，有被搞垮的可能。

所以怎么解決呢？我們可以在該功能上線前，提前將需要做緩存的數(shù)據(jù)放入redis，即緩存預(yù)熱。

如何預(yù)熱？將所有用戶的信息都放到redis.舉個栗子（也許不是最佳的），我們使用Redis的hash數(shù)據(jù)結(jié)構(gòu)，key-field-value。key我們可以固定一個字符串如coderTreeHole_Agreement_Check，field我們可以用客戶號（唯一），value是個標志位，用0代表沒同意過協(xié)議，1代表同意過。一般在電商大促前都會對熱點key進行預(yù)熱，不然真的扛不住。

redis3.0上加入了cluster模式，實現(xiàn)的redis的分布式存儲，也就是說每臺redis節(jié)點上存儲不同的內(nèi)容。在redis的每一個節(jié)點上，都有這么兩個東西，一個是插槽（slot），它的的取值范圍是：0-16383。還有一個就是cluster，可以理解為是一個集群管理的插件。當(dāng)我們的存取的key到達的時候，redis會根據(jù)crc16的算法得出一個結(jié)果，然后把結(jié)果對16384求余數(shù)，這樣每個key都會對應(yīng)一個編號在0-16383之間的哈希槽，通過這個值，去找到對應(yīng)的插槽所對應(yīng)的節(jié)點，然后直接自動跳轉(zhuǎn)到這個對應(yīng)的節(jié)點上進行存取操作。

看了上面這段話，明白了吧。那對于這個大key而且是熱點key的請求，是不是都落到某一個redis節(jié)點上了？大key會帶來很多問題，篇幅原因以后再來細說，跑題了。。。

針對這個需求，你還有什么方法防治緩存擊穿？

第五版 消息隊列削峰填谷

可以看到我們上面的設(shè)計其實都是實時對數(shù)據(jù)庫進行操作的。

例如，當(dāng)用戶點了同意，前端就調(diào)后臺的recordAgree方法將該記錄記錄到數(shù)據(jù)庫，即這條記錄是立馬插入到數(shù)據(jù)庫的。

如果剛上線這個功能，大量用戶同時點這個功能，并發(fā)量大的話，請求走到后臺，那么寫庫的操作就非常多，數(shù)據(jù)庫連接數(shù)突然激增，數(shù)據(jù)庫會頂不住吧。

所以為避免流量集中落到數(shù)據(jù)庫，此時我們可以使用消息隊列MQ。將插入操作的請求發(fā)往消息隊列，使插入操作以一定的速率到數(shù)據(jù)庫執(zhí)行，使得對數(shù)據(jù)庫的請求數(shù)盡量平滑，消息發(fā)給消息隊列立即返回給前端成功，不用等待插庫完成，用MQ實現(xiàn)了異步解耦，削峰填谷。

到這你是不是忍不住說設(shè)計的真贊~~

另外MQ的使用注意的點還是非常多的，如：消息隊列的消息重復(fù)消費問題，順序問題，事務(wù)消息等。

總結(jié)

對于這個需求設(shè)計到哪種程度取決于你的用戶量和并發(fā)量，如果是像雙十一那樣，肯定是要用消息隊列的，那一般小的例如，用戶量1千萬，日活10萬，請求最集中的也就是中午9-12點，下午13-17點吧，差不多8個小時，平均一個小時1.25萬，用戶都來點這個功能的話，每分鐘208，每秒3.5，算不上高并發(fā)，數(shù)據(jù)庫完全扛得住。

總結(jié)一下，這個需求我們用到的知識點（敲黑板），redis數(shù)據(jù)緩存，redis緩存穿透，緩存擊穿，熱點key問題，redis大key問題（沒具體講），消息隊列異步解耦等。

畫圖碼字不易，如果覺得我寫的還可以，記得點贊鼓勵一下哦，如果覺得有問題歡迎指正。

好了，就給大家介紹這么多。

文章名稱：從一個小需求感受Redis的獨特魅力(需求設(shè)計)-創(chuàng)新互聯(lián)
本文鏈接：http://muchs.cn/article12/cdsjdc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供靜態(tài)網(wǎng)站、網(wǎng)站營銷、手機網(wǎng)站建設(shè)、外貿(mào)建站、虛擬主機、微信小程序

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)