??大家好，我是陳哈哈，北漂五年，認識我的朋友們知道，我是非科班出身，半路出家，大學也很差！這種背景來北漂，你都不知道你會經歷什么🙃🙃，

??不敢茍同，相信大家和我一樣，都有一個大廠夢，作為一名資深Java選手，深知面試重要性，接下來我準備用100天時間，基于Java崗面試中的高頻面試題，以每日3題的形式，帶你過一遍熱門面試題及恰如其分的解答，當然，我不會太深入，因為我怕記不住！！

??因此，不足的地方希望各位在評論區補充疑惑、見解以及面試中遇到的奇葩問法，希望這100天能夠讓我們有質的飛越，一起沖進大廠！！，讓我們一起學（juan）起來！！！

坐標：西安 不夜城

??本欄目Java開發崗高頻面試題主要出自以下各技術堆疊：Java基礎知識、集合容器、并發編程、JVM、Spring全家桶、MyBatis等ORMapping框架、MySQL資料庫、Redis快取、RabbitMQ訊息佇列、Linux操作技巧等，

面試題1：介紹一下你對Redis哨兵模式的了解吧

正經回答：

??Redis在主從復制模式下，一旦主節點由于故障不能提供服務， 需要人工將從節點晉升為主節點， 同時還要通知應用方更新主節點地址， 對于很多應用場景這種故障處理的方式是無法接受的，這也是Redis主從復制的缺點之一，沒有辦法對master進行動態選舉， 可喜的是Redis從2.8開始正式提供了Redis Sentinel（哨兵） 機制來解決這個問題，

哨兵模式介紹

• Sentinel(哨兵)行程是用于監控redis集群中Master主服務器作業的狀態；

• 在Master主服務器發生故障的時候，可以實作Master和Slave服務器的切換，保證系統的高可用（HA）；

圖片來源：https://itpcb.com/a/259584

哨兵行程的作用

??通過發送命令，讓Redis服務器回傳監控其運行狀態，包括主服務器和從服務器，

??當哨兵監測到master宕機，會自動將slave切換成master，然后通過發布訂閱模式通知其他的從服務器，修改組態檔，讓它們切換主機，

??然而一個哨兵行程對Redis服務器進行監控，可能會出現問題，為此，我們可以使用多個哨兵進行監控，各個哨兵之間還會進行監控，這樣就形成了多哨兵模式，

深入追問：

追問1：介紹一下Redis故障自動切換程序：

??假設主服務器宕機，哨兵1先檢測到這個結果，系統并不會馬上進行failover程序，僅僅是哨兵1主觀的認為主服務器不可用，這個現象成為主觀下線，當后面的哨兵也檢測到主服務器不可用，并且數量達到一定值時，那么哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行failover操作，切換成功后，就會通過發布訂閱模式，讓各個哨兵把自己監控的從服務器實作切換主機，這個程序稱為客觀下線，

追問2：那你說一下主觀下線以及客觀下線的區別吧：

• 主觀下線（Subjectively Down， 簡稱 SDOWN）指的是單個 Sentinel 實體對服務器做出的下線判斷，

• 客觀下線（Objectively Down， 簡稱 ODOWN）指的是多個 Sentinel 實體在對同一個服務器做出 SDOWN 判斷， 并且通過 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服務器下線判斷，

??從主觀下線狀態切換到客觀下線狀態并沒有使用嚴格的法定人數演算法（strong quorum algorithm）， 而是使用了流言協議： 如果 Sentinel 在給定的時間范圍內， 從其他 Sentinel 那里接收到了足夠數量的主服務器下線報告， 那么 Sentinel 就會將主服務器的狀態從主觀下線改變為客觀下線， 如果之后其他 Sentinel 不再報告主服務器已下線， 那么客觀下線狀態就會被移除，

??客觀下線條件只適用于主服務器， 對于任何其他型別的 Redis 實體， Sentinel 在將它們判斷為下線前不需要進行協商， 所以從服務器或者其他 Sentinel 永遠不會達到客觀下線條件，

追問3：說一下哨兵行程的作業方式吧

• 每個Sentinel（哨兵）行程以每秒鐘一次的頻率向整個集群中的Master主服務器，Slave從服務器以及其他Sentinel（哨兵）行程發送一個 PING 命令，
• 如果一個實體（instance）距離最后一次有效回復 PING 命令的時間超過down-after-milliseconds選項所指定的值，則這個實體會被 Sentinel（哨兵）行程標記為主觀下線（SDOWN），
• 如果一個Master主服務器被標記為主觀下線（SDOWN），則正在監視這個Master主服務器的所有
• Sentinel（哨兵）行程要以每秒一次的頻率確認Master主服務器的確進入了主觀下線狀態，
• 當有足夠數量的 Sentinel（哨兵）行程（大于等于組態檔指定的值）在指定的時間范圍內確認Master主服務器進入了主觀下線狀態（SDOWN）， 則Master主服務器會被標記為客觀下線（ODOWN），
• 在一般情況下， 每個Sentinel（哨兵）行程會以每 10 秒一次的頻率向集群中的所有Master主服務器、Slave從服務器發送 INFO 命令，
• 當Master主服務器被 Sentinel（哨兵）行程標記為客觀下線（ODOWN）時，Sentinel（哨兵）行程向下線的 Master主服務器的所有 Slave從服務器發送 INFO 命令的頻率會從 10 秒一次改為每秒一次，
• 若沒有足夠數量的 Sentinel（哨兵）行程同意 Master主服務器下線， Master主服務器的客觀下線狀態就會被移除，若 Master主服務器重新向 Sentinel（哨兵）行程發送 PING 命令回傳有效回復，Master主服務器的主觀下線狀態就會被移除，

