1.如果你想new一個(gè)Quene，你有幾種方式？他們之間的區(qū)別是什么？

2.Redis 是如何判斷數(shù)據(jù)是否過(guò)期的呢？

Redis 通過(guò)一個(gè)叫做過(guò)期字典（可以看作是 hash 表）來(lái)保存數(shù)據(jù)過(guò)期的時(shí)間。過(guò)期字典的鍵指向 Redis 數(shù)據(jù)庫(kù)中的某個(gè) key(鍵)，過(guò)期字典的值是一個(gè) long long 類(lèi)型的整數(shù)，這個(gè)整數(shù)保存了 key 所指向的數(shù)據(jù)庫(kù)鍵的過(guò)期時(shí)間（毫秒精度的 UNIX 時(shí)間戳）。

過(guò)期字典是存儲(chǔ)在 redisDb 這個(gè)結(jié)構(gòu)里的：

?typedef struct redisDb {...?dict *dict; ? ? //數(shù)據(jù)庫(kù)鍵空間,保存著數(shù)據(jù)庫(kù)中所有鍵值對(duì)dict *expires ? // 過(guò)期字典,保存著鍵的過(guò)期時(shí)間...} redisDb;

3.Redis中常用的過(guò)期數(shù)據(jù)的刪除策略就兩個(gè)（重要！自己造緩存輪子的時(shí)候需要格外考慮的東西）：

1. 惰性刪除 ：只會(huì)在取出 key 的時(shí)候才對(duì)數(shù)據(jù)進(jìn)行過(guò)期檢查。這樣對(duì) CPU 最友好，但是可能會(huì)造成太多過(guò)期 key 沒(méi)有被刪除。

2. 定期刪除 ： 每隔一段時(shí)間抽取一批 key 執(zhí)行刪除過(guò)期 key 操作。并且，Redis 底層會(huì)通過(guò)限制刪除操作執(zhí)行的時(shí)長(zhǎng)和頻率來(lái)減少刪除操作對(duì) CPU 時(shí)間的影響。

定期刪除對(duì)內(nèi)存更加友好，惰性刪除對(duì) CPU 更加友好。兩者各有千秋，所以 Redis 采用的是 定期刪除+惰性/懶漢式刪除 。

4.Redis 事務(wù)支持原子性嗎？

Redis 事務(wù)在運(yùn)行錯(cuò)誤的情況下，除了執(zhí)行過(guò)程中出現(xiàn)錯(cuò)誤的命令外，其他命令都能正常執(zhí)行。并且，Redis 事務(wù)是不支持回滾（roll back）操作的。因此，Redis 事務(wù)其實(shí)是不滿足原子性的。

5.什么是緩存穿透？

緩存穿透說(shuō)簡(jiǎn)單點(diǎn)就是大量請(qǐng)求的 key 是不合理的，根本不存在于緩存中，也不存在于數(shù)據(jù)庫(kù)中 。這就導(dǎo)致這些請(qǐng)求直接到了數(shù)據(jù)庫(kù)上，根本沒(méi)有經(jīng)過(guò)緩存這一層，對(duì)數(shù)據(jù)庫(kù)造成了巨大的壓力，可能直接就被這么多請(qǐng)求弄宕機(jī)了。

有哪些解決辦法？

最基本的就是首先做好參數(shù)校驗(yàn)，一些不合法的參數(shù)請(qǐng)求直接拋出異常信息返回給客戶(hù)端。比如查詢(xún)的數(shù)據(jù)庫(kù) id 不能小于 0、傳入的郵箱格式不對(duì)的時(shí)候直接返回錯(cuò)誤消息給客戶(hù)端等等。

>>緩存無(wú)效 key

如果緩存和數(shù)據(jù)庫(kù)都查不到某個(gè) key 的數(shù)據(jù)就寫(xiě)一個(gè)到 Redis 中去并設(shè)置過(guò)期時(shí)間，具體命令如下： SET key value EX 10086 。這種方式可以解決請(qǐng)求的 key 變化不頻繁的情況，如果黑客惡意攻擊，每次構(gòu)建不同的請(qǐng)求 key，會(huì)導(dǎo)致 Redis 中緩存大量無(wú)效的 key 。很明顯，這種方案并不能從根本上解決此問(wèn)題!

>>布隆過(guò)濾器

布隆過(guò)濾器是一個(gè)非常神奇的數(shù)據(jù)結(jié)構(gòu)，通過(guò)它我們可以非常方便地判斷一個(gè)給定數(shù)據(jù)是否存在于海量數(shù)據(jù)中。我們需要的就是判斷 key 是否合法，有沒(méi)有感覺(jué)布隆過(guò)濾器就是我們想要找的那個(gè)“人”。

具體是這樣做的：把所有可能存在的請(qǐng)求的值都存放在布隆過(guò)濾器中，當(dāng)用戶(hù)請(qǐng)求過(guò)來(lái)，先判斷用戶(hù)發(fā)來(lái)的請(qǐng)求的值是否存在于布隆過(guò)濾器中。不存在的話，直接返回請(qǐng)求參數(shù)錯(cuò)誤信息給客戶(hù)端，存在的話才會(huì)走下面的流程。

加入布隆過(guò)濾器之后的緩存處理流程圖如下。

但是，需要注意的是布隆過(guò)濾器可能會(huì)存在誤判的情況?？偨Y(jié)來(lái)說(shuō)就是： 布隆過(guò)濾器說(shuō)某個(gè)元素存在，小概率會(huì)誤判。布隆過(guò)濾器說(shuō)某個(gè)元素不在，那么這個(gè)元素一定不在。

6.什么是緩存擊穿？

緩存擊穿中，請(qǐng)求的 key 對(duì)應(yīng)的是 熱點(diǎn)數(shù)據(jù) ，該數(shù)據(jù) 存在于數(shù)據(jù)庫(kù)中，但不存在于緩存中（通常是因?yàn)榫彺嬷械哪欠輸?shù)據(jù)已經(jīng)過(guò)期） 。這就可能會(huì)導(dǎo)致瞬時(shí)大量的請(qǐng)求直接打到了數(shù)據(jù)庫(kù)上，對(duì)數(shù)據(jù)庫(kù)造成了巨大的壓力，可能直接就被這么多請(qǐng)求弄宕機(jī)了。

