理論：第四章：Redis支持的數(shù)據(jù)類型以及使用場景，持久化，哨兵機制，緩存雪崩，緩存穿透，雙刪策略

簡單介紹一個redis？

redis是內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)存儲系統(tǒng)，一個key-value類型的非關(guān)系型數(shù)據(jù)庫，可持久化的數(shù)據(jù)庫，相對于關(guān)系型數(shù)據(jù)庫（數(shù)據(jù)主要存在硬盤中），性能高，因此我們一般用redis來做緩存使用；并且redis支持豐富的數(shù)據(jù)類型，比較容易解決各種問題，因此redis可以用來作為注冊中心，?數(shù)據(jù)庫、緩存和消息中間件。Redis的Value支持5種數(shù)據(jù)類型，string、hash、list、set、zset（sorted set）;

String類型：一個key對應(yīng)一個value

Hash類型：它的key是string類型，value又是一個map（key-value），適合存儲對象。

List類型：按照插入順序的字符串鏈表（雙向鏈表），主要命令是LPUSH和RPUSH，能夠支持反向查找和遍歷

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

zset類型：和set類型基本一致，不過它會給每個元素關(guān)聯(lián)一個double類型的分?jǐn)?shù)（score），這樣就可以為成員排序，并且插入是有序的。

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

對于緩存了解過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不支持?jǐn)?shù)據(jù)持久化，斷電或重啟后數(shù)據(jù)消失，但其穩(wěn)定性是有保證的；redis支持?jǐn)?shù)據(jù)持久化和數(shù)據(jù)恢復(fù)，允許單點故障，但是同時也會付出性能的代價

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

應(yīng)用場景：

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

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

案例：分布式系統(tǒng)，存在session之間的共享問題，因此在做單點登錄的時候，我們利用redis來模擬了session的共享，來存儲用戶的信息，實現(xiàn)不同系統(tǒng)的session共享；

對redis的持久化了解不？

redis的持久化方式有兩種：

RDB（半持久化方式）：按照配置不定期的通過異步的方式、快照的形式直接把內(nèi)存中的數(shù)據(jù)持久化到磁盤的一個dump.rdb文件（二進制的臨時文件）中，redis默認(rèn)的持久化方式，它在配置文件（redis.conf）中。

優(yōu)點：只包含一個文件，將一個單獨的文件轉(zhuǎn)移到其他存儲媒介上，對于文件備份、災(zāi)難恢復(fù)而言，比較實用。

缺點：系統(tǒng)一旦在持久化策略之前出現(xiàn)宕機現(xiàn)象，此前沒有來得及持久化的數(shù)據(jù)將會產(chǎn)生丟失

RDB持久化配置：

Redis會將數(shù)據(jù)集的快照dump到dump.rdb文件中。此外，我們也可以通過配置文件來修改Redis服務(wù)器dump快照的頻率，在打開6379.conf文件之后，我們搜索save，可以看到下面的配置信息：

save 900 1              #在900秒(15分鐘)之后，如果至少有1個key發(fā)生變化，則dump內(nèi)存快照。

save 300 10            #在300秒(5分鐘)之后，如果至少有10個key發(fā)生變化，則dump內(nèi)存快照。

save 60 10000        #在60秒(1分鐘)之后，如果至少有10000個key發(fā)生變化，則dump內(nèi)存快照。

AOF（全持久化的方式）：把每一次數(shù)據(jù)變化都通過write()函數(shù)將你所執(zhí)行的命令追加到一個appendonly.aof文件里面，Redis默認(rèn)是不支持這種全持久化方式的，需要在配置文件（redis.conf）中將appendonly no改成appendonly yes

優(yōu)點：數(shù)據(jù)安全性高，對日志文件的寫入操作采用的是append模式，因此在寫入過程中即使出現(xiàn)宕機問題，也不會破壞日志文件中已經(jīng)存在的內(nèi)容；

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

AOF持久化配置:

在Redis的配置文件中存在三種同步方式，它們分別是：

appendfsync always     #每次有數(shù)據(jù)修改發(fā)生時都會都調(diào)用fsync刷新到aof文件，非常慢，但是安全；

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

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

二種持久化方式區(qū)別：

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

如果緩存數(shù)據(jù)安全性要求比較高的話，用aof這種持久化方式（比如項目中的購物車）；

如果對于大數(shù)據(jù)集要求效率高的話，就可以使用默認(rèn)的。而且這兩種持久化方式可以同時使用。  

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

Redis的數(shù)據(jù)是存放在內(nèi)存中的，不適合存儲大數(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集群。集群這塊是公司運維搭建的，具體怎么搭建不是太了解。

我們項目中redis集群主要搭建了6臺，3主（為了保證redis的投票機制）3從（高可用），每個主服務(wù)器都有一個從服務(wù)器，作為備份機。所有的節(jié)點都通過PING-PONG機制彼此互相連接；客戶端與redis集群連接，只需要連接集群中的任何一個節(jié)點即可；Redis-cluster中內(nèi)置了16384個哈希槽，Redis-cluster把所有的物理節(jié)點映射到【0-16383】slot上，負(fù)責(zé)維護。

redis有事務(wù)嗎？

Redis是有事務(wù)的，redis中的事務(wù)是一組命令的集合，這組命令要么都執(zhí)行，要不都不執(zhí)行，保證一個事務(wù)中的命令依次執(zhí)行而不被其他命令插入。redis的事務(wù)是不支持回滾操作的。redis事務(wù)的實現(xiàn)，需要用到MULTI（事務(wù)的開始）和EXEC（事務(wù)的結(jié)束）命令 ;

緩存穿透

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

解決方案：

1.對所有可能查詢的參數(shù)以hash形式存儲，在控制層先進行校驗，不符合則丟棄。

2.將所有可能存在的數(shù)據(jù)哈希到一個足夠大的bitmap中，一個一定不存在的數(shù)據(jù)會被這個bitmap攔截掉，從而避免了對底層存儲系統(tǒng)的查詢壓力。

3.如果一個查詢返回的數(shù)據(jù)為空（不管是數(shù) 據(jù)不存在，還是系統(tǒng)故障），我們?nèi)匀话堰@個空結(jié)果進行緩存，但它的過期時間會很短，最長不超過五分鐘。

緩存雪崩

當(dāng)緩存服務(wù)器重啟或者大量緩存集中在一段時間內(nèi)失效，發(fā)生大量的緩存穿透，這樣在失效的瞬間對數(shù)據(jù)庫的訪問壓力就比較大，所有的查詢都落在數(shù)據(jù)庫上，造成了緩存雪崩。 這個沒有完美解決辦法，但可以分析用戶行為，盡量讓失效時間點均勻分布。大多數(shù)系統(tǒng)設(shè)計者考慮用加鎖或者隊列的方式保證緩存的單線程（進程）寫，從而避免失效時大量的并發(fā)請求落到底層存儲系統(tǒng)上。

解決方案：

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

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

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

解決方案：

    禁止一些高危命令。修改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ù)只在當(dāng)前主機使用；
    做log監(jiān)控，及時發(fā)現(xiàn)攻擊；

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

哨兵機制：

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

提醒：當(dāng)被監(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）里面配置訪問密碼

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

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

  應(yīng)用場景：

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

（數(shù)據(jù)庫和redis的數(shù)據(jù)如何保持一致）雙刪策略

https://blog.csdn.net/bntX2jSQfEHy7/article/details/80416687?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromBaidu-1.nonecase&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromBaidu-1.nonecase

redis本人被問到的較少，所以只是寫了簡單的一些面試題