Redis配置哨兵模式

配置3個哨兵和1主2從的Redis服務器來演示這個程序，

??首先配置Redis的主從服務器，修改redis.conf檔案如下

# 使得Redis服務器可以跨網路訪問
bind 0.0.0.0
# 設定密碼
requirepass "123456"
# 指定主服務器，注意：有關slaveof的配置只是配置從服務器，主服務器不需要配置
slaveof 192.168.101.90 6379
# 主服務器密碼，注意：有關slaveof的配置只是配置從服務器，主服務器不需要配置
masterauth 123456
# 上述內容主要是配置Redis服務器，從服務器比主服務器多一個slaveof的配置和密碼，

??配置3個哨兵，每個哨兵的配置都是一樣的，在Redis安裝目錄下有一個sentinel.conf檔案，copy一份進行修改

# 禁止保護模式
protected-mode no
# 配置監聽的主服務器，這里sentinel monitor代表監控，mymaster代表服務器的名稱，可以自定義，192.168.101.90代表監控的主服務器，6379代表埠，2代表只有兩個或兩個以上的哨兵認為主服務器不可用的時候，才會進行failover操作，
sentinel monitor mymaster 192.168.101.90 6379 2
# sentinel author-pass定義服務的密碼，mymaster是服務名稱，123456是Redis服務器密碼
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456

關鍵配置項：

sentinel monitor mymaster 192.168.101.90 6379 2

??配置監聽的主服務器，這里sentinel monitor代表監控，mymaster代表服務器的名稱，可以自定義，192.168.101.90代表監控的主服務器，6379代表埠，2代表只有兩個或兩個以上的哨兵認為主服務器不可用的時候，才會進行failover操作，

??有了上述的修改，我們可以進入Redis的安裝目錄的src目錄，通過下面的命令啟動服務器和哨兵

# 啟動Redis服務器行程
./redis-server ../redis.conf
# 啟動哨兵行程
./redis-sentinel ../sentinel.conf

??注意啟動的順序，首先是主機（192.168.101.90）的Redis服務行程，然后啟動從機的服務行程，最后啟動3個哨兵的服務行程，

課間休息，欣賞一下來自咱們SQL大腿群同學的搬磚工地，坐標：上海，

面試題2：redis 的過期策略和記憶體淘汰策略是一個東西么？

正經回答：

??過期策略和記憶體淘汰策略乍一看相似，但卻不是一個事兒，我們知道，往 redis 寫入的資料會消失很正常的，在生產環境的 redis 經常會丟掉一些資料，寫進去了，過一會兒可能就沒了？這不是BUG，因為redis 是快取，不是資料庫，

??快取主要存在記憶體中，記憶體空間是有限的，比如 redis 就只能用 10G，你要是往里面寫了 20G 的資料，會咋辦？當然會干掉 10G 的資料，保留另外 10G 資料，那么干掉哪些資料，保留哪些資料呢？當然要根據熱度干掉不常用的資料，

??資料已經過期了，怎么還占用著記憶體？這是由 redis 的過期策略來決定，

redis 過期策略

??在Redis中過期的key不會立刻從記憶體中洗掉，而是會同時以下面兩種策略進行洗掉：

• 定期洗掉：每隔一段時間，隨機檢查設定了過期的key并洗掉已過期的key；維護定時器消耗CPU資源；
• 惰性洗掉：當key被訪問時檢查該key的過期時間，若已過期則洗掉；已過期未被訪問的資料仍保持在記憶體中，消耗記憶體資源；

定期洗掉

Redis每 100ms 進行一次過期掃描：

1. 隨機取20個設定了過期策略的key；
2. 檢查20個key中過期時間中已過期的key并洗掉；
3. 如果有超過25%的key已過期則重復第一步；

??這種回圈隨機操作會持續到過期key可能僅占全部key的25%以下時，并且為了保證不會出現回圈過多的情況，默認掃描時間不會超過25ms；

惰性洗掉

??定期洗掉可能會導致很多過期 key 到了時間并沒有被洗掉掉，那咋整呢？所以就是惰性洗掉了，這就是說，在你獲取某個 key 的時候，redis 會檢查一下 ，這個 key 如果設定了過期時間那么是否過期了？如果過期了此時就會洗掉，不會給你回傳任何東西，

??獲取 key 的時候，如果此時 key 已經過期，就洗掉，不會回傳任何東西，

