您好,登錄后才能下訂單哦!
9個常見的Redis面試"刁難"問題
字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。
如果你是Redis中高級用戶,還需要加上下面幾種數據結構HyperLogLog、Geo、Pub/Sub。
如果你說還玩過Redis Module,像BloomFilter,RedisSearch,Redis-ML,面試官得眼睛就開始發亮了。
先拿setnx來爭搶鎖,搶到之后,再用expire給鎖加一個過期時間防止鎖忘記了釋放。
這時候對方會告訴你說你回答得不錯,然后接著問如果在setnx之后執行expire之前進程意外crash或者要重啟維護了,那會怎么樣?
這時候你要給予驚訝的反饋:唉,是喔,這個鎖就永遠得不到釋放了。緊接著你需要抓一抓自己得腦袋,故作思考片刻,好像接下來的結果是你主動思考出來的,然后回答:我記得set指令有非常復雜的參數,這個應該是可以同時把setnx和expire合成一條指令來用的!對方這時會顯露笑容,心里開始默念:摁,這小子還不錯。
使用keys指令可以掃出指定模式的key列表。
對方接著追問:如果這個redis正在給線上的業務提供服務,那使用keys指令會有什么問題?
這個時候你要回答redis關鍵的一個特性:redis的單線程的。keys指令會導致線程阻塞一段時間,線上服務會停頓,直到指令執行完畢,服務才能恢復。這個時候可以使用scan指令,scan指令可以無阻塞的提取出指定模式的key列表,但是會有一定的重復概率,在客戶端做一次去重就可以了,但是整體所花費的時間會比直接用keys指令長。
一般使用list結構作為隊列,rpush生產消息,lpop消費消息。當lpop沒有消息的時候,要適當sleep一會再重試。
如果對方追問可不可以不用sleep呢?list還有個指令叫blpop,在沒有消息的時候,它會阻塞住直到消息到來。
如果對方追問能不能生產一次消費多次呢?使用pub/sub主題訂閱者模式,可以實現1:N的消息隊列。
如果對方追問pub/sub有什么缺點?在消費者下線的情況下,生產的消息會丟失,得使用專業的消息隊列如rabbitmq等。
如果對方追問redis如何實現延時隊列?我估計現在你很想把面試官一棒打死如果你手上有一根棒球棍的話,怎么問的這么詳細。但是你很克制,然后神態自若的回答道:使用sortedset,拿時間戳作為score,消息內容作為key調用zadd來生產消息,消費者用zrangebyscore指令獲取N秒之前的數據輪詢進行處理。
到這里,面試官暗地里已經對你豎起了大拇指。但是他不知道的是此刻你卻豎起了中指,在椅子背后。
如果大量的key過期時間設置的過于集中,到過期的那個時間點,redis可能會出現短暫的卡頓現象。一般需要在時間上加一個隨機值,使得過期時間分散一些。
bgsave做鏡像全量持久化,aof做增量持久化。因為bgsave會耗費較長時間,不夠實時,在停機的時候會導致大量丟失數據,所以需要aof來配合使用。在redis實例重啟時,優先使用aof來恢復內存的狀態,如果沒有aof日志,就會使用rdb文件來恢復。
如果再問aof文件過大恢復時間過長怎么辦?你告訴面試官,Redis會定期做aof重寫,壓縮aof文件日志大小。如果面試官不夠滿意,再拿出殺手锏答案,Redis4.0之后有了混合持久化的功能,將bgsave的全量和aof的增量做了融合處理,這樣既保證了恢復的效率又兼顧了數據的安全性。這個功能甚至很多面試官都不知道,他們肯定會對你刮目相看。
如果對方追問那如果突然機器掉電會怎樣?取決于aof日志sync屬性的配置,如果不要求性能,在每條寫指令時都sync一下磁盤,就不會丟失數據。但是在高性能的要求下每次都sync是不現實的,一般都使用定時sync,比如1s1次,這個時候最多就會丟失1s的數據。
可以將多次IO往返的時間縮減為一次,前提是pipeline執行的指令之間沒有因果相關性。使用redis-benchmark進行壓測的時候可以發現影響redis的QPS峰值的一個重要因素是pipeline批次指令的數目。
Redis可以使用主從同步,從從同步。第一次同步時,主節點做一次bgsave,并同時將后續修改操作記錄到內存buffer,待完成后將rdb文件全量同步到復制節點,復制節點接受完成后將rdb鏡像加載到內存。加載完成后,再通知主節點將期間修改的操作記錄同步到復制節點進行重放就完成了同步過程。
Redis Sentinal著眼于高可用,在master宕機時會自動將slave提升為master,繼續提供服務。
Redis Cluster著眼于擴展性,在單個redis內存不足時,使用Cluster進行分片存儲。
Redis Cluster 是Redis的集群實現,內置數據自動分片機制,集群內部將所有的key映射到16384個Slot中,集群中的每個Redis Instance負責其中的一部分的Slot的讀寫。集群客戶端連接集群中任一Redis Instance即可發送命令,當Redis Instance收到自己不負責的Slot的請求時,會將負責請求Key所在Slot的Redis Instance地址返回給客戶端,客戶端收到后自動將原請求重新發往這個地址,對外部透明。一個Key到底屬于哪個Slot由crc16(key) % 16384 決定。
關于負載均衡,集群的Redis Instance之間可以遷移數據,以Slot為單位,但不是自動的,需要外部命令觸發。
關于集群成員管理,集群的節點(Redis Instance)和節點之間兩兩定期交換集群內節點信息并且更新,從發送節點的角度看,這些信息包括:集群內有哪些節點,IP和PORT是什么,節點名字是什么,節點的狀態(比如OK,PFAIL,FAIL,后面詳述)是什么,包括節點角色(master 或者 slave)等。
關于可用性,集群由N組主從Redis Instance組成。主可以沒有從,但是沒有從 意味著主宕機后主負責的Slot讀寫服務不可用。一個主可以有多個從,主宕機時,某個從會被提升為主,具體哪個從被提升為主,協議類似于Raft,參見這里。如何檢測主宕機?Redis Cluster采用quorum+心跳的機制。從節點的角度看,節點會定期給其他所有的節點發送Ping,cluster-node-timeout(可配置,秒級)時間內沒有收到對方的回復,則單方面認為對端節點宕機,將該節點標為PFAIL狀態。通過節點之間交換信息收集到quorum個節點都認為這個節點為PFAIL,則將該節點標記為FAIL,并且將其發送給其他所有節點,其他所有節點收到后立即認為該節點宕機。從這里可以看出,主宕機后,至少cluster-node-timeout時間內該主所負責的Slot的讀寫服務不可用。
文章來源:高可用架構
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。