Redis 支持哪幾種數(shù)據(jù)類型?
- string:最基本的數(shù)據(jù)類型,二進制安全的字符串,最大512M
- list:按照添加順序保持順序的 字符串列表
- set:無序的字符串集合,不存在重復的元素
- sorted set:已排序的字符串集合
- hash:key/value對的一種集合
Redis是單進程的還是單線程的?
Redis是單進程單線程的,Redis利用隊列技術(shù)將并發(fā)訪問變?yōu)榇性L問,消除了傳統(tǒng)數(shù)據(jù)庫串行控制的開銷。
Redis為什么是單線程的?
多線程處理會設(shè)計到鎖,而且多線程處理會設(shè)計到線程切換而消耗CPU。因為CPU不會Redis的瓶頸,Redis的瓶頸最有可能是機器內(nèi)存或者網(wǎng)絡(luò)帶寬。單線程無法發(fā)揮多核CPU性能,不過可以通過在單機開啟Redis實例來解決。
Redis的優(yōu)勢
- 速度快。因為數(shù)據(jù)存儲于內(nèi)存中,類似于HashMap,HashMap的優(yōu)勢就是查找和操作的時間復雜度都是O(1)
- 支持豐富的數(shù)據(jù)類型,支持string,list,set,sorted set,hash
- 支持事務,操作都是原子性,所謂的原子性就是對數(shù)據(jù)的更改要么全部執(zhí)行,要么全部不執(zhí)行
- 豐富的特性:可用于緩存,消息,按key設(shè)置過期時間,過期后將會自動刪除
Redis和memcached有哪些優(yōu)勢
- memcached所有的值均是簡單的字符串,Reids作為其替代者,支持更為豐富的數(shù)據(jù)類型
- Redis的速度比memcached快很多
- Redis可以持久化其數(shù)據(jù)
- Redis支持數(shù)據(jù)的備份,即master/slave模式的數(shù)據(jù)備份
Redis有哪幾種數(shù)據(jù)淘汰策略
在Redis中,允許用戶設(shè)置最大使用內(nèi)存大小server.maxmemory,當Redis內(nèi)存數(shù)據(jù)集大小上升到一定大小的時候,就會執(zhí)行數(shù)據(jù)淘汰策略
- volatile-lru:從已設(shè)置過期的數(shù)據(jù)集中挑選最近最少使用的淘汰
- volatile-ttl:從已設(shè)置過期的數(shù)據(jù)集中挑選將要過期的數(shù)據(jù)淘汰
- volatile-random:從已設(shè)置過期的數(shù)據(jù)集中任意挑選數(shù)據(jù)淘汰
- allkeys-lru:從數(shù)據(jù)集中挑選最近最少使用的數(shù)據(jù)淘汰
- allkeys-random:從數(shù)據(jù)集中任意挑選數(shù)據(jù)淘汰
- noenviction:禁止淘汰數(shù)據(jù)
Redis支持哪幾種持久化方式
原理是將Redis在內(nèi)存中的數(shù)據(jù)記錄定時dump到磁盤上的RDB文件
指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤,實際操作過程是fork一個子進程,先將數(shù)據(jù)集寫入臨時文件,寫入成功后,再替換之前的文件,用二進制壓縮存儲。
原理是將Redis的操作日志以追加的方式寫入文件。
以日志的形式記錄服務器所處理的每一個寫、刪除操作,查詢操作不會記錄,以文本的方式記錄,可以打開文件看到詳細的操作記錄。當服務器重啟的時候會重新執(zhí)行這些命令來恢復原始的數(shù)據(jù)。AOF命令以Reids協(xié)議追加保存每次寫的操作到文件末尾。Redis還能對AOF文件進行后臺重寫,使得AOF文件的體積不至于過大。
Redis兩種持久化方式優(yōu)缺點?
RDB持久化
優(yōu)點:RDB文件緊湊,體積小,網(wǎng)絡(luò)傳輸快,適合全量復制;恢復速度比AOF快很多。當然,與AOF相比,RDB最重要的優(yōu)點之一是對性能的影響相對較小
缺點:RDB文件的致命缺點在與其數(shù)據(jù)快照的持久化方式?jīng)Q定了必然做不到實時持久化,而在數(shù)據(jù)越來越重要的今天,數(shù)據(jù)的大量丟失很多時候是無法接受的,因此AOF持久化稱為主流。此外,RDB文件需要滿足特定格式,兼容性差。
AOF持久化
與RDB持久化相對應,AOF的優(yōu)點在于支持秒級持久化、兼容性好,缺點是文件大,恢復速度慢,對性能影響大
如何選擇Redis持久化方式策略?
在介紹持久化策略之前,首先要明白無論是RDB還是AOF,持久化的開啟都是要付出性能方面的代價的。對比RDB持久化,一方面是bdsave在進行fork操作時Redis主進程會阻塞,另一方面,子進程向硬盤寫數(shù)據(jù)也會帶來IO壓力;對于AOF持久化,向硬盤寫數(shù)據(jù)的頻率大大提高(everysec策略下為秒級),IO壓力更大,設(shè)置可能造成AOF追加阻塞文件。此外,AOF文件的重寫與RDB的basave類似,會有fork時的阻塞和子進程的IO壓力問題。相對來說,由于AOF向硬盤中寫數(shù)據(jù)的頻率更高,因此對Redis主進程性能的影響會更大。
在實際生產(chǎn)環(huán)境中,根據(jù)數(shù)據(jù)量、應用對數(shù)據(jù)的安全要求、預算限制等不同情況,會有各種各樣的持久化策略;如完全不使用任何持久化,使用RDB或AOF一種,或同事開啟RDB和AOF持久化等。此外,持久化的選擇必須與Redis的主從策略一起考慮,因為主從復制與持久化同樣具有數(shù)據(jù)備份的功能,而且主機master和從機slave可以獨立的選擇持久化方案。
Redis集群的主從復制模型是怎樣的?
為了是在部分節(jié)點失敗或者大部分節(jié)點無法通信的情況下集群仍然可用,所以集群是用了主從復制模型,每個節(jié)點都會有N-1個復制品
Redis集群會有寫操作丟失嗎?為什么?
Redis并不能保證數(shù)據(jù)強一致性,這意味著在實際中集群在特定的條件下可能會丟失寫操作
Redis集群之間是如何復制的
異步復制
Redis如何做內(nèi)存優(yōu)化
盡可能使用散列表(hashes),散列表(是說列表里面存儲的數(shù)少)使用的內(nèi)存非常小,所以你應該盡可能的將你的數(shù)據(jù)模型抽象到一個散列表里面,比如你的web系統(tǒng)中有一個用戶對象,不要為這個用戶的名稱,姓氏,郵箱,密碼設(shè)置單獨的key,而是應該把這個用戶所有信息存儲到一張散列表中
Redis回收進程如何工作?
一個Client運行了新的命令,添加了新的數(shù)據(jù),Redis會檢查內(nèi)存使用情況,如果大于maxmemory的限制,則根據(jù)設(shè)定好的策略進行回收
Redis常用的使用場景
- Session共享(單點登錄)
- 頁面緩存
- 隊列
- 排行榜/計算器
以上就是Redis面試必會的題目的詳細內(nèi)容,更多關(guān)于Redis面試題的資料請關(guān)注腳本之家其它相關(guān)文章!
您可能感興趣的文章:- Redis分析慢查詢操作的實例教程
- 淺析JavaWeb項目架構(gòu)之Redis分布式日志隊列
- java獲取redis日志信息與動態(tài)監(jiān)控信息的方法
- 如何高效使用Redis作為LRU緩存
- Linux安裝Redis實現(xiàn)過程及報錯解決方案
- spring boot+redis 監(jiān)聽過期Key的操作方法
- 在Docker中使用Redis的步驟詳解
- SpringBoot2.3整合redis緩存自定義序列化的實現(xiàn)
- Redis 執(zhí)行性能測試
- Redis緩存常用4種策略原理詳解
- Redis緩存穿透出現(xiàn)原因及解決方案
- 詳解Redis的慢查詢?nèi)罩?/li>