Redis支持的數據類型以及使用場景，持久化，哨兵機制，緩存擊穿，緩存穿透

簡單介紹一個redis？

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

String類型：一個key對應一個value

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

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

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

zset類型：和set類型基本一致，不過它會給每個元素關聯一個double類型的分數（score），這樣就可以為成員排序，并且插入是有序的。

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

對于緩存了解過redis和memcache

Memcache和redis的區別：

數據支持的類型：redis不僅僅支持簡單的k/v類型的數據，同時還支持list、set、zset、hash等數據結構的存儲；memcache只支持簡單的k/v類型的數據，key和value都是string類型

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

性能上：對于存儲大數據，memcache的性能要高于redis

應用場景：

Memcache：適合多讀少寫，大數據量的情況（一些官網的文章信息等）

Redis：適用于對讀寫效率要求高、數據處理業務復雜、安全性要求較高的系統

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

對redis的持久化了解不？

redis的持久化方式有兩種：

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

優點：只包含一個文件，將一個單獨的文件轉移到其他存儲媒介上，對于文件備份、災難恢復而言，比較實用。

缺點：系統一旦在持久化策略之前出現宕機現象，此前沒有來得及持久化的數據將會產生丟失

RDB持久化配置：

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

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

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

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

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

優點：數據安全性高，對日志文件的寫入操作采用的是append模式，因此在寫入過程中即使出現宕機問題，也不會破壞日志文件中已經存在的內容；

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

AOF持久化配置:

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

appendfsync always #每次有數據修改發生時都會都調用fsync刷新到aof文件，非常慢，但是安全；

appendfsync everysec #每秒鐘都調用fsync刷新到aof文件中，很快，但是可能丟失一秒內的數據，推薦使用，兼顧了速度和安全；

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

二種持久化方式區別：

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

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

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

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

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

Redis搭建集群的方式有多種，例如：客戶端分片、Twemproxy、Codis等，但是redis3.0之后就支持redis-cluster集群，這種方式采用的是無中心結構，每個節點保存數據和整個集群的狀態，每個節點都和其他所有節點連接。如果使用的話就用redis-cluster集群。集群這塊是公司運維搭建的，具體怎么搭建不是太了解。

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

redis有事務嗎？

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

緩存穿透

緩存查詢一般都是通過key去查找value，如果不存在對應的value，就要去數據庫中查找。如果這個key對應的value在數據庫中也不存在，并且對該key并發請求很大，就會對數據庫產生很大的壓力，這就叫緩存穿透

解決方案：

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

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

3.如果一個查詢返回的數據為空（不管是數 據不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鐘。

緩存雪崩

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

解決方案：

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

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

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

解決方案：

禁止一些高危命令。修改redis.conf文件，用來禁止遠程修改DB文件地址，比如 rename-command FLUSHALL “” 、rename-command CONFIG"" 、rename-command EVAL “”等；
以低權限運行redis服務。為redis服務創建單獨的用戶和根目錄，并且配置禁止登錄；
為redis添加密碼驗證。修改redis.conf文件，添加requirepass mypassword；
禁止外網訪問redis。修改redis.conf文件，添加或修改 bind 127.0.0.1，使得redis服務只在當前主機使用；
做log監控，及時發現攻擊；
redis的哨兵機制（redis2.6以后出現的）
哨兵機制：

監控：監控主數據庫和從數據庫是否正常運行；

提醒：當被監控的某個redis出現問題的時候，哨兵可以通過API向管理員或者其他應用程序發送通知；

自動故障遷移：主數據庫出現故障時，可以自動將從數據庫轉化為主數據庫，實現自動切換；

具體的配置步驟參考的網上的文檔。要注意的是，如果master主服務器設置了密碼，記得在哨兵的配置文件（sentinel.conf）里面配置訪問密碼

redis中對于生存時間的應用

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

應用場景：

設置限制的優惠活動的信息；
一些及時需要更新的數據，積分排行榜；
手機驗證碼的時間；
限制網站訪客訪問頻率；

總結

以上是生活随笔為你收集整理的Redis支持的数据类型以及使用场景，持久化，哨兵机制，缓存击穿，缓存穿透的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。