舉個(gè)例子 ：秒殺進(jìn)行過(guò)程中，緩存中的某個(gè)秒殺商品的數(shù)據(jù)突然過(guò)期，這就導(dǎo)致瞬時(shí)大量對(duì)該商品的請(qǐng)求直接落到數(shù)據(jù)庫(kù)上，對(duì)數(shù)據(jù)庫(kù)造成了巨大的壓力。

有哪些解決辦法？

• 設(shè)置熱點(diǎn)數(shù)據(jù)永不過(guò)期或者過(guò)期時(shí)間比較長(zhǎng)。

• 針對(duì)熱點(diǎn)數(shù)據(jù)提前預(yù)熱，將其存入緩存中并設(shè)置合理的過(guò)期時(shí)間比如秒殺場(chǎng)景下的數(shù)據(jù)在秒殺結(jié)束之前不過(guò)期。

• 請(qǐng)求數(shù)據(jù)庫(kù)寫(xiě)數(shù)據(jù)到緩存之前，先獲取互斥鎖，保證只有一個(gè)請(qǐng)求會(huì)落到數(shù)據(jù)庫(kù)上，減少數(shù)據(jù)庫(kù)的壓力。

# 緩存穿透和緩存擊穿有什么區(qū)別？

緩存穿透中，請(qǐng)求的 key 既不存在于緩存中，也不存在于數(shù)據(jù)庫(kù)中。

緩存擊穿中，請(qǐng)求的 key 對(duì)應(yīng)的是 熱點(diǎn)數(shù)據(jù) ，該數(shù)據(jù) 存在于數(shù)據(jù)庫(kù)中，但不存在于緩存中（通常是因?yàn)榫彺嬷械哪欠輸?shù)據(jù)已經(jīng)過(guò)期） 。

7.什么是緩存雪崩？

我發(fā)現(xiàn)緩存雪崩這名字起的有點(diǎn)意思，哈哈。

實(shí)際上，緩存雪崩描述的就是這樣一個(gè)簡(jiǎn)單的場(chǎng)景：緩存在同一時(shí)間大面積的失效，導(dǎo)致大量的請(qǐng)求都直接落到了數(shù)據(jù)庫(kù)上，對(duì)數(shù)據(jù)庫(kù)造成了巨大的壓力。 這就好比雪崩一樣，摧枯拉朽之勢(shì)，數(shù)據(jù)庫(kù)的壓力可想而知，可能直接就被這么多請(qǐng)求弄宕機(jī)了。

