Redis數(shù)據(jù)結(jié)構(gòu)存儲系統(tǒng)：第三章：Redis在項目中如何使用？

簡單介紹一個redis？

redis是一個key-value類型的非關(guān)系型數(shù)據(jù)庫，基于內(nèi)存也可持久化的數(shù)據(jù)庫，相對于關(guān)系型數(shù)據(jù)庫（數(shù)據(jù)主要存在硬盤中），性能高，因此我們一般用redis來做緩存使用；并且redis支持豐富的數(shù)據(jù)類型，比較容易解決各種問題
Redis的Value支持5種數(shù)據(jù)類型，string、hash、list、set、zset（sorted set）;

  String類型是最簡單的類型，一個key對應(yīng)一個value，項目中主要利用單點登錄中的token用string類型來存儲；

 Hash類型中的key是string類型，value又是一個map（key-value），針對這種數(shù)據(jù)特性，比較適合存儲對象，在項目中由于購物車是用redis來存儲的，因為選擇redis的散列（hash）來存儲；

 List類型是按照插入順序的字符串鏈表（雙向鏈表），主要命令是LPUSH和RPUSH，能夠支持反向查找和遍歷，如果使用的話主要存儲商品評論列表，key是該商品的ID，value是商品評論信息列表；

 Set類型是用哈希表類型的字符串序列，沒有順序，集合成員是唯一的，沒有重復(fù)數(shù)據(jù)，底層主要是由一個value永遠為null的hashmap來實現(xiàn)的。

我們的電商項目中沒有用到這個數(shù)據(jù)類型。這個應(yīng)用場景一般存儲一個列表數(shù)據(jù)，但列表里面又不希望出現(xiàn)重復(fù)數(shù)據(jù)，比如微博應(yīng)用中，可以將一個用戶所有關(guān)注的對象放在一個集合中，將其所有粉絲存在一個集合，這樣我們就可以實現(xiàn)兩個人的共同好友、共同關(guān)注等需求；

zset（sorted set）類型和set類型基本是一致的，不同的是zset這種類型會給每個元素關(guān)聯(lián)一個double類型的分數(shù)（score），這樣就可以為成員排序，并且插入是有序的。這種數(shù)據(jù)類型如果使用的話主要用來統(tǒng)計商品的銷售排行榜，比如：items:sellsort 10 1001 20 1002 這個代表編號是1001的商品銷售數(shù)量為10,編號為1002的商品銷售數(shù)量為20。

（3）我們項目中主要用redis的java客戶端Jedis來操作redis數(shù)據(jù)庫，用來緩存各種操作頻繁，不經(jīng)常修改的數(shù)據(jù)，這樣就減輕了數(shù)據(jù)庫的訪問壓力，提高了查詢效率

你還用過其他的緩存嗎？這些緩存有什么區(qū)別？都在什么場景下去用？

 對于緩存了解過redis和memcache，redis我們在項目中用的比較多，memcache沒用過，但是了解過一點；

 Memcache和redis的區(qū)別：

    數(shù)據(jù)支持的類型：

    存儲方式：redis不僅僅支持簡單的k/v類型的數(shù)據(jù)，同時還支持list、set、zset、hash等數(shù)據(jù)結(jié)構(gòu)的存儲；memcache只支持簡單的k/v類型的數(shù)據(jù)，key和value都是string類型

    可靠性：memcache不支持數(shù)據(jù)持久化，斷電或重啟后數(shù)據(jù)消失，但其穩(wěn)定性是有保證的；redis支持數(shù)據(jù)持久化和數(shù)據(jù)恢復(fù)，允許單點故障，但是同時也會付出性能的代價

    性能上：對于存儲大數(shù)據(jù)，memcache的性能要高于redis

應(yīng)用場景：

Memcache：適合多讀少寫，大數(shù)據(jù)量的情況（一些官網(wǎng)的文章信息等）

Redis：適用于對讀寫效率要求高、數(shù)據(jù)處理業(yè)務(wù)復(fù)雜、安全性要求較高的系統(tǒng)

