用過Redis哪些數(shù)據(jù)類型？Redis String 類型的底層實現(xiàn)是什么?
基本數(shù)據(jù)類型：
- String：最常用的一種數(shù)據(jù)類型，String類型的值可以是字符串、數(shù)字或者二進制，但值最大不能超過512MB。一般用于 緩存和計數(shù)器
- Hash：Hash 是一個鍵值對集合。存儲商品的各個屬性
- Set：無序去重的集合。Set 提供了交集、并集等方法，對于實現(xiàn)共同好友、共同關(guān)注等功能特別方便。
- List：有序可重復的集合，底層是依賴雙向鏈表實現(xiàn)的。用于消息隊列
- SortedSet：有序Set。內(nèi)部維護了一個
score的參數(shù)來實現(xiàn)。適用于排行榜和帶權(quán)重的消息隊列等場景。
特殊的數(shù)據(jù)類型：
- Bitmap：位圖，可以認為是一個以位為單位數(shù)組，數(shù)組中的每個單元只能存0或者1，數(shù)組的下標在 Bitmap 中叫做偏移量。Bitmap的長度與集合中元素個數(shù)無關(guān)，而是與基數(shù)的上限有關(guān)。
- Hyperloglog。HyperLogLog 是用來做基數(shù)統(tǒng)計的算法，其優(yōu)點是，在輸入元素的數(shù)量或者體積非常非常大時，計算基數(shù)所需的空間總是固定的、并且是很小的。典型的使用場景是統(tǒng)計獨立訪客。
- Geospatial ：主要用于存儲地理位置信息，并對存儲的信息進行操作，適用場景如定位、附近的人等。
- Stream ：一種日志數(shù)據(jù)結(jié)構(gòu)，適合于存儲時間序列數(shù)據(jù)或消息流。支持高效的消息生產(chǎn)和消費模式，具有持久性和序列化特性。
SortedSet和List異同點？
相同點：
- 都是有序的；
- 都可以獲得某個范圍內(nèi)的元素。
不同點：
- 列表基于鏈表實現(xiàn)，獲取兩端元素速度快，訪問中間元素速度慢；
- 有序集合基于散列表和跳躍表實現(xiàn)，訪問中間元素時間復雜度是OlogN；
- 列表不能簡單的調(diào)整某個元素的位置，有序列表可以（更改元素的分數(shù)）；
- 有序集合更耗內(nèi)存。
Redis 怎么實現(xiàn)消息隊列？
BLPOP queue 0 //0表示不限制等待時間BLPOP和LPOP命令相似，唯一的區(qū)別就是當列表沒有元素時BLPOP命令會一直阻塞連接，直到有新元素加入。
redis可以通過pub/sub主題訂閱模式實現(xiàn)一個生產(chǎn)者，多個消費者，當然也存在一定的缺點，當消費者下線時，生產(chǎn)的消息會丟失。
PUBLISH channel1 hi
SUBSCRIBE channel1
UNSUBSCRIBE channel1 //退訂通過SUBSCRIBE命令訂閱的頻道。
PSUBSCRIBE channel?*按照規(guī)則訂閱。PUNSUBSCRIBE channel?*退訂通過PSUBSCRIBE命令按照某種規(guī)則訂閱的頻道。其中訂閱規(guī)則要進行嚴格的字符串匹配，PUNSUBSCRIBE *無法退訂channel?*規(guī)則。
如何在 Redis 中實現(xiàn)隊列和棧數(shù)據(jù)結(jié)構(gòu)?
可以通過 List 類型 來實現(xiàn) 隊列 和 棧
實現(xiàn)隊列(FIFO)：隊列是一種 先進先出(FIFO)的數(shù)據(jù)結(jié)構(gòu)。在Redis中，可以使用 PUSH 和 RPOP命令組合來實現(xiàn)隊列。LPUSH 向列表的左側(cè)推入元素，而 RPOP從列表的右側(cè)彈出元素，這樣可以保證最先進入的元素最先被彈出
實現(xiàn)棧(LIFO)：棧是一種 后進先出(LIFO)的數(shù)據(jù)結(jié)構(gòu)。在Redis 中，可以使用 LPUSH和 LPoP命令組合來實現(xiàn)棧。LPUSH 向列表的左側(cè)推入元素，而 LPoP從列表的左側(cè)彈出元素，這樣可以保證最后進入的元素最先被彈出。
Redis 怎么實現(xiàn)延時隊列
使用sortedset，拿時間戳作為score，消息內(nèi)容作為key，調(diào)用zadd來生產(chǎn)消息，消費者用zrangebyscore指令獲取N秒之前的數(shù)據(jù)輪詢進行處理。
如何使用 Redis 快速實現(xiàn)排行榜?
使用 Redis 實現(xiàn)排行榜的方式主要利用 Sorted Set(有序集合)，它可以高效地存儲、更新、以及獲取排名數(shù)據(jù)。實現(xiàn)排行榜的主要步驟：
- 使用 Sorted Set 存儲分數(shù)和成員：使用 Redis 的 ADD命令，將用戶和對應的分數(shù)添加到有序集合中。例如：add leaderboard 1000 user1，將用戶 user1 的分數(shù)設置為 1000。
- 獲取排名：使用 ZRANK命令獲取某個用戶的排名。例如：zrank leaderboard user1，返回用戶user1 的排名(從0開始)。
- 獲取前 N 名：使用 ZREVRANGE 命令獲取分數(shù)最高的前N名。例如：REVRANGE leaderboard 0 9 WITHSCORES ，獲取排行榜前 10 名用戶及其分數(shù)。
- 更新分數(shù)：如果用戶的分數(shù)需要更新，可以使用 ZINCRBY 命令對其分數(shù)進行加減操作。例如：ZINCRBY leaderboard 500 user1，將用戶 user1 的分數(shù)增加 500。
如何使用 Redis 快速實現(xiàn)布隆過濾器?
可以通過使用 位圖(Bitmap)或使用 Redis 模塊 RedisBloom。
- 使用位圖實現(xiàn)布隆過濾器：使用 Redis 的位圖結(jié)構(gòu) SETBIT 和 GETBIT 操作來實現(xiàn)布隆過濾器。位圖本質(zhì)上是一個比特數(shù)組，用于標識元素是否存在對于給定的數(shù)據(jù)，通過多個 哈希函數(shù) 計算位置索引，將位圖中的相應位置設置為 1，表示該元素可能存在。
- 使用 RedisBloom 模塊：Redis 提供了一個官方模塊 RedisBloom，封裝了哈希函數(shù)、位圖大小等操作，可以直接用于創(chuàng)建和管理布隆過濾器。使用 BF.ADD 來向布隆過濾器添加元素，使用 BF.EXISTS 來檢查某個元素是否可能存在,
如何使用 Redis 統(tǒng)計大量用戶唯一訪問量(UV)?
Redis 中 HyperLogLog 結(jié)構(gòu)，可以快速實現(xiàn)網(wǎng)頁UV、PV 等統(tǒng)計場景。它是一種基數(shù)估算算法的概率性數(shù)據(jù)結(jié)構(gòu)，可以用極少的內(nèi)存統(tǒng)計海量用戶唯一訪問量的近似值。
Set 也可以實現(xiàn)，用于精確統(tǒng)計唯一用戶訪問量，但是但當用戶數(shù)非常大時，內(nèi)存開銷較高。
Redis 中的 Geo 數(shù)據(jù)結(jié)構(gòu)是什么?
Redis中的 Geo(Geoloaton的簡寫形式，代表地理坐標) 數(shù)據(jù)結(jié)構(gòu)主要用于地理位置信息的存儲，通過這個結(jié)構(gòu)，可以方便地進行地理位置的存儲、檢索、以及計算地理距離等課作，GeO 數(shù)據(jù)結(jié)內(nèi)存層使用了 Sorted set， 并結(jié)合了Geohash 編碼算法來對地理位置進行處理。
Redis String 類型的底層實現(xiàn)是什么?(SDS)
Redis 中的 Sting 類型底層實現(xiàn)主要基于 SDS(Simple Dynamic string 簡單動態(tài)字符串)結(jié)構(gòu)，并結(jié)合 int、embstr、raw 等不同的編碼方式進行優(yōu)化存儲。
Redis 中的 Ziplist 和 Quicklist 數(shù)據(jù)結(jié)構(gòu)的特點是什么?
Ziplist：
- 簡單、緊湊、連續(xù)存儲，適用于小數(shù)據(jù)量場景，但對大量數(shù)據(jù)或頻繁的修改操作不太友好。
- 適合小數(shù)據(jù)量場景，例如短列表、小哈希表等，因為它的內(nèi)存緊湊，可以大幅減少內(nèi)存使用
Quicklist：
- 通過將鏈表和 Ziplist 結(jié)合，既實現(xiàn)了鏈表的靈活操作，又能節(jié)省內(nèi)存，在 Redis 3.2 之后成為 List 的默認實現(xiàn)。
- Quicklist是為了替代純而設計的，適用于需要頻繁對列表進行插入、刪除、查找等提作的場景，并目數(shù)據(jù)量可能較大，它在存儲多個元素時，既保留了鏈表的靈活性，又具備壓縮列表的內(nèi)存優(yōu)勢
Redis Zset 的實現(xiàn)原理是什么?
Redis 中的Zset(有序集合，Sorted set)是一種由 跳表 (Skip List)和哈希表 (Hash Table)組成的數(shù)據(jù)結(jié)構(gòu)，Zset 結(jié)合了集合 (Set)的特性和排序功能，能夠存儲具有唯一性的成員，并根據(jù)成員的分數(shù) (score) 進行排序
ZSet 的實現(xiàn)由兩個核心數(shù)據(jù)結(jié)構(gòu)組成：
- 跳表(Skip List)：用于存儲數(shù)據(jù)的排序和快速查找。
- 哈希表(Hash Table)：用于存儲成員與其分數(shù)的映射，提供快速查找
當 Zset 元素數(shù)量較少時，Redis 會使用壓縮列表(Zip List)來節(jié)省內(nèi)存
- 即元素個數(shù)≤ zset-max-ziplist-entries(默認 128)
- 元素成員名和分值的長度 ≤ zset-max-ziplist-value(默認 64 字節(jié))
如果任何一個條件不滿足，Zset 將使用 跳表 +哈希表 作為底層實現(xiàn),
Redis 的有序集合底層為什么要用跳表，而不用平衡樹、紅黑樹或者 B+樹？
這道面試題很多大廠比較喜歡問，難度還是有點大的。
- 平衡樹 vs 跳表：平衡樹的插入、刪除和查詢的時間復雜度和跳表一樣都是 **O(log n)**。對于范圍查詢來說，平衡樹也可以通過中序遍歷的方式達到和跳表一樣的效果。但是它的每一次插入或者刪除操作都需要保證整顆樹左右節(jié)點的絕對平衡，只要不平衡就要通過旋轉(zhuǎn)操作來保持平衡，這個過程是比較耗時的。跳表誕生的初衷就是為了克服平衡樹的一些缺點。跳表使用概率平衡而不是嚴格強制的平衡，因此，跳表中的插入和刪除算法比平衡樹的等效算法簡單得多，速度也快得多。
- 紅黑樹 vs 跳表：相比較于紅黑樹來說，跳表的實現(xiàn)也更簡單一些，不需要通過旋轉(zhuǎn)和染色（紅黑變換）來保證黑平衡。并且，按照區(qū)間來查找數(shù)據(jù)這個操作，紅黑樹的效率沒有跳表高。
- B+樹 vs 跳表：B+樹更適合作為數(shù)據(jù)庫和文件系統(tǒng)中常用的索引結(jié)構(gòu)之一，它的核心思想是通過盡可能少的 IO 定位到盡可能多的索引來獲得查詢數(shù)據(jù)。對于 Redis 這種內(nèi)存數(shù)據(jù)庫來說，它對這些并不感冒，因為 Redis 作為內(nèi)存數(shù)據(jù)庫它不可能存儲大量的數(shù)據(jù)，所以對于索引不需要通過 B+樹這種方式進行維護，只需按照概率進行隨機維護即可，節(jié)約內(nèi)存。而且使用跳表實現(xiàn) zset 時相較前者來說更簡單一些，在進行插入時只需通過索引將數(shù)據(jù)插入到鏈表中合適的位置再隨機維護一定高度的索引即可，也不需要像 B+樹那樣插入時發(fā)現(xiàn)失衡時還需要對節(jié)點分裂與合并。
Redis 中跳表的實現(xiàn)原理是什么?
跳表主要是通過多層鏈表來實現(xiàn)，底層鏈表保存所有元素，而每一層鏈表都是下一層的子集。
插入時，首先從最高層開始查找插入位置，然后隨機決定新節(jié)點的層數(shù)，最后在相應的層中插入節(jié)點并更新指針
刪除時，同樣從最高層開始查找要刪除的節(jié)點，并在各層中更新指針，以保持跳表的結(jié)構(gòu)。
查找時，從最高層開始，逐層向下，直到找到目標元素或確定元素不存在。查找效率高，時間復雜度為 O(logn)
Redis中的跳表是兩步兩步跳的嗎？
如果采用新增節(jié)點或者刪除節(jié)點時，來調(diào)整跳表節(jié)點以維持比例2：1的方法的話，顯然是會帶來額外開銷的。
跳表在創(chuàng)建節(jié)點時候，會生成范圍為[0-1]的一個隨機數(shù)，如果這個隨機數(shù)小于 0.25（相當于概率 25%），那么層數(shù)就增加 1 層，然后繼續(xù)生成下一個隨機數(shù)，直到隨機數(shù)的結(jié)果大于 0.25 結(jié)束，最終確定該節(jié)點的層數(shù)。因為隨機數(shù)取值在[0,0.25）范圍內(nèi)概率不會超過25%，所以這也說明了增加一層的概率不會超過25%。這樣的話，當插入一個新結(jié)點時，只需修改前后結(jié)點的指針，而其它結(jié)點的層數(shù)就不需要隨之改變了，這樣就降低插入操作的復雜度。
// #define ZSKIPLIST_P 0.25
int zslRandomLevel(void) {
static const int threshold = ZSKIPLIST_P*RAND_MAX;
int level = 1; //初始化為一級索引
while (random() < threshold)
level += 1;//隨機數(shù)小于 0.25就增加一層
//如果level 沒有超過最大層數(shù)就返回，否則就返回最大層數(shù)
return (level<ZSKIPLIST_MAXLEVEL) ? level : ZSKIPLIST_MAXLEVEL;
}Redis遇到哈希沖突怎么辦？
當有兩個或以上數(shù)量的鍵被分配到了哈希表數(shù)組的同一個索引上面時， 我們稱這些鍵發(fā)生了沖突（collision）。
關(guān)于解決hash沖突問題可以看這篇文章：解決哈希沖突的三種方法
而redis是先通過拉鏈法解決，再通過rehash來解決hash沖突問題的，即再hash法，只不過redis的hash使?jié)u進式hash
rehash原理？
漸進式 rehash 步驟如下：
- 先給
哈希表 2分配空間； - 在 rehash 進行期間，每次哈希表元素進行新增、刪除、查找或者更新操作時，Redis 除了會執(zhí)行對應的操作之外，還會順序?qū)?/span>
哈希表 1中索引位置上的所有 key-value 遷移到哈希表 2上； - 隨著處理客戶端發(fā)起的哈希表操作請求數(shù)量越多，最終在某個時間點會把
哈希表 1的所有 key-value 遷移到哈希表 2，從而完成 rehash 操作。
這樣就把一次性大量數(shù)據(jù)遷移工作的開銷，分攤到了多次處理請求的過程中，避免了一次性 rehash 的耗時操作。
在進行漸進式 rehash 的過程中，會有兩個哈希表，所以在漸進式 rehash 進行期間，哈希表元素的刪除、查找、更新等操作都會在這兩個哈希表進行。比如，在漸進式 rehash 進行期間，查找一個 key 的值的話，先會在哈希表 1里面進行查找，如果沒找到，就會繼續(xù)到哈希表 2 里面進行找到。新增一個 key-value 時，會被保存到哈希表 2里面，而哈希表 1則不再進行任何添加操作，這樣保證了哈希表 1的 key-value 數(shù)量只會減少，隨著 rehash 操作的完成，最終哈希表 1就會變成空表。
rehash的觸發(fā)條件？
負載因子 = 哈希表已保存節(jié)點數(shù)量/哈希表大小
觸發(fā) rehash 操作的條件，主要有兩個：
- 當負載因子大于等于 1 ，并且 Redis 沒有在執(zhí)行 bgsave 命令或者 bgrewiteaof 命令，也就是沒有執(zhí)行 RDB 快照或沒有進行 AOF 重寫的時候，就會進行 rehash 操作。
- 當負載因子大于等于 5 時，此時說明哈希沖突非常嚴重了，不管有沒有有在執(zhí)行 RDB 快照或 AOF 重寫，都會強制進行 rehash 操作
一個REDIS實例最多能存放多少KEYS
redis 的每個實例最多可以存放約 2^32 - 1 個keys，即大約 42 億個keys。這是由 Redis 內(nèi)部使用的哈希表實現(xiàn)決定的，它使用 32 位有符號整數(shù)作為索引。Redis 使用的哈希函數(shù)和負載因子等因素也會影響實際可存放鍵的數(shù)量。
需要注意的是，盡管 Redis 允許存儲數(shù)量龐大的鍵，但在實踐中，存儲過多的鍵可能會導致性能下降和內(nèi)存消耗增加。因此，在設計應用程序時，需要根據(jù)實際需求和硬件資源來合理規(guī)劃鍵的數(shù)量，避免過度使用 Redis 實例造成負擔。如果需要存儲更多的鍵值對，可以考慮使用 Redis 集群或分片技術(shù)，以擴展整體存儲容量。