另外，緩存服務(wù)宕機(jī)也會(huì)導(dǎo)致緩存雪崩現(xiàn)象，導(dǎo)致所有的請(qǐng)求都落到了數(shù)據(jù)庫(kù)上。

舉個(gè)例子 ：數(shù)據(jù)庫(kù)中的大量數(shù)據(jù)在同一時(shí)間過(guò)期，這個(gè)時(shí)候突然有大量的請(qǐng)求需要訪問(wèn)這些過(guò)期的數(shù)據(jù)。這就導(dǎo)致大量的請(qǐng)求直接落到數(shù)據(jù)庫(kù)上，對(duì)數(shù)據(jù)庫(kù)造成了巨大的壓力。

# 有哪些解決辦法？

針對(duì) Redis 服務(wù)不可用的情況：

1. 采用 Redis 集群，避免單機(jī)出現(xiàn)問(wèn)題整個(gè)緩存服務(wù)都沒(méi)辦法使用。

2. 限流，避免同時(shí)處理大量的請(qǐng)求。

針對(duì)熱點(diǎn)緩存失效的情況：

1. 設(shè)置不同的失效時(shí)間比如隨機(jī)設(shè)置緩存的失效時(shí)間。

2. 緩存永不失效（不太推薦，實(shí)用性太差）。

3. 設(shè)置二級(jí)緩存。

# 緩存雪崩和緩存擊穿有什么區(qū)別？

緩存雪崩和緩存擊穿比較像，但緩存雪崩導(dǎo)致的原因是緩存中的大量或者所有數(shù)據(jù)失效，緩存擊穿導(dǎo)致的原因主要是某個(gè)熱點(diǎn)數(shù)據(jù)不存在與緩存中（通常是因?yàn)榫彺嬷械哪欠輸?shù)據(jù)已經(jīng)過(guò)期）

8.如果我想實(shí)現(xiàn)微信里邊的每天步數(shù)自動(dòng)排序的功能，Redis中那個(gè)數(shù)據(jù)結(jié)構(gòu)比較合適？

Sorted Set

9.Redis持久化機(jī)制

Redis 不同于 Memcached 的很重要一點(diǎn)就是，Redis 支持持久化，而且支持 3 種持久化方式:

• 快照（snapshotting，RDB）

• 只追加文件（append-only file, AOF）

• RDB 和 AOF 的混合持久化(Redis 4.0 新增)

如何選擇 RDB 和 AOF？

關(guān)于 RDB 和 AOF 的優(yōu)缺點(diǎn)，官網(wǎng)上面也給了比較詳細(xì)的說(shuō)明Redis persistenceopen in new window，這里結(jié)合自己的理解簡(jiǎn)單總結(jié)一下。

RDB 比 AOF 優(yōu)秀的地方 ：

• RDB 文件存儲(chǔ)的內(nèi)容是經(jīng)過(guò)壓縮的二進(jìn)制數(shù)據(jù)， 保存著某個(gè)時(shí)間點(diǎn)的數(shù)據(jù)集，文件很小，適合做數(shù)據(jù)的備份，災(zāi)難恢復(fù)。AOF 文件存儲(chǔ)的是每一次寫(xiě)命令，類(lèi)似于 MySQL 的 binlog 日志，通常會(huì)比 RDB 文件大很多。當(dāng) AOF 變得太大時(shí)，Redis 能夠在后臺(tái)自動(dòng)重寫(xiě) AOF。新的 AOF 文件和原有的 AOF 文件所保存的數(shù)據(jù)庫(kù)狀態(tài)一樣，但體積更小。不過(guò)， Redis 7.0 版本之前，如果在重寫(xiě)期間有寫(xiě)入命令，AOF 可能會(huì)使用大量?jī)?nèi)存，重寫(xiě)期間到達(dá)的所有寫(xiě)入命令都會(huì)寫(xiě)入磁盤(pán)兩次。

• 使用 RDB 文件恢復(fù)數(shù)據(jù)，直接解析還原數(shù)據(jù)即可，不需要一條一條地執(zhí)行命令，速度非?？?。而 AOF 則需要依次執(zhí)行每個(gè)寫(xiě)命令，速度非常慢。也就是說(shuō)，與 AOF 相比，恢復(fù)大數(shù)據(jù)集的時(shí)候，RDB 速度更快。

