一. Redis介紹
1.1 redis 是什麼？
redis可以理解就是一個資料庫，不過與傳統資料庫不同的是 redis 的數據是存在內存中的，所以讀寫速度非常快，因此 redis 被廣泛應用於緩存方向。另外，redis 也經常用來做分布式鎖。redis 提供了多種數據類型來支持不同的業務場景。除此之外，redis 支持事務 、持久化、Lua腳本、LRU驅動事件、多種集群方案。
1.2 為什麼要用 redis？/為什麼要用緩存？
因為傳統的關係型資料庫如Mysql已經不能適用所有的場景了，比如秒殺的庫存扣減，APP首頁的訪問流量高峰等等，都很容易把資料庫打崩，所以引入了緩存中間件，目前市面上比較常用的緩存中間件有 Redis 和 memcached。
1.3 為什麼要用 redis 而不用 map/guava 做緩存?
緩存分為本地緩存和分布式緩存。以 Java 為例，使用自帶的 map 或者 guava 實現的是本地緩存，最主要的特點是輕量以及快速，生命周期隨著 jvm 的銷毀而結束。
使用 redis 或 Memcached 之類的稱為分布式緩存，在多實例的情況下，各實例共用一份緩存數據，緩存具有一致性。
缺點: 是需要保持 redis 或 memcached服務的高可用，整個程序架構上較為複雜。
1.4 Memcache 和 redis 對比
- redis支持更豐富的數據類型（支持更複雜的應用場景）：Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。memcache支持簡單的數據類型，string。
- Redis支持數據的持久化，可以將內存中的數據保持在磁碟中，重啟的時候可以再次加載進行使用,而Memecache把數據全部存在內存之中。
- 集群模式：memcached沒有原生的集群模式，需要依靠客戶端來實現往集群中分片寫入數據；但是 redis 目前是原生支持 cluster 模式的.
- Memcached是多線程，非阻塞IO復用的網絡模型；Redis使用單線程的多路 IO 復用模型。
1.5 redis 的線程模型
Redis基於Reactor模式開發了自己的網絡事件處理器，稱之為文件事件處理器(File Event Hanlder)。文件事件處理器由Socket、IO多路復用程序、文件事件分派器(dispather)，事件處理器(handler)四部分組成，文件事件處理器的模型如下所示：
IO多路復用程序會同時監聽多個socket，當被監聽的socket準備好執行accept、read、write、close等操作時，與這些操作相對應的文件事件就會產生。IO多路復用程序會把所有產生事件的socket壓入一個隊列中，然後有序地每次僅一個socket的方式傳送給文件事件分派器，文件事件分派器接收到socket之後會根據socket產生的事件類型調用對應的事件處理器進行處理。
1.6 Redis 為什麼是單線程的？
一直可能有個誤區，多線程 一定比 單線程 效率高，其實不然！多線程就涉及到上線文切換，CPU上下文的切換大概在 1500ns 左右。
redis 核心就是 如果我的數據全都在內存里，我單線程的去操作 就是效率最高的，為什麼呢？因為多線程的本質就是 CPU 模擬出來多個線程的情況，這種模擬出來的情況就有一個代價，就是上下文的切換，對於一個內存的系統來說，它沒有上下文的切換就是效率最高的。
1.7 redis的優缺點
優點：
1、支持多種數據類型 string、list、set、zset、Hash
2、數據可以持久化保持（AOF、快照），寫入硬碟，
3、支持災難恢復，主從複製。主機會自動將數據同步到從機，可以進行讀寫分離。
4、讀寫性能優異。
缺點：
1、redis不支持自動容錯和恢復功能，主從宕機都會導致前端讀寫失敗，需要手動重啟機器。
2、主機宕機，主從數據複製過程中，數據未完全複製到從機，會出現數據不一致。
1.8 redis為什麼快？
Redis採用的是基於內存的採用的是單進程單線程模型的 KV 資料庫，由C語言編寫，官方提供的數據是可以達到100000+的QPS（每秒內查詢次數）。
1、完全基於內存，絕大部分請求是純粹的內存操作，非常快速。它的，數據存在內存中，類似於HashMap。
2、數據結構簡單，對數據操作也簡單，Redis中的數據結構是專門進行設計的；
3、採用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導致的切換而消耗 CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的性能消耗；
4、使用多路I/O復用模型，非阻塞IO；
5、使用底層模型不同，它們之間底層實現方式以及與客戶端之間通信的應用協議不一樣，Redis直接自己構建了VM 機制 ，因為一般的系統調用系統函數的話，會浪費一定的時間去移動和請求
二. redis支持的數據結構
2.1 五種基本數據結構
String字符串類型
介紹
String 類型是 Redis 中最常使用的類型，內部的實現是通過 SDS（Simple Dynamic String ）來存儲的。SDS 類似於 Java 中的 ArrayList，可以通過預分配冗餘空間的方式來減少內存的頻繁分配。這是最簡單的類型，就是普通的 set 和 get，做簡單的 KV 緩存。
應用場景
1、緩存功能：String字符串是最常用的數據類型，不僅僅是Redis，各個語言都是最基本類型，因此，利用Redis作為緩存，配合其它資料庫作為存儲層，利用Redis支持高並發的特點，可以大大加快系統的讀寫速度、以及降低後端資料庫的壓力。
2、計數器：許多系統都會使用Redis作為系統的實時計數器，可以快速實現計數和查詢的功能。比如想知道什麼時候封鎖一個IP位址（訪問超過幾次），INCRBY命令讓這些變得很容易，通過原子遞增保持計數。
List列表類型
介紹
Redis中的List其實就是鍊表（Redis用雙端鍊表實現List）。使用List結構，我們可以輕鬆地實現最新消息排隊功能（比如新浪微博的TimeLine）。List的另一個應用就是消息隊列，可以利用List的 PUSH 操作，將任務存放在List中，然後工作線程再用 POP 操作將任務取出進行執行。
應用場景
1、消息隊列：Redis的鍊表結構，可以輕鬆實現阻塞隊列，可以使用左進右出的命令組成來完成隊列的設計。比如：數據的生產者可以通過Lpush命令從左邊插入數據，多個數據消費者，可以使用BRpop命令阻塞的「搶」列表尾部的數據。
Set集合類型
介紹
Redis的集合類型和列表都可以存儲多個字符串，它們的不同之處在於。列表可以存儲多個相同的字符串，而集合通過散列表來保證自己存儲的每個字符串都是各不相同的。
應用場景
1、共同好友、二度好友（並集、交集、差集運算）
2、利用唯一性，可以統計訪問網站的所有獨立IP
Hash散列類型
介紹
Redis的散列可以存儲多個鍵值對之間的映射。和字符串一樣，散列存儲的值既可以是字符串又可以是數字值。並且用戶同樣可以對散列存儲的數字進行自增或自減操作。
應用場景
適用於存儲對象（object）信息，如用戶詳細信息，用戶id為key，他的姓名、性別、年齡等信息為field-value。存儲多個用戶信息的化，可以將filed存為用戶id，每個用戶的信息序列化為json存於value。
有序集合Sorted set
介紹
Sorted set 是排序的 Set，去重但可以排序，寫進去的時候給一個分數，自動根據分數排序。有序集合的使用場景與集合類似，但是set集合不是自動有序的，而Sorted set可以利用分數進行成員間的排序，而且是插入時就排序好。所以當你需要一個有序且不重複的集合列表時，就可以選擇Sorted set數據結構作為選擇方案。
應用場景
1、排行榜：有序集合經典使用場景。例如視頻網站需要對用戶上傳的視頻做排行榜，榜單維護可能是多方面：按照時間、按照播放量、按照獲得的贊數等。
2、用Sorted Sets來做帶權重的隊列，比如普通消息的score為1，重要消息的score為2，然後工作線程可以選擇按score的倒序來獲取工作任務。讓重要的任務優先執行。
2.2 redis數據結構-高級篇
- Bitmap :位圖是支持按 bit 位來存儲信息，可以用來實現 布隆過濾器（BloomFilter）；
- HyperLogLog:供不精確的去重計數功能，比較適合用來做大規模數據的去重統計，例如統計 UV；
- Geospatial:可以用來保存地理位置，並作位置距離計算或者根據半徑計算位置等。比如用Redis來實現附近的人？或者計算最優地圖路徑？
- pub/sub：功能是訂閱發布功能，可以用作簡單的消息隊列。
- Pipeline：可以批量執行一組指令，一次性返回全部結果，可以減少頻繁的請求應答。
- Lua：Redis 支持提交 Lua 腳本來執行一系列的功能。
2.3 擴展-Bloom Filter
Bloom Filter
2.4 redis 事務
- 1 Redis事務的概念： Redis 提供的不是嚴格的事務，Redis 只保證串行執行命令，並且能保證全部執行，但是執行命令失敗時並不會回滾，而是會繼續執行下去。
- 2 Redis事務沒有隔離級別的概念： 批量操作在發送 EXEC 命令前被放入隊列緩存，並不會被實際執行，也就不存在事務內的查詢要看到事務里的更新，事務外查詢不能看到。
- 3 Redis不保證原子性： Redis中，單條命令是原子性執行的，但事務不保證原子性，且沒有回滾。事務中任意命令執行失敗，其餘的命令仍會被執行。
- 4 Redis事務的三個階段：開始事務命令入隊執行事務
- 5 Redis事務相關命令：
- watch key1 key2 ... : 監視一或多個key,如果在事務執行之前，被監視的key被其他命令改動，則事務被打斷 （ 類似樂觀鎖 ）
- multi : 標記一個事務塊的開始（ queued ）
- exec : 執行所有事務塊的命令 （ 一旦執行exec後，之前加的監控鎖都會被取消掉 ） discard : 取消事務，放棄事務塊中的所有命令
- unwatch : 取消watch對所有key的監控
三. redis-持久化
3.1持久化的實現方式
- 快照方式持久化：快照方式持久化就是在某時刻把所有數據進行完整備份。例：Mysql的Dump方式、Redis的RDB方式。
- 寫日誌方式持久化：寫日誌方式持久化就是把用戶執行的所有寫指令（增刪改）備份到文件中，還原數據時只需要把備份的所有指令重新執行一遍即可。例：Mysql的Binlog、Redis的AOF、Hbase的HLog。
3.2 兩種機制的對比
RDB
優點：他會生成多個數據文件，每個數據文件分別都代表了某一時刻Redis裡面的數據，這種方式，有沒有覺得很適合做冷備，完整的數據運維設置定時任務，定時同步到遠端的伺服器，比如阿里的雲服務，這樣一旦線上掛了，你想恢復多少分鐘之前的數據，就去遠端拷貝一份之前的數據就好了。RDB對Redis的性能影響非常小，是因為在同步數據的時候他只是fork了一個子進程去做持久化的，而且他在數據恢復的時候速度比AOF來的快。
缺點：RDB都是快照文件，都是默認五分鐘甚至更久的時間才會生成一次，這意味著你這次同步到下次同步這中間五分鐘的數據都很可能全部丟失掉。AOF則最多丟一秒的數據，數據完整性上高下立判。還有就是RDB在生成數據快照的時候，如果文件很大，客戶端可能會暫停幾毫秒甚至幾秒，你公司在做秒殺的時候他剛好在這個時候fork了一個子進程去生成一個大快照，哦豁，出大問題。
AOF
優點：上面提到了，RDB五分鐘一次生成快照，但是AOF是一秒一次去通過一個後台的線程fsync操作，那最多丟這一秒的數據。AOF在對日誌文件進行操作的時候是以append-only的方式去寫的，他只是追加的方式寫數據，自然就少了很多磁碟尋址的開銷了，寫入性能驚人，文件也不容易破損。AOF的日誌是通過一個叫非常可讀的方式記錄的，這樣的特性就適合做災難性數據誤刪除的緊急恢復了，比如公司的實習生通過flushall清空了所有的數據，只要這個時候後台重寫還沒發生，你馬上拷貝一份AOF日誌文件，把最後一條flushall命令刪了就完事了。
缺點：一樣的數據，AOF文件比RDB還要大。AOF開啟後，Redis支持寫的QPS會比RDB支持寫的要低，他不是每秒都要去異步刷新一次日誌嘛fsync，當然即使這樣性能還是很高，ElasticSearch也是這樣的，異步刷新緩存區的數據去持久化。
3.3 如何選擇使用哪種持久化方式？
一般來說， 如果想達到足以媲美 PostgreSQL 的數據安全性， 你應該同時使用兩種持久化功能。如果你非常關心你的數據， 但仍然可以承受數分鐘以內的數據丟失， 那麼你可以只使用 RDB 持久化。有很多用戶都只使用 AOF 持久化， 但並不推薦這種方式： 因為定時生成 RDB 快照（snapshot）非常便於進行資料庫備份， 並且 RDB 恢復數據集的速度也要比 AOF 恢復的速度要快。
四. redis-主從複製
4.1 什麼是主從複製
Redis的主從複製機制是指可以讓從伺服器(slave)能精確複製主伺服器(master)的數據
4.2 主從複製的方式
Redis的主從複製是異步複製，異步分為兩個方面，
一個是master伺服器在將數據同步到slave時是異步的，因此master伺服器在這裡仍然可以接收其他請求，另一個是slave在接收同步數據也是異步的。
複製方式Redis主從複製分為以下三種方式：
- 當master伺服器與slave伺服器正常連接時，master伺服器會發送數據命令流給slave伺服器,將自身數據的改變複製到slave伺服器。
- 當因為各種原因master伺服器與slave伺服器斷開後，slave伺服器在重新連上master伺服器時會嘗試重新獲取斷開後未同步的數據即部分同步，或者稱為部分複製。
- 如果無法部分同步(比如初次同步)，則會請求進行全量同步，這時master伺服器會將自己的rdb文件發送給slave伺服器進行數據同步，並記錄同步期間的其他寫入，再發送給slave伺服器，以達到完全同步的目的，這種方式稱為全量複製。
4.3 主從複製的原理
master伺服器會記錄一個replicationId的偽隨機字符串，用於標識當前的數據集版本，還會記錄一個當數據集的偏移量offset，不管master是否有配置slave伺服器，replication Id和offset會一直記錄並成對存在。
當master與slave正常連接時，slave使用PSYNC命令向master發送自己記錄的舊master的replication
id和offset，而master會計算與slave之間的數據偏移量，並將緩衝區中的偏移數量同步到slave，此時master和slave的數據一致。而如果slave引用的replication太舊了，master與slave之間的數據差異太大，則master與slave之間會使用全量複製的進行數據同步。
4.4 如何避免slave被清空
slave會被清空？slave不用同步了master的數據嗎？備份的數據怎麼會清空了呢？當master伺服器關閉了持久化時，如果發生故障後自動重啟時，由本地沒有保存持久化的數據，重啟的Redis內存數據為空，而slave會自動同步master的數據，這時候，slave伺服器的數據也會被清空。如何避免slave被清空呢？如果條件允許(一般都可以的)，master伺服器還是要開啟持久化，這樣master故障重啟時，可以快速恢復數據，而同步這台master的slave數據也不會被清空。如果master不能開啟持久化，則不應該設置讓master發生故障後重啟(有些機器會配置自動重啟)，而是將某個slave伺服器升級為master伺服器，對外繼續提供服務。
4.5 主從複製中的key過期問題
我們都知道Redis可以通過設置key的過期時間來限制key的生存時間，Redis處理key過期有惰性刪除和定期刪除兩種機制，而在配置主從複製後，slave伺服器就沒有權限處理過期的key，這樣的話，對於在master上過期的key，在slave伺服器就可能被讀取，所以master會累積過期的key，積累一定的量之後，發送del命令到slave，刪除slave上的key。如果slave伺服器升級為master伺服器 ，則它將開始獨立地計算key過期時間，而不需要通過master伺服器的幫助。
4.6 主從複製的作用
保存Redis數據副本當我們只是通過RDB或AOF把Redis的內存數據持久化畢竟只是在本地，並不能保證絕對的安全，而通過將數據同步slave伺服器上，可以保留多一個數據備份，更好地保證數據的安全。
讀寫分離單機QPS是有上限的，而且Redis的特性就是必須支撐讀高並發的，那你一台機器又讀又寫，這誰頂得住啊，不當人啊！但是你讓這個master機器去寫，數據同步給別的slave機器，他們都拿去讀，分發掉大量的請求那是不是好很多，而且擴容的時候還可以輕鬆實現水平擴容。
高可用性與故障轉移伺服器的高可用性是指伺服器能提供7*24小時不間斷的服務，Redis可以通過Sentinel系統管理多個Redis伺服器，當master伺服器發生故障時，Sentineal系統會根據一定的規則將某台slave伺服器升級為master伺服器,繼續提供服務，實現故障轉移，保證Redis服務不間斷。
4.7 Sentinel哨兵組件的主要功能
集群監控：負責監控 Redis master 和 slave 進程是否正常工作。
消息通知：如果某個 Redis 實例有故障，那麼哨兵負責發送消息作為報警通知給管理員。
故障轉移：如果 master node 掛掉了，會自動轉移到 slave node 上。
配置中心：如果故障轉移發生了，通知 client 客戶端新的 master 地址。
五.面試題
1、redis的基礎知識
2、redis內存淘汰機制
Redis的過期策略，是有定期刪除+惰性刪除兩種。
- volatile-lru：從已設置過期時間的數據集（server. db[i]. expires）中挑選最近最少使用的數據淘汰。
- volatile-ttl：從已設置過期時間的數據集（server. db[i]. expires）中挑選將要過期的數據淘汰。
- volatile-random：從已設置過期時間的數據集（server. db[i]. expires）中任意選擇數據淘汰。
- allkeys-lru：從數據集（server. db[i]. dict）中挑選最近最少使用的數據淘汰。
- allkeys-random：從數據集（server. db[i]. dict）中任意選擇數據淘汰。
- no-enviction（驅逐）：禁止驅逐數據。
3、主從複製時，數據傳輸的時候斷網了或者伺服器掛了怎麼辦啊？
傳輸過程中有什麼網絡問題啥的，會自動重連的，並且連接之後會把缺少的數據補上的。需要注意的就是，RDB快照的數據生成的時候，緩存區也必須同時開始接受新請求，不然你舊的數據過去了，你在同步期間的增量數據咋辦。
4、redis-緩存雪崩、擊穿、穿透
雪崩
同一時間所有的redis全部失效，所有的請求都打到資料庫。如何解決？處理緩存雪崩簡單，在批量往Redis存數據的時候，把每個Key的失效時間都加個隨機值就好了，這樣可以保證數據不會在同一時間大面積失效，或者設置熱點數據永遠不過期，有更新操作就更新緩存就好了（比如運維更新了首頁商品，那你刷下緩存就完事了，不要設置過期時間）。
什麼是緩存穿透和擊穿？它們跟雪崩的區別？
緩存穿透：是指緩存和資料庫中都沒有的數據，而用戶不斷發起請求，我們資料庫的 id 都是1開始自增上去的，如發起為id值為 -1 的數據或 id 為特別大不存在的數據。這時的用戶很可能是攻擊者，攻擊會導致資料庫壓力過大，嚴重會擊垮資料庫。Redis還有一個高級用法布隆過濾器（Bloom
Filter）這個也能很好的防止緩存穿透的發生，他的原理也很簡單就是利用高效的數據結構和算法快速判斷出你這個Key是否在資料庫中存在，不存在你return就好了，存在你就去查了DB刷新KV再return。
緩存擊穿：這個跟緩存雪崩有點像，但是又有一點不一樣，緩存雪崩是因為大面積的緩存失效，打崩了DB，而緩存擊穿不同的是緩存擊穿是指一個Key非常熱點，在不停的扛著大並發，大並發集中對這一個點進行訪問，當這個Key在失效的瞬間，持續的大並發就穿破緩存，直接請求資料庫，就像在一個完好無損的桶上鑿開了一個洞。
緩存穿透和緩存擊穿分別怎麼解決？
緩存穿透：我會在接口層增加校驗，比如用戶鑒權校驗，參數做校驗，不合法的參數直接代碼Return，比如：id 做基礎校驗，id <=0的直接攔截等。我們在開發程序的時候都要有一顆「不信任」的心，就是不要相信任何調用方，如果上游或者下游掛掉了怎麼辦，參數不合理怎麼處理等。
緩存擊穿：從緩存取不到的數據，在資料庫中也沒有取到，這時也可以將對應Key的Value對寫為null、位置錯誤、稍後重試這樣的值具體取啥問產品，或者看具體的場景，緩存有效時間可以設置短點，如30秒（設置太長會導致正常情況也沒法使用）。同時在獲取資料庫里的數據的時候，也需要進行加鎖控制，保證同一時間只有一個線程去請求資料庫，刷新緩存。還可以通過自旋的方式，或者信號量的方式
5、redis-哨兵、持久化、主從見上 redis-主從複製
6、LRU
7、redis 實現異步隊列
我們在實際開發中經常會有專業的消息隊列中間件，但是如果系統中沒有mq中間件，又懶得維護mq中間件，那麼我們可以通過redis來實現 因為redis並不是專業實現隊列的中間件，因此在實現方式上還是會存在一些問題，還是比不上rocketMq之類的中間件。redis實現隊列主要是使用數據結構中的list，因為它是按照塞入順序排序的結構，我們就可以按照左邊塞入，右邊取出的方式來實現先入先出的隊列需求 彈出時使用blpop的方法而不是lpop方法是因為如果使用lpop方法的話會造成如果隊列中沒有數據，連接一直空置的情況，所以使用blpop的方法可以在沒有數據的時候將連接阻塞，在有數據時再讀取 。 當然使用blpop同樣可能存在長時間沒有數據，redis將連接斷掉的情況，因此就需要我們在使用時將這種情況的異常也考慮進去，在catch中將連接重新建立之類。
8、緩存一致性問題怎麼解決？
先刪緩存，再更新資料庫
存在的問題
先刪除緩存，資料庫還沒有更新成功，此時如果讀取緩存，緩存不存在，去資料庫中讀取到的是舊值，緩存不一致發生。
解決方案
延時雙刪的方案的思路是，為了避免更新資料庫的時候，其他線程從緩存中讀取不到數據，就在更新完資料庫之後，再sleep一段時間，然後再次刪除緩存。sleep的時間要對業務讀寫緩存的時間做出評估，sleep時間大於讀寫緩存的時間即可。
流程如下：
1、線程1刪除緩存，然後去更新資料庫
2、線程2來讀緩存，發現緩存已經被刪除，所以直接從資料庫中讀取，這時候由於線程1還沒有更新完成，所以讀到的是舊值，然後把舊值寫入緩存
3、線程1，根據估算的時間，sleep，由於sleep的時間大於線程2讀數據+寫緩存的時間，所以緩存被再次刪除
4、如果還有其他線程來讀取緩存的話，就會再次從資料庫中讀取到最新值
先更新資料庫，再刪除緩存
存在的問題
反過來操作，先更新資料庫，再刪除緩存呢？這個就更明顯的問題了，更新資料庫成功，如果刪除緩存失敗或者還沒有來得及刪除，那麼，其他線程從緩存中讀取到的就是舊值，還是會發生不一致。
解決方案
消息隊列先更新資料庫，成功後往消息隊列發消息，消費到消息後再刪除緩存，藉助消息隊列的重試機制來實現，達到最終一致性的效果。這個解決方案其實問題更多。引入消息中間件之後，問題更複雜了，怎麼保證消息不丟失更麻煩就算更新資料庫和刪除緩存都沒有發生問題，消息的延遲也會帶來短暫的不一致性，不過這個延遲相對來說還是可以接受的
為了解決緩存一致性的問題單獨引入一個消息隊列，太複雜了。一般大公司本身都會有監聽binlog消息的消息隊列存在，主要是為了做一些核對的工作。這樣，我們可以藉助監聽binlog的消息隊列來做刪除緩存的操作。這樣做的好處是，不用你自己引入，侵入到你的業務代碼中，中間件幫你做了解耦，同時，中間件的這個東西本身就保證了高可用。當然，這樣消息延遲的問題依然存在，但是相比單純引入消息隊列的做法更好一點。如果並發不是特別高的話，這種做法的實時性和一致性都還算可以接受的。
設置緩存過期時間
每次放入緩存的時候，設置一個過期時間，比如5分鐘，以後的操作只修改資料庫，不操作緩存，等待緩存超時後從資料庫重新讀取。如果對於一致性要求不是很高的情況，可以採用這種方案。這個方案還會有另外一個問題，就是如果數據更新的特別頻繁，不一致性的問題就很大了。