從一個小需求感覺Redis的獨特魅力

分享一個簡單的小需求應該怎麼設計實現以及有關Redis的使用

Redis在實際應用中使用的很是普遍，本篇文章就從一個簡單的需求提及，爲你講述一個需求是如何從頭至尾開始作的，又是如何一步步完善的。

需求

設定，如今咱們有一個APP，產品新提出一個叫「程序員樹洞」的功能，具體功能就不說了，其中這個功能有一點須要作的是在使用該功能時，若是是首次進入會展現一個協議頁面，用戶須要勾選後點肯定才能進入功能，此後再進該功能，再也不顯示協議頁直接進入該功能。以下圖所示，

原型圖

需求分析

需求就是這麼的簡單，咱們來分析一下。
一、用戶點擊該功能時前端須要知道該給用戶顯示哪一個頁面，這一步須要請求後端接口，後臺告訴前端這個用戶有沒有贊成過協議。
二、用戶勾選協議點肯定，後端須要記錄這步操做(記錄用戶已經贊成協議)，這一步需在點肯定時前端請求後端接口。

概要設計

前面需求分析裏說了，後端須要告訴前端用戶有沒有統一過協議，因此後端須要把這個信息記錄下來，最好是記錄到數據庫保存，那就須要一張表來記錄贊成過協議的用戶。表結構大體是：id，客戶號，插入時間。

詳細設計

一、記錄客戶是否已贊成過協議並提供查詢功能（查詢是否贊成過協議）
二、沒有贊成過的和贊成過的用戶信息怎麼存儲
三、如何高效的查詢是否贊成過
四、怎麼保證高併發下服務的可用性，數據庫的可用性

功能實現

後端提供兩個接口，
一、hasAgree()，查詢該用戶是否已贊成協議
二、recordAgree()，記錄用戶已贊成協議

初版 Just DB

很容易嘛！不就是CRUD嗎，小意思。用戶進來先查數據庫有沒有記錄，沒有返回用戶沒有贊成過協議，前端給用戶展現協議頁，不然展現功能頁；用戶點贊成後，後臺記錄用戶已點了贊成協議，記錄到庫。一個查詢一個插入，5分鐘搞定嘛。

直接甩代碼

初版代碼如上，我以爲剛入門的程序員都可以寫出來。若是用戶量不大，該功能的點擊量不大的話，這麼作仍是勉強說得過去。爲何說勉強說得過去，由於存在隱患，你看啊若是每次點擊都會去查庫，假若有人惡意***，仿造高併發，瞬時大量請求過來都去查庫，極可能數據庫頂不住就掛了。或者就算數據庫沒掛，每次查庫也都是浪費啊。因此這是個隱患，或者潛在的危險，那麼第二版咱們就去解決這個問題。

第二版 引入Redis緩存

考慮到每次查庫很浪費，那咱們使用緩存好很差?
進來先查緩存有沒有對應的數據，緩存裏有就直接返回，沒有則查庫，庫裏有就存緩存。這樣redis就分擔了一部分數據庫的壓力。

代碼呈上

這一版好一點了，部分請求分攤到redis了，減輕了數據庫的壓力。

第三版 解決緩存穿透

隨着客戶量的增長，點擊這個功能的次數、頻率愈來愈高，假若有人頻繁點擊該功能，彈出協議後，退出，再點，再退出…就是不點肯定

這樣會有啥問題？

這樣的話後臺緩存中沒有，數據庫中也沒有，每次都會走數據庫，繞過了緩存，直接都走數據庫，這類請求量多了也是個問題，這就是緩存穿透。因此第三版，咱們來解決緩存穿透的問題。

解決緩存穿透：
由於是數據庫和緩存都沒有，咱們可讓數據庫沒有的也存到redis。須要改變redis的數據類型，由set改成map，目的是記錄狀態值。

能夠看到，咱們的這個key-field-value沒有設置過時時間，由於能夠認爲這個key是一個熱點key，對於熱點key咱們的處理方式是，永久有效或過時時間儘可能長一點。