AOF 比 RDB 優(yōu)秀的地方 ：

• RDB 的數(shù)據(jù)安全性不如 AOF，沒(méi)有辦法實(shí)時(shí)或者秒級(jí)持久化數(shù)據(jù)。生成 RDB 文件的過(guò)程是比較繁重的， 雖然 BGSAVE 子進(jìn)程寫(xiě)入 RDB 文件的工作不會(huì)阻塞主線程，但會(huì)對(duì)機(jī)器的 CPU 資源和內(nèi)存資源產(chǎn)生影響，嚴(yán)重的情況下甚至?xí)苯影?Redis 服務(wù)干宕機(jī)。AOF 支持秒級(jí)數(shù)據(jù)丟失（取決 fsync 策略，如果是 everysec，最多丟失 1 秒的數(shù)據(jù)），僅僅是追加命令到 AOF 文件，操作輕量。

• RDB 文件是以特定的二進(jìn)制格式保存的，并且在 Redis 版本演進(jìn)中有多個(gè)版本的 RDB，所以存在老版本的 Redis 服務(wù)不兼容新版本的 RDB 格式的問(wèn)題。

• AOF 以一種易于理解和解析的格式包含所有操作的日志。你可以輕松地導(dǎo)出 AOF 文件進(jìn)行分析，你也可以直接操作 AOF 文件來(lái)解決一些問(wèn)題。比如，如果執(zhí)行FLUSHALL命令意外地刷新了所有內(nèi)容后，只要 AOF 文件沒(méi)有被重寫(xiě)，刪除最新命令并重啟即可恢復(fù)之前的狀態(tài)。

綜上 ：

• Redis 保存的數(shù)據(jù)丟失一些也沒(méi)什么影響的話，可以選擇使用 RDB。

• 不建議單獨(dú)使用 AOF，因?yàn)闀r(shí)不時(shí)地創(chuàng)建一個(gè) RDB 快照可以進(jìn)行數(shù)據(jù)庫(kù)備份、更快的重啟以及解決 AOF 引擎錯(cuò)誤。

• 如果保存的數(shù)據(jù)要求安全性比較高的話，建議同時(shí)開(kāi)啟 RDB 和 AOF 持久化或者開(kāi)啟 RDB 和 AOF 混合持久化。

10.什么是內(nèi)存碎片?

你可以將內(nèi)存碎片簡(jiǎn)單地理解為那些不可用的空閑內(nèi)存。

舉個(gè)例子：操作系統(tǒng)為你分配了 32 字節(jié)的連續(xù)內(nèi)存空間，而你存儲(chǔ)數(shù)據(jù)實(shí)際只需要使用 24 字節(jié)內(nèi)存空間，那這多余出來(lái)的 8 字節(jié)內(nèi)存空間如果后續(xù)沒(méi)辦法再被分配存儲(chǔ)其他數(shù)據(jù)的話，就可以被稱(chēng)為內(nèi)存碎片。

Redis 內(nèi)存碎片雖然不會(huì)影響 Redis 性能，但是會(huì)增加內(nèi)存消耗。

為什么會(huì)有 Redis 內(nèi)存碎片?

Redis 內(nèi)存碎片產(chǎn)生比較常見(jiàn)的 2 個(gè)原因：

1、Redis 存儲(chǔ)存儲(chǔ)數(shù)據(jù)的時(shí)候向操作系統(tǒng)申請(qǐng)的內(nèi)存空間可能會(huì)大于數(shù)據(jù)實(shí)際需要的存儲(chǔ)空間。

2、頻繁修改 Redis 中的數(shù)據(jù)也會(huì)產(chǎn)生內(nèi)存碎片。

如何清理 Redis 內(nèi)存碎片？

Redis4.0-RC3 版本以后自帶了內(nèi)存整理，可以避免內(nèi)存碎片率過(guò)大的問(wèn)題。

直接通過(guò) config set 命令將 activedefrag 配置項(xiàng)設(shè)置為 yes 即可。

?config set activedefrag yes

具體什么時(shí)候清理需要通過(guò)下面兩個(gè)參數(shù)控制：