Redis在你們項目中是怎么用的？

門戶系統(tǒng)中的首頁內(nèi)容信息的展示。（商品類目、廣告、熱門商品等信息）門戶系統(tǒng)的首頁是用戶訪問量最大的，而且這些數(shù)據(jù)一般不會經(jīng)常修改，因此為了提高用戶的體驗，我們選擇將這些內(nèi)容放在緩存中；
單點登錄系統(tǒng)中也用到了redis。因為我們是分布式系統(tǒng)，存在session之間的共享問題，因此在做單點登錄的時候，我們利用redis來模擬了session的共享，來存儲用戶的信息，實現(xiàn)不同系統(tǒng)的session共享；
我們項目中同時也將購物車的信息設(shè)計存儲在redis中，購物車在數(shù)據(jù)庫中沒有對應(yīng)的表，用戶登錄之后將商品添加到購物車后存儲到redis中，key是用戶id，value是購物車對象；
因為針對評論這塊，我們需要一個商品對應(yīng)多個用戶評論，并且按照時間順序顯示評論，為了提高查詢效率，因此我們選擇了redis的list類型將商品評論放在緩存中；
在統(tǒng)計模塊中，我們有個功能是做商品銷售的排行榜，因此選擇redis的zset結(jié)構(gòu)來實現(xiàn)；

還有一些其他的應(yīng)用場景，主要就是用來作為緩存使用。

對redis的持久化了解不？

   Redis是內(nèi)存型數(shù)據(jù)庫，同時它也可以持久化到硬盤中，redis的持久化方式有兩種：

RDB（半持久化方式）：

按照配置不定期的通過異步的方式、快照的形式直接把內(nèi)存中的數(shù)據(jù)持久化到磁盤的一個dump.rdb文件（二進制文件）中；

這種方式是redis默認的持久化方式，它在配置文件（redis.conf）中的格式是：save N M，表示的是在N秒之內(nèi)發(fā)生M次修改，則redis抓快照到磁盤中；

原理：當redis需要持久化的時候，redis會fork一個子進程，這個子進程會將數(shù)據(jù)寫到一個臨時文件中；當子進程完成寫臨時文件后，會將原來的.rdb文件替換掉，這樣的好處是寫時拷貝技術(shù)（copy-on-write），可以參考下面的流程圖；
在這里插入圖片描述












   優(yōu)點：只包含一個文件，對于文件備份、災(zāi)難恢復(fù)而言，比較實用。因為我們可以輕松的將一個單獨的文件轉(zhuǎn)移到其他存儲媒介上；性能最大化，因為對于這種半持久化方式，使用的是寫時拷貝技術(shù)，可以極大的避免服務(wù)進程執(zhí)行IO操作；相對于AOF來說，如果數(shù)據(jù)集很大，RDB的啟動效率就會很高

 缺點：如果想保證數(shù)據(jù)的高可用（最大限度的包裝數(shù)據(jù)丟失），那么RDB這種半持久化方式不是一個很好的選擇，因為系統(tǒng)一旦在持久化策略之前出現(xiàn)宕機現(xiàn)象，此前沒有來得及持久化的數(shù)據(jù)將會產(chǎn)生丟失；rdb是通過fork進程來協(xié)助完成持久化的，因此當數(shù)據(jù)集較大的時候，我們就需要等待服務(wù)器停止幾百毫秒甚至一秒；

AOF（全持久化的方式）

把每一次數(shù)據(jù)變化都通過write()函數(shù)將你所執(zhí)行的命令追加到一個appendonly.aof文件里面；

事實上，不會立即將命令寫入硬盤文件中，而是寫入硬盤緩存，可以配置策略，配置多久從硬盤緩存寫入到硬盤文件中。

Appendfsync always

Appendfsync everysec 默認的

Appendfsync no 不主動，默認30秒一次

Redis默認是不支持這種全持久化方式的，需要將no改成yes

在這里插入圖片描述

















