一.Redis 支援的資料型別有哪些？

基本資料型別

• String：存放的是k-v鍵值對。如：set k v；
  • 使用場景：常規計數，快取等
• List：有序，可重複。如：lpush mylist v1 v2 v3;
  • 使用場景：Redis的list是每個子元素都是String型別的雙向連結串列， 可以通過push和pop操作從列表的頭部或者尾部 新增或者刪除元素，這樣List即可以作為棧和佇列。
• Set：無序，不可重複。如：sadd myset v1 v2 v3;
  • 使用場景：交集：一些共同關注，共同喜好，二度好友(共同好友)都可以使用。
• Hash：在 Redis中雜湊型別是指值本身是一種鍵值對結構，如 value={{field1,value1},……{fieldN,valueN}}。如：hmset
  myhash k1 v1 k2 v2 k3 v3
  • 使用場景：儲存物件，儲存一些複雜的k-v資訊
• zSet：有序，不可重複。雖然set是無序的，但是zSet就是為了讓set有序。如：zadd myset 1 v1 2 v2 3 v3
  • 使用場景：排行榜。　　

三大特殊的資料型別

• Geospatial：這個功能可以將使用者給定的地理位置資訊(經緯度)儲存起來， 並對這些資訊進行操作(計算兩地的距離，範圍等)。
  • 使用場景：地圖，附件的人...
• HyperLogLog：可以儲存不重複的資料,並且佔用很小的記憶體。雖然set也可以，但是佔用空間大。如：pfadd myhyper 1 3 5 6 7 4
  • 每個 HyperLogLog 只需要花費 12
    KB 記憶體，就可以計算接近 2^64 個不同元素的基數。
  • 使用場景：適合瀏覽量一類的業務。
• BitMap點陣圖：存放是/否的操作，如果把true/false放在資料庫中，佔用空間大。BitMap採用二進位制01110010101001...進行儲存。如：setbit mybit 7 1;//比如第7天是否打卡
  • 使用場景：存放登入/未登入，打卡/未打卡,活躍/不活躍這樣的資料

二.RDB和AOF機制

它們都是redis進行持久化的方式。

• RDB：(redis database)
  • 在指定的時間間隔內將記憶體中的資料集快照寫入磁碟(dump.rdb)。 恢復時將快照檔案直接讀到記憶體裡，它會fork一個子程序
    來進行持久化,不會影響主程序的效能。
    
  • 優點：效率高，因為fork一個子程序進行IO操作,不影響主程序。
  • 缺點：安全性不高
    • 在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最後一次快照後的所有修改
    • Fork的時候，記憶體中的資料被克隆了一份，大致2倍的膨脹性需要考慮。
  • 同步機制：redis會自動進行持久化
    • save 60 10 //在redis.config中手動設定：60秒內修改10次
    • 執行flushall 命令的時候
    • 退出redis.server的時候
      
• AOF (append only file)
  • 以日誌的形式來記錄每一個"寫/刪除"的命令。但是隻追加檔案不可以修改檔案，redis啟動的時候會重新載入appendonly.aof，重新執行所有的命令,用來恢復資料
    
  • 優點：安全性高
    • 資料安全性高，發生宕機後，不會破壞已經存在的內容
    • 內部採用rewrite模式，定期對AOF檔案進行重寫，以達到壓縮的目的
  • 缺點：效率不高
    • AOF檔案比RDB檔案要大很多，並且每次啟動重新執行寫的指令，效率就低。
  • 同步機制: 不同步；每秒同步一次；每次寫入時同步
• 並存：
  • redis支援同時開啟兩種方式，預設優先載入aof檔案來恢復資料，因為資料完整性高。 rdb作為備份。

三.過期鍵刪除策略

redis的過期策略是指:key過期了,redis如何在內部把它刪除。

• 惰性過期：只有在使用key的時候，才判斷key是否過期，過期清除。不使用的時候就算是過期了，也一直儲存在記憶體中。
  • 可以節省CPU資源，但對記憶體不友好。
• 定時過期：不是redis的策略，指給每一個key都配上定時器。到時間了自動清除key。
  • 可以節省記憶體，但是對CPU不友好，因為得維護每一個定時器。
• 定期過期：每隔一段時間，會掃描一定數量的expires字典中的key，刪除過期的key。
  • 是對以上兩者的一個折中方案，平衡記憶體和CPU的最高效能。

redis默認同時使用了惰性過期和定期過期兩種策略

四.執行緒模型

執行緒模型：