?# 內(nèi)存碎片占用空間達(dá)到 500mb 的時(shí)候開(kāi)始清理config set active-defrag-ignore-bytes 500mb# 內(nèi)存碎片率大于 1.5 的時(shí)候開(kāi)始清理config set active-defrag-threshold-lower 50

通過(guò) Redis 自動(dòng)內(nèi)存碎片清理機(jī)制可能會(huì)對(duì) Redis 的性能產(chǎn)生影響，我們可以通過(guò)下面兩個(gè)參數(shù)來(lái)減少對(duì) Redis 性能的影響：

?# 內(nèi)存碎片清理所占用 CPU 時(shí)間的比例不低于 20%config set active-defrag-cycle-min 20# 內(nèi)存碎片清理所占用 CPU 時(shí)間的比例不高于 50%config set active-defrag-cycle-max 50

另外，重啟節(jié)點(diǎn)可以做到內(nèi)存碎片重新整理。如果你采用的是高可用架構(gòu)的 Redis 集群的話，你可以將碎片率過(guò)高的主節(jié)點(diǎn)轉(zhuǎn)換為從節(jié)點(diǎn)，以便進(jìn)行安全重啟。

11.MongoDB 有什么特點(diǎn)？

• 數(shù)據(jù)記錄被存儲(chǔ)為文檔 ：MongoDB 中的記錄就是一個(gè) BSON 文檔，它是由鍵值對(duì)組成的數(shù)據(jù)結(jié)構(gòu)，類(lèi)似于 JSON 對(duì)象，是 MongoDB 中的基本數(shù)據(jù)單元。

• 模式自由 ：集合的概念類(lèi)似 MySQL 里的表，但它不需要定義任何模式，能夠用更少的數(shù)據(jù)對(duì)象表現(xiàn)復(fù)雜的領(lǐng)域模型對(duì)象。

• 支持多種查詢(xún)方式 ：MongoDB 查詢(xún) API 支持讀寫(xiě)操作 (CRUD)以及數(shù)據(jù)聚合、文本搜索和地理空間查詢(xún)。

• 支持 ACID 事務(wù) ：NoSQL 數(shù)據(jù)庫(kù)通常不支持事務(wù)，為了可擴(kuò)展和高性能進(jìn)行了權(quán)衡。不過(guò)，也有例外，MongoDB 就支持事務(wù)。與關(guān)系型數(shù)據(jù)庫(kù)一樣，MongoDB 事務(wù)同樣具有 ACID 特性。MongoDB 單文檔原生支持原子性，也具備事務(wù)的特性。MongoDB 4.0 加入了對(duì)多文檔事務(wù)的支持，但只支持復(fù)制集部署模式下的事務(wù)，也就是說(shuō)事務(wù)的作用域限制為一個(gè)副本集內(nèi)。MongoDB 4.2 引入了分布式事務(wù)，增加了對(duì)分片集群上多文檔事務(wù)的支持，并合并了對(duì)副本集上多文檔事務(wù)的現(xiàn)有支持。

• 高效的二進(jìn)制存儲(chǔ) ：存儲(chǔ)在集合中的文檔，是以鍵值對(duì)的形式存在的。鍵用于唯一標(biāo)識(shí)一個(gè)文檔，一般是 ObjectId 類(lèi)型，值是以 BSON 形式存在的。BSON = Binary JSON， 是在 JSON 基礎(chǔ)上加了一些類(lèi)型及元數(shù)據(jù)描述的格式。

• 自帶數(shù)據(jù)壓縮功能 ：存儲(chǔ)同樣的數(shù)據(jù)所需的資源更少。

• 支持 mapreduce ：通過(guò)分治的方式完成復(fù)雜的聚合任務(wù)。不過(guò)，從 MongoDB 5.0 開(kāi)始，map-reduce 已經(jīng)不被官方推薦使用了，替代方案是 聚合管道open in new window。聚合管道提供比 map-reduce 更好的性能和可用性。

• 支持多種類(lèi)型的索引 ：MongoDB 支持多種類(lèi)型的索引，包括單字段索引、復(fù)合索引、多鍵索引、哈希索引、文本索引、 地理位置索引等，每種類(lèi)型的索引有不同的使用場(chǎng)合。

• 支持 failover ：提供自動(dòng)故障恢復(fù)的功能，主節(jié)點(diǎn)發(fā)生故障時(shí)，自動(dòng)從從節(jié)點(diǎn)中選舉出一個(gè)新的主節(jié)點(diǎn)，確保集群的正常使用，這對(duì)于客戶(hù)端來(lái)說(shuō)是無(wú)感知的。