實現(xiàn)文件刷新的三種方式：

在這里插入圖片描述










no:不會自動同步到磁盤上，需要依靠OS（操作系統(tǒng)）進行刷新，效率快，但是安全性就比較差；

always:每提交一個命令都調(diào)用fsync刷新到aof文件，非常慢，但是安全；

everysec:每秒鐘都調(diào)用fsync刷新到aof文件中，很快，但是可能丟失一秒內(nèi)的數(shù)據(jù)，推薦使用，兼顧了速度和安全；

原理：redis需要持久化的時候，fork出一個子進程，子進程根據(jù)內(nèi)存中的數(shù)據(jù)庫快照，往臨時文件中寫入重建數(shù)據(jù)庫狀態(tài)的命令；父進程會繼續(xù)處理客戶端的請求，除了把寫命令寫到原來的aof中，同時把收到的寫命令緩存起來，這樣包裝如果子進程重寫失敗的話不會出問題；當子進程把快照內(nèi)容以命令方式寫入臨時文件中后，子進程會發(fā)送信號給父進程，父進程會把緩存的寫命令寫入到臨時文件中；接下來父進程可以使用臨時的aof文件替換原來的aof文件，并重命名，后面收到的寫命令也開始往新的aof文件中追加。下面的圖為最簡單的方式，其實也是利用寫時復(fù)制原則。
在這里插入圖片描述








優(yōu)點：

數(shù)據(jù)安全性高

該機制對日志文件的寫入操作采用的是append模式，因此在寫入過程中即使出現(xiàn)宕機問題，也不會破壞日志文件中已經(jīng)存在的內(nèi)容；

缺點：

對于數(shù)量相同的數(shù)據(jù)集來說，aof文件通常要比rdb文件大，因此rdb在恢復(fù)大數(shù)據(jù)集時的速度大于AOF；

根據(jù)同步策略的不同，AOF在運行效率上往往慢于RDB，每秒同步策略的效率是比較高的，同步禁用策略的效率和RDB一樣高效；

針對以上兩種不同的持久化方式，如果緩存數(shù)據(jù)安全性要求比較高的話，用aof這種持久化方式（比如項目中的購物車）；如果對于大數(shù)據(jù)集要求效率高的話，就可以使用默認的。而且這兩種持久化方式可以同時使用。

做過redis的集群嗎？你們做集群的時候搭建了幾臺，都是怎么搭建的？

針對這類問題，我們首先考慮的是為什么要搭建集群？（這個需要針對我們的項目來說）

Redis的數(shù)據(jù)是存放在內(nèi)存中的，這就意味著redis不適合存儲大數(shù)據(jù)，大數(shù)據(jù)存儲一般公司常用hadoop中的Hbase或者MogoDB。因此redis主要用來處理高并發(fā)的，用我們的項目來說，電商項目如果并發(fā)大的話，一臺單獨的redis是不能足夠支持我們的并發(fā)，這就需要我們擴展多臺設(shè)備協(xié)同合作，即用到集群。

Redis搭建集群的方式有多種，例如：客戶端分片、Twemproxy、Codis等，但是redis3.0之后就支持redis-cluster集群，這種方式采用的是無中心結(jié)構(gòu)，每個節(jié)點保存數(shù)據(jù)和整個集群的狀態(tài)，每個節(jié)點都和其他所有節(jié)點連接。如果使用的話就用redis-cluster集群。

集群這塊直接說是公司運維搭建的，小公司的話也有可能由我們自己搭建，開發(fā)環(huán)境我們也可以直接用單機版的。但是可以了解一下redis的集群版。搭建redis集群的時候，對于用到多少臺服務(wù)器，每家公司都不一樣，大家針對自己項目的大小去衡量。舉個簡單的例子：

我們項目中redis集群主要搭建了6臺，3主（為了保證redis的投票機制）3從（高可用），每個主服務(wù)器都有一個從服務(wù)器，作為備份機。

架構(gòu)圖如下：
在這里插入圖片描述