??但是實際上這還是有問題的，如果定期洗掉漏掉了很多過期 key，然后你也沒及時去查，也就沒走惰性洗掉，此時會怎么樣？如果大量過期 key 堆積在記憶體里，導致 redis 記憶體塊耗盡了，咋整？

??那這就要提到了Redis的記憶體淘汰機制，

記憶體淘汰機制

??Redis的記憶體淘汰策略是指在Redis的用于快取的記憶體不足時，怎么處理需要新寫入且需要申請額外空間的資料，如何淘汰舊資料給新資料騰出記憶體空間，

redis 記憶體淘汰機制有以下幾個：

• noeviction：當記憶體不足以容納新寫入資料時，新寫入操作會報錯，

• allkeys-lru：當記憶體不足以容納新寫入資料時，在鍵空間中，移除最近最少使用的key，（這個是最常用的）

• allkeys-random：當記憶體不足以容納新寫入資料時，在鍵空間中，隨機移除某個key，

• volatile-lru：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，移除最近最少使用的key，

• volatile-random：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，隨機移除某個key，

• volatile-ttl：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，有更早過期時間的key優先移除，

??Redis的記憶體淘汰策略的選取并不會影響過期的key的處理，記憶體淘汰策略用于處理記憶體不足時的需要申請額外空間的資料；過期策略用于處理過期的快取資料，

深入追問：

追問1： 簡單介紹一下LRU淘汰機制吧

??LRU（Least recently used），淘汰最近最少使用的；演算法根據資料的歷史訪問記錄來進行淘汰資料，其核心思想是“如果資料最近被訪問過，那么將來被訪問的幾率也更高”，

演算法思路：

• 新資料插入到鏈表頭部；
• 每當快取命中（即快取資料被訪問），則將資料移到鏈表頭部；
• 當鏈表滿的時候，將鏈表尾部的資料丟棄，

??在服務器配置中保存了 lru 計數器 server.lrulock，會定時（redis 定時程式 serverCorn()）更新，server.lrulock 的值是根據 server.unixtime 計算出來進行排序的，然后選擇最近使用時間最久的資料進行洗掉，另外，從 struct redisObject 中可以發現，每一個 redis 物件都會設定相應的 lru，每一次訪問資料，會更新對應redisObject.lru

??在Redis中，LRU演算法是一個近似演算法，默認情況下，Redis會隨機挑選5個鍵，并從中選擇一個最久未使用的key進行淘汰，在組態檔中，按maxmemory-samples選項進行配置，選項配置越大，消耗時間就越長，但結構也就越精準，

追問2：Redis的記憶體用完了會發生什么實際問題？

??如果達到設定的上限，Redis的寫命令會回傳錯誤資訊（但是讀命令還可以正常回傳，）或者你可以配置記憶體淘汰機制，當Redis達到記憶體上限時會沖刷掉舊的內容，

追問3：Redis如何做記憶體優化？

??可以好好利用Hash,list,sorted set,set等集合型別資料，因為通常情況下很多小的Key-Value可以用更緊湊的方式存放到一起，盡可能使用散串列（hashes），散串列（是說散串列里面存盤的數少）使用的記憶體非常小，所以你應該盡可能的將你的資料模型抽象到一個散串列里面，比如你的web系統中有一個用戶物件，不要為這個用戶的名稱，姓氏，郵箱，密碼設定單獨的key，而是應該把這個用戶的所有資訊存盤到一張散串列里面，

課間休息，欣賞一下來自咱們SQL大腿群同學的搬磚工地，坐標：濟南，

面試題3：在實際生產環境中的 redis 你是怎么部署的？說一服務器情況吧

正經回答：

??redis cluster，我們線上是用了 5 臺服務器（32G 記憶體+ 8 核 CPU + 1T 磁盤），每臺服務器劃了兩臺虛擬機共10臺，5 臺機器部署了 redis 主實體，另外 5 臺機器部署了 redis 的從實體， 每個主實體掛了一個從實體，5 個節點對外提供讀寫服務，每個節點的讀寫高峰 qps 可能可以達到每秒 5 萬，5 臺機器最多是 25 萬讀寫請求/s，

??分配給 redis 行程的記憶體是 10g，一般線上生產環境，redis 的記憶體盡量不要超過 10g，超過 10g 可能會有問題，5 臺機器對外提供讀寫，一共有 50g 記憶體，

??因為每個主實體都掛了一個從實體，所以是高可用的，任何一個主實體宕機，都會自動故障遷移，redis 從實體會自動變成主實體繼續提供讀寫服務，

??我們主要存的是熱點商品資料，每條資料是 10kb，100 條資料是 1mb，10 萬條資料是 1g，常駐記憶體的是 200 萬條商品資料，占用記憶體是 20g，僅僅不到總記憶體的 50%，目前高峰期每秒就是 3500 左右的請求量，

每日小結

??今天我們復習了面試中常考的Redis三個問題，你做到心中有數了么？對了，如果你的朋友也在準備面試，請將這個系列扔給他，如果他認真對待，肯定會感謝你的！！好了，今天就到這里，學廢了的同學，記得在評論區留言：打卡，，給同學們以激勵，