第四版 緩存預熱防止緩存擊穿

另外一個關於緩存的問題，那就是緩存擊穿。

何爲緩存擊穿？
假如該功能在前期宣傳力度比較大，或預計該功能上線後點擊量比較大的話，那麼在功能上線後極可能就會一瞬間大量用戶來點擊這個功能，由於咱們前面的邏輯是首次進入該功能的用戶展現協議頁，咱們的後臺處理雖然加了redis緩存，可是新上的功能全部用戶都沒有點過，那麼redis裏就沒有緩存，是否是全部用戶的請求都落到數據庫了？一旦瞬間流量很是大，數據庫安全性就存在隱患，有被搞垮的可能。

這個問題就是能夠理解爲緩存擊穿。（實際的緩存擊穿是某個key在緩存裏不存在或是失效後，某一瞬間不少請求都來訪問這個key，都斷定爲redis裏沒有這個key，就都去查庫。）

因此怎麼解決呢？咱們能夠在該功能上線前，提早將須要作緩存的數據放入redis，即緩存預熱。

如何預熱？
將全部用戶的信息都放到redis.舉個栗子（也許不是最佳的），咱們使用Redis的hash數據結構，key-field-value。key咱們能夠固定一個字符串如coderTreeHole_Agreement_Check，field咱們能夠用客戶號（惟一），value是個標誌位，用0表明沒贊成過協議，1表明贊成過。通常在電商大促前都會對熱點key進行預熱，否則真的扛不住。

and，用戶量很大的時候redis裏的coderTreeHole_Agreement_Check這個key是否是很大？在redis集羣部署模式下，這個key是否是都放在一個節點上？why?

redis3.0上加入了cluster模式，實現的redis的分佈式存儲，也就是說每臺redis節點上存儲不一樣的內容。在redis的每個節點上，都有這麼兩個東西，一個是插槽（slot），它的的取值範圍是：0-16383。還有一個就是cluster，能夠理解爲是一個集羣管理的插件。當咱們的存取的key到達的時候，redis會根據crc16的算法得出一個結果，而後把結果對16384求餘數，這樣每一個key都會對應一個編號在0-16383之間的哈希槽，經過這個值，去找到對應的插槽所對應的節點，而後直接自動跳轉到這個對應的節點上進行存取操做。

看了上面這段話，明白了吧。那對於這個大key並且是熱點key的請求，是否是都落到某一個redis節點上了？大key會帶來不少問題，篇幅緣由之後再來細說，跑題了。。。

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

第五版 消息隊列削峯填谷

能夠看到咱們上面的設計其實都是實時對數據庫進行操做的。

例如，當用戶點了贊成，前端就調後臺的recordAgree方法將該記錄記錄到數據庫，即這條記錄是立馬插入到數據庫的。

若是剛上線這個功能，大量用戶同時點這個功能，併發量大的話，請求走到後臺，那麼寫庫的操做就很是多，數據庫鏈接數忽然激增，數據庫會頂不住吧。

因此爲避免流量集中落到數據庫，此時咱們可使用消息隊列MQ。將插入操做的請求發往消息隊列，使插入操做以必定的速率到數據庫執行，使得對數據庫的請求數儘可能平滑，消息發給消息隊列當即返回給前端成功，不用等待插庫完成，用MQ實現了異步解耦，削峯填谷。

到這你是否是忍不住說設計的真贊~~

另外MQ的使用注意的點仍是很是多的，如：消息隊列的消息重複消費問題，順序問題，事務消息等。

總結

對於這個需求設計到哪一種程度取決於你的用戶量和併發量，若是是像雙十一那樣，確定是要用消息隊列的，那通常小的例如，用戶量1千萬，日活10萬，請求最集中的也就是中午9-12點，下午13-17點吧，差很少8個小時，平均一個小時1.25萬，用戶都來點這個功能的話，每分鐘208，每秒3.5，算不上高併發，數據庫徹底扛得住。

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

畫圖碼字不易，若是以爲我寫的還能夠，記得點贊鼓勵一下哦，若是以爲有問題歡迎指正。