所有的節(jié)點都通過PING-PONG機制彼此互相連接；
每個節(jié)點的fail是通過集群中超過半數(shù)的節(jié)點檢測失效時才生效；
客戶端與redis集群連接，只需要連接集群中的任何一個節(jié)點即可；
Redis-cluster把所有的物理節(jié)點映射到【0-16383】slot上，負責維護

2、容錯機制（投票機制）

（1）選舉過程是集群中的所有master都參與，如果半數(shù)以上master節(jié)點與故障節(jié)點連接超過時間，則認為該節(jié)點故障，自動會觸發(fā)故障轉(zhuǎn)移操作；

（2）集群不可用？

 a:如果集群任意master掛掉，并且當前的master沒有slave，集群就會fail;

 b:如果集群超過半數(shù)以上master掛掉，無論是否有slave，整個集群都會fail;

6、redis有事務(wù)嗎？

Redis是有事務(wù)的，redis中的事務(wù)是一組命令的集合，這組命令要么都執(zhí)行，要不都不執(zhí)行，redis事務(wù)的實現(xiàn)，需要用到MULTI（事務(wù)的開始）和EXEC（事務(wù)的結(jié)束）命令 ;
在這里插入圖片描述











當輸入MULTI命令后，服務(wù)器返回OK表示事務(wù)開始成功，然后依次輸入需要在本次事務(wù)中執(zhí)行的所有命令，每次輸入一個命令服務(wù)器并不會馬上執(zhí)行，而是返回”QUEUED”，這表示命令已經(jīng)被服務(wù)器接受并且暫時保存起來，最后輸入EXEC命令后，本次事務(wù)中的所有命令才會被依次執(zhí)行，可以看到最后服務(wù)器一次性返回了兩個OK，這里返回的結(jié)果與發(fā)送的命令是按順序一一對應(yīng)的，這說明這次事務(wù)中的命令全都執(zhí)行成功了。

Redis的事務(wù)除了保證所有命令要不全部執(zhí)行，要不全部不執(zhí)行外，還能保證一個事務(wù)中的命令依次執(zhí)行而不被其他命令插入。同時，redis的事務(wù)是不支持回滾操作的。

【擴展】

Redis的事務(wù)中存在一個問題，如果一個事務(wù)中的B命令依賴上一個命令A(yù)怎么辦？

這會涉及到redis中的WATCH命令：可以監(jiān)控一個或多個鍵，一旦其中有一個鍵被修改（或刪除），之后的事務(wù)就不會執(zhí)行，監(jiān)控一直持續(xù)到EXEC命令（事務(wù)中的命令是在EXEC之后才執(zhí)行的，EXEC命令執(zhí)行完之后被監(jiān)控的鍵會自動被UNWATCH）。

應(yīng)用場景：待定
【擴展】

redis的安全機制（你們公司redis的安全這方面怎么考慮的？）

漏洞介紹：redis默認情況下，會綁定在bind 0.0.0.0:6379，這樣就會將redis的服務(wù)暴露到公網(wǎng)上，如果在沒有開啟認證的情況下，可以導(dǎo)致任意用戶在訪問目標服務(wù)器的情況下未授權(quán)訪問redis以及讀取redis的數(shù)據(jù)，攻擊者就可以在未授權(quán)訪問redis的情況下可以利用redis的相關(guān)方法，成功在redis服務(wù)器上寫入公鑰，進而可以直接使用私鑰進行直接登錄目標主機；

比如：可以使用FLUSHALL方法，整個redis數(shù)據(jù)庫將被清空

解決方案：

禁止一些高危命令。修改redis.conf文件，用來禁止遠程修改DB文件地址，比如 rename-command FLUSHALL "" 、rename-command CONFIG"" 、rename-command EVAL “”等；
以低權(quán)限運行redis服務(wù)。為redis服務(wù)創(chuàng)建單獨的用戶和根目錄，并且配置禁止登錄；
為redis添加密碼驗證。修改redis.conf文件，添加