• 多個 socket 可能會併發產生不同的操作，每個操作對應不同的檔案事件，但是 IO多路複用程式會監聽多個 socket，會將產生事件的 socket 放入佇列中排隊，事件分派器每次從佇列中取出一個 socket，根據 socket 的事件型別交給對應的事件處理器進行處理。

一次客戶端與redis完整通訊過程

• 建立連線
  1. 首先，redis 服務端程序初始化的時候，會將 server socket 的AE_READABLE事件與連線應答處理器關聯。
  2. 客戶端 socket01 向 redis 程序的 server socket 請求建立連線，此時 server socket 會產生一個AE_READABLE事件，IO 多路複用程式監聽到 server socket 產生的事件後，將該 socket 壓入佇列中。
  3. 檔案事件分派器從佇列中獲取 socket，交給連線應答處理器。
  4. 連線應答處理器會建立一個能與客戶端通訊的 socket01，並將該 socket01 的AE_READABLE事件與命令請求處理器關聯。
• 執行一個set請求
  1. 客戶端傳送了一個set key value請求，此時 redis 中的 socket01 會產生AE_READABLE事件，IO 多路複用程式將 socket01 壓入佇列，
  2. 此時事件分派器從佇列中獲取到 socket01 產生的AE_READABLE事件，由於前面 socket01 的AE_READABLE事件已經與命令請求處理器關聯，
  3. 因此事件分派器將事件交給命令請求處理器來處理。命令請求處理器讀取 socket01 的key value並在自己記憶體中完成key value的設定。
  4. 操作完成後，它會將 socket01 的AE_WRITABLE事件與命令回覆處理器關聯。
  5. 如果此時客戶端準備好接收返回結果了，那麼 redis 中的 socket01 會產生一個AE_WRITABLE事件，同樣壓入佇列中，
  6. 事件分派器找到相關聯的命令回覆處理器，由命令回覆處理器對 socket01 輸入本次操作的一個結果，比如ok，之後解除 socket01 的AE_WRITABLE事件與命令回覆處理器的關聯。

redis單執行緒快的原因?

• 純記憶體操作。
• 核心是基於非阻塞的 IO 多路複用機制。
• C 語言實現，語言更接近作業系統，執行速度相對會更快。
• 單執行緒反而避免了多執行緒的頻繁上下文切換問題,預防了多執行緒可能產生的競爭問題。
• 總結：就像對於一個請求來說，如果業務邏輯複雜，使用多執行緒效率就高，使用者也可以及時得到迴應.。但是請求中如果業務邏輯簡單(就像redis,就僅僅是對key進行讀寫操作)，但是請求量大的話， 單執行緒效率就要高。

五.快取雪崩,快取擊穿,快取穿透的區別?

• 快取雪崩：指快取(redis)同一時間，大面積的失效。所有請求都到了資料庫，相當於redis整個不能用了。
  • 比如:redis重啟的時候，開始redis中沒有任何資料；或者快取資料同一時間失效； 這時所有請求需要訪問資料庫，那一刻相當於快取雪崩，整個redis不能用了。 同時訪問大量資料
    
  • 解決方案：
    • 設定隨機過期時間，避免統一時間點同時過期
    • 快取預熱：比如對於重啟的時候，提前把一些資料放到快取中， 讓redis一啟動就載入了熱點資料
    • 互斥鎖：加鎖，訪問資料庫的請求只能有一條。
      
• 快取擊穿：是指訪問快取中沒有，但是資料庫中有的資料。與快取雪崩不同的是，它是同時訪問同一條熱點資料。而不是大量的資料。同時訪問同一資料
  • 解決方案:
    • 設定熱點資料永不過期，但是也需要維護(定期刪除)
    • 互斥鎖
• 快取穿透：同時大量訪問快取中和資料庫中都不存在的資料，一般就是被惡意攻擊。
  • 解決方案：
    • 介面層面新增校驗，比如查詢的id不符合資料庫中的範圍，或者使用者許可權不夠。直接攔截
    • 快取空物件，把該資料的key存在快取中，值設為null。這樣可以防止反覆用同一個id暴力攻擊
    • 使用布隆過濾器，這是redis自帶的。它將所有可能的資料存放在足夠大的bitmap中，一個一定不存在的資料就會被這個bitmap攔截掉,避免資料庫的查詢壓力

六.redis事務

既然是事務,就需要保證ACID。