• 支持分片集群 ：MongoDB 支持集群自動(dòng)切分?jǐn)?shù)據(jù)，讓集群存儲(chǔ)更多的數(shù)據(jù)，具備更強(qiáng)的性能。在數(shù)據(jù)插入和更新時(shí)，能夠自動(dòng)路由和存儲(chǔ)。

• 支持存儲(chǔ)大文件 ：MongoDB 的單文檔存儲(chǔ)空間要求不超過(guò) 16MB。對(duì)于超過(guò) 16MB 的大文件，MongoDB 提供了 GridFS 來(lái)進(jìn)行存儲(chǔ)，通過(guò) GridFS，可以將大型數(shù)據(jù)進(jìn)行分塊處理，然后將這些切分后的小文檔保存在數(shù)據(jù)庫(kù)中

12.MongoDB 適合什么應(yīng)用場(chǎng)景？

MongoDB 的優(yōu)勢(shì)在于其數(shù)據(jù)模型和存儲(chǔ)引擎的靈活性、架構(gòu)的可擴(kuò)展性以及對(duì)強(qiáng)大的索引支持。

選用 MongoDB 應(yīng)該充分考慮 MongoDB 的優(yōu)勢(shì)，結(jié)合實(shí)際項(xiàng)目的需求來(lái)決定：

• 隨著項(xiàng)目的發(fā)展，使用類(lèi) JSON 格式（BSON）保存數(shù)據(jù)是否滿足項(xiàng)目需求？MongoDB 中的記錄就是一個(gè) BSON 文檔，它是由鍵值對(duì)組成的數(shù)據(jù)結(jié)構(gòu)，類(lèi)似于 JSON 對(duì)象，是 MongoDB 中的基本數(shù)據(jù)單元。

• 是否需要大數(shù)據(jù)量的存儲(chǔ)？是否需要快速水平擴(kuò)展？MongoDB 支持分片集群，可以很方便地添加更多的節(jié)點(diǎn)（實(shí)例），讓集群存儲(chǔ)更多的數(shù)據(jù)，具備更強(qiáng)的性能。

• 是否需要更多類(lèi)型索引來(lái)滿足更多應(yīng)用場(chǎng)景？MongoDB 支持多種類(lèi)型的索引，包括單字段索引、復(fù)合索引、多鍵索引、哈希索引、文本索引、 地理位置索引等，每種類(lèi)型的索引有不同的使用場(chǎng)合。

13. MongoDB 支持哪些存儲(chǔ)引擎？

與 MySQL 一樣，MongoDB 采用的也是 插件式的存儲(chǔ)引擎架構(gòu) ，支持不同類(lèi)型的存儲(chǔ)引擎，不同的存儲(chǔ)引擎解決不同場(chǎng)景的問(wèn)題。在創(chuàng)建數(shù)據(jù)庫(kù)或集合時(shí)，可以指定存儲(chǔ)引擎。

插件式的存儲(chǔ)引擎架構(gòu)可以實(shí)現(xiàn) Server 層和存儲(chǔ)引擎層的解耦，可以支持多種存儲(chǔ)引擎，如MySQL既可以支持B-Tree結(jié)構(gòu)的InnoDB存儲(chǔ)引擎，還可以支持LSM結(jié)構(gòu)的RocksDB存儲(chǔ)引擎。

現(xiàn)在主要有下面這兩種存儲(chǔ)引擎：

• WiredTiger 存儲(chǔ)引擎 ：自 MongoDB 3.2 以后，默認(rèn)的存儲(chǔ)引擎為 WiredTiger 存儲(chǔ)引擎open in new window 。非常適合大多數(shù)工作負(fù)載，建議用于新部署。WiredTiger 提供文檔級(jí)并發(fā)模型、檢查點(diǎn)和數(shù)據(jù)壓縮（后文會(huì)介紹到）等功能。

• In-Memory 存儲(chǔ)引擎 ：In-Memory 存儲(chǔ)引擎open in new window在 MongoDB Enterprise 中可用。它不是將文檔存儲(chǔ)在磁盤(pán)上，而是將它們保留在內(nèi)存中以獲得更可預(yù)測(cè)的數(shù)據(jù)延遲。