requirepass mypassword；

禁止外網(wǎng)訪問redis。修改redis.conf文件，添加或修改 bind 127.0.0.1，使得redis服務(wù)只在當前主機使用；
做log監(jiān)控，及時發(fā)現(xiàn)攻擊；

redis的哨兵機制（redis2.6以后出現(xiàn)的）

哨兵機制：

監(jiān)控：監(jiān)控主數(shù)據(jù)庫和從數(shù)據(jù)庫是否正常運行；

    提醒：當被監(jiān)控的某個redis出現(xiàn)問題的時候，哨兵可以通過API向管理員或者其他應(yīng)用程序發(fā)送通知；

    自動故障遷移：主數(shù)據(jù)庫出現(xiàn)故障時，可以自動將從數(shù)據(jù)庫轉(zhuǎn)化為主數(shù)據(jù)庫，實現(xiàn)自動切換；

具體的配置步驟面試中可以說參考的網(wǎng)上的文檔。要注意的是，如果master主服務(wù)器設(shè)置了密碼，記得在哨兵的配置文件（sentinel.conf）里面配置訪問密碼

3、緩存穿透

緩存查詢一般都是通過key去查找value，如果不存在對應(yīng)的value，就要去數(shù)據(jù)庫中查找。如果這個key對應(yīng)的value在數(shù)據(jù)庫中也不存在，并且對該key并發(fā)請求很大，就會對數(shù)據(jù)庫產(chǎn)生很大的壓力，這就叫緩存穿透

解決方案：

    對所有可能查詢的參數(shù)以hash形式存儲，在控制層先進行校驗，不符合則丟棄。還有最常見的則是采用布隆過濾器，將所有可能存在的數(shù)據(jù)哈希到一個足夠大的bitmap中，一個一定不存在的數(shù)據(jù)會被這個bitmap攔截掉，從而避免了對底層存儲系統(tǒng)的查詢壓力。
    也可以采用一個更為簡單粗暴的方法，如果一個查詢返回的數(shù)據(jù)為空（不管是數(shù) 據(jù)不存在，還是系統(tǒng)故障），我們?nèi)匀话堰@個空結(jié)果進行緩存，但它的過期時間會很短，最長不超過五分鐘。

4、緩存雪崩

當緩存服務(wù)器重啟或者大量緩存集中在一段時間內(nèi)失效，發(fā)生大量的緩存穿透，這樣在失效的瞬間對數(shù)據(jù)庫的訪問壓力就比較大，所有的查詢都落在數(shù)據(jù)庫上，造成了緩存雪崩。

這個沒有完美解決辦法，但可以分析用戶行為，盡量讓失效時間點均勻分布。大多數(shù)系統(tǒng)設(shè)計者考慮用加鎖或者隊列的方式保證緩存的單線程（進程）寫，從而避免失效時大量的并發(fā)請求落到底層存儲系統(tǒng)上。

解決方案：

    在緩存失效后，通過加鎖或者隊列來控制讀數(shù)據(jù)庫寫緩存的線程數(shù)量。比如對某個key只允許一個線程查詢數(shù)據(jù)和寫緩存，其他線程等待。
    可以通過緩存reload機制，預(yù)先去更新緩存，再即將發(fā)生大并發(fā)訪問前手動觸發(fā)加載緩存
    不同的key，設(shè)置不同的過期時間，讓緩存失效的時間點盡量均勻
    做二級緩存，或者雙緩存策略。A1為原始緩存，A2為拷貝緩存，A1失效時，可以訪問A2，A1緩存失效時間設(shè)置為短期，A2設(shè)置為長期。

redis中對于生存時間的應(yīng)用

Redis中可以使用expire命令設(shè)置一個鍵的生存時間，到時間后redis會自動刪除；

應(yīng)用場景：

設(shè)置限制的優(yōu)惠活動的信息；
一些及時需要更新的數(shù)據(jù)，積分排行榜；
手機驗證碼的時間；
限制網(wǎng)站訪客訪問頻率；