• 原子性(A)：事務中單條命令才保證原子性，整個事務並不保證原子性。因為事務不支援回滾
• 一致性(C)：Redis捨棄了回滾的設計，基本上也就捨棄對資料一致性的有效保證。
• 隔離性(I)：redis單執行緒天然的隔離性
• 永續性(D)：採用RDB和AOF兩種方式實現持久化

實現：Redis事務的三個階段

• 開始事務 (multi)
• 命令入隊 (命令)，採用FIFO (先進先出)
• 執行事務 (exec)

注意：事務中如果出現命令語法錯誤(相當於編譯時錯誤)，所有命令就不會執行。 事務中如果出現邏輯錯誤(相當於執行時錯誤)，錯誤語句不執行，其他命令正常執行。

事務中用到的其他命令:

• watch：相當於加了一個樂觀鎖，更新時判斷。
• unwatch：釋放樂觀鎖。但是每次事務結束(無論成功與否)會自動釋放樂觀鎖，不需要手動執行該命令
• discard：事務中途放棄事務，命令都不執行

七.redis叢集

redis的叢集方案?　　四種模式各有優缺點，可根據實際場景進行選擇。

• 主從模式
  • 指將一臺Redis伺服器的資料，複製到其他的Redis伺服器。 資料的複製是單向的，只能由主節點到從節點。
  • Master以寫為主，可讀；Slave以讀為主，不能寫。 實現讀寫分離。
  • 缺點：不能自動故障轉移。
    
• 哨兵模式
  • 基於主從複製模式，哨兵本身就是redis一個例項，用來監視其他的例項。主節點宕機,採用選老大的方式處理故障，實現自動故障轉移。
  • 缺點：不能線上擴容。
• redis Sharding模式(客戶端分片)
  • 客戶端通過雜湊演算法將資料的key進行雜湊，對映到不同的redis節點中。Jedies就支援 Sharding功能。解決了線上擴容問題
  • 缺點：大量的處理放在客戶端,導致資料大。
• redis cluster模式(服務端分片)
  • 是redis Sharding模式的升級版，將叢集分為不同的卡槽(0~16383)，每個節點有一定數量的卡槽。 每一節點既是主節點，也是從節點,相互依賴。解決了擴容問題
  • 缺點：對於像批量操作,事務操作等的支援性不夠好

哨兵模式選老大的演算法?

• 哨兵通過傳送命令，等待Redis伺服器響應。如果主機宕機，哨兵1先檢查到這個資訊， 但是不會馬上進行選舉。這個過程稱為主觀下線。
• 當其他的哨兵也檢查到主機宕機，那麼哨兵之間會進行投票選取新的老大，選取成功之後,會通過釋出訂閱模式，讓各個從節點切換主機，這個過程成為客觀下線。
• 注意：如果已經客觀下線，就算主節點已經恢復，只能作為新的主節點的從節點

Cluster如何實現故障轉移

• Redis 叢集節點採用Gossip協議來廣播自己的狀態以及自己對整個叢集認知的改變。比如一個節點發現某個節點失聯了 (PFail)，它會將這條資訊向整個叢集廣播，其它節點也就可以收到這點失聯資訊。
• 如果一個節點收到了某個節點失聯的數量 已經達到了叢集的大多數，就可以標記該節點為確定下線狀態 (Fail)，然後向整個叢集廣播，強迫其它節點也接收該節點已經下線的事實，並立即對該失聯節點進行主從切換。

主從複製的原理?

• 全量複製
  • 主節點進行RDB或者AOF，然後將持久化檔案通過網路傳送給從節點，從節點開始啟動的時候進行讀取，此時從節點是同步的，不能進行資料訪問(因為也沒有資料)，需要消耗IO資源。
    
• 增量複製
  • 每次主節點更新資料，會發送給從節點，從節點根據偏移量進行增量複製。
    
  • 注意：因為IO非常消耗資源，每次增量進行持久化的時候，會把更新的資料放在主節點的一個叫做 複製積壓快取區的地方，傳送給從節點。這樣就不至於每次增量複製進行io操作。

上圖相關問題：

• runid：每一個redis例項都有一個id，區別身份。比如主節點發送給從節點就會把自己的id傳送過來。主節點宕機了,這個不能使用增量複製。
• 什麼時候會由增量複製變為全量複製?　　
  • runid不匹配(比如主節點宕機了,不是之前那個了)，或者複製積壓快取區放不下。

寄語：你所浪費的今天是昨天死去的人奢望的明天；你所厭惡的現在，是未來的你回不到的曾經 ---哈佛大學校訓

執行緒模型參照文章：https://www.cnblogs.com/mrmirror/p/13587311.html