「十項全能」的 ChatGPT ，用起來感受如何？

之前，作為 ChatGPT Plus 用戶，如果你集齊下面這五個模式，就會成為別人羨慕的對象。

但現在，人們更加期盼的，是下面這個提示的出現：

這個提示，意味著你的 GPT-4 已經不再是「一專」（只能使用某一模式），而是「多能」（根據需要自動調用不同模式的功能）。

例如你可以讓 ChatGPT 看到一幅圖（原本的基礎模式），然后讓它自動理解總結圖片的內容，并且要求它繪制出類似的圖片（原本的 DALLE）模式。當然，你還可以讓它自動編程（原本的 Data 模式）或者訪問網絡（原本的 Browse with Bing 或者插件模式）。

這樣一來，用戶的想象力就可以變成特別有趣有用的實踐過程。例如王佩老師，就讓 ChatGPT 繪制簡筆畫。他對繪制結果很滿意。

見賢思齊，于是我又把自己的微信頭像傳上去了。要求 ChatGPT (GPT-4 All Tools）：

畫成皮克斯風格

于是，我獲得了這樣的圖像：

呃，除了人物不像我，以及背景多了一只狐貍，我沒有啥可抱怨的……

同時生成的，還有另外一幅作品。咱們也放大看看。

可這…… 也太不像我了啊。于是，我提出了這樣的要求：

畫成皮克斯風格，注意人物一定要像。

這次 GPT-4 全模式 (All Tools) 的繪圖結果是這樣的：

這個…… 你要非得說像我，我無話可說。

我查看了對應的提示詞：

Photo of a man , wearing a light blue polo shirt and a . He is Asian, with short black hair, smiling warmly with a of covered with green and reddish trees under a cloudy sky. The image should be into a Pixar-style , the and of the person, but with the and typical of Pixar .

對應的翻譯為：

一張快樂男子在戶外的照片，他穿著淺藍色的 Polo 衫，背著背包。他是亞洲人，有短黑發，背景是山脈，山上覆蓋著綠色和紅色的樹木，天空多云。他的笑容溫暖。這張圖片應該被轉化為皮克斯風格的動畫，保持人物的相似性和表情，但具有皮克斯動畫典型的迷人和異想天開的特點。

我旋即明白了，圖片畫得不像我，就是 ChatGPT 識圖后總結提示詞的原因。這里只描述為「亞洲人」、「快樂男子」和「短黑發」，至于臉型、五官之類的，絲毫沒有涉及，那當然沒有辦法「完美復刻」了。

我在視頻中提到了這個問題。有觀眾提示我說可能是在上傳人像的時候，ChatGPT自動做了面部模糊化處理以保護人物肖像權，我覺得非常有道理。回頭我準備找個卡通頭像上傳上去試試看。

看完了這個有趣的例子，咱們該講講嚴肅的事兒了 —— 如何利用 GPT-4 全模式 (All Tools) 幫助你更好地學習和工作？

學習

咱們先從一個最常見的場景開始 —— 上課的時候，看到課件里面的英文不會，該怎么辦？

這時候，你可以拍張照或者截屏，讓 GPT-4 全模式 (All Tools) 幫助你來翻譯。上面這張幻燈截圖，它的翻譯如下：

描述了使用大語言模型（LLM）時的提示（）能做什么。圖片中提到，如果給一個剛剛畢業的大學生一些指導，他們是否能夠完成任務。為了更加清晰明了，假設情況如下：

沒有互聯網或其他資源的訪問權限

對你的公司 / 業務沒有特定的培訓

沒有完成先前任務的記憶

每次都會得到一個不同的新畢業的大學生

圖片旨在探討在沒有額外資源和指導的情況下，一個新畢業的大學生是否能夠根據給定的指導完成任務。

你可能對此不屑一顧 —— 這簡單的翻譯功能，我手機上的 XX 應用，早就有了。

沒錯，但是 ChatGPT 可不僅僅會翻譯哦。你看到一頁幻燈，如果對其中內容有不清楚的地方，可以立即呼喚你的這個「私人助教」來幫忙總結和解答。例如下面這頁幻燈，是吳恩達老師在新課程 AI for 中對「監督學習」應用的總結。

我截圖發給 GPT-4 全模式 (All Tools) ，要求用中文總結圖中內容。

這是 GPT-4 的回答：

這張圖片是 Andrew Ng 在講解監督學習的應用。圖片中列出了不同的輸入、輸出和相應的應用場景。例如，輸入可以是電子郵件，輸出是判斷這封郵件是否為垃圾郵件，應用場景是垃圾郵件過濾。其他的應用還包括在線廣告、自動駕駛車輛的其他車輛位置識別、醫療診斷、視覺檢測、語音識別和餐廳評論的情感分析等。每個應用都涵蓋了將輸入數據（如圖像、廣告和用戶信息、音頻記錄等）轉換為有意義輸出（如診斷、缺陷檢測、文本轉錄等）的過程。

你看，ChatGPT 打通各個模式之后，拿來當助教非常合適，講解耐心不厭其煩。更妙的是，你不僅可以讓它識別幻燈幫你講解，還能要求它立即給你寫出對應例子的程序代碼來。

編程

例如我剛剛聽完 GPT-4 全模式 (All Tools) 的總結，依然對監督學習沒有形象的概念。于是我下面的提示語為：

就找上面的一個例子，給我寫一段監督學習的 Python 代碼

ChatGPT 就立即開始干活兒了。

在你看到代碼之后，是不是對監督學習的模型訓練流程概念理解更加清晰了呢？有了這種快速支援，相信你學東西會更加扎實，疑問也能更及時得到解決。

況且你不要忘了，GPT-4 全模式 (All Tools) 還包含了 Data 模式，也就是可以把程序直接作用在數據集上面，幫助你實驗，甚至解決實際的問題。下面我們就來看看如何用 ChatGPT 來「看到」實際的數據，并且進行分析。

數據分析

我這里舉的例子，也來自于吳恩達老師的新課。他提到了很有意思的問題 ——LLM 對結構化數據處理不好。

我覺得這個觀察很有意思，但是將信將疑，于是立即就把數據截取出來嘗試。我問 ChatGPT ：

這個表格里面有對應的面積和價格，那么 900 sqft 的房子，對應的價格是多少？請一步步思考，并且詳細說明你的解題過程

下面是 ChatGPT 的回答：

你看，要公式有公式，要代碼有代碼。數據齊全，分析清晰。只可惜，這個線性插值計算方法并不完美，因為利用數據太少了。為了幫助 ChatGPT 改進結果，咱們還可以這樣來追問：

好，但是你能否充分利用上全部數據來建模并且測算呢？

ChatGPT 旋即給了答案。

如果你希望了解 ChatGPT 如何計算，還可以點開被折疊的工作區，查看對應代碼。

你看，原先表格中的所有數據，確實都被使用了進來。但是，這個計算的結果是否正確？希望你能夠檢驗一下，然后在留言區給出自己的判定答案。

論文閱讀

下面這個功能，更是很多小伙伴期待已久的 —— 你可以直接把 PDF 格式的文檔扔給 ChatGPT 了。GPT-4 全模式 (All Tools) 可以自動識別其中的內容，并且進行分析和回答你提出的問題。

例如，我從 下載了 MemGPT 論文的全文。

然后，我把它扔給 GPT-4 全模式 (All Tools) ，提出的要求為：

給我介紹一下這篇文章的亮點

這是 ChatGPT （速度很快）讀過文章后，給出的結果。

我們讓 ChatGPT 簡單翻譯一下前面幾段：

論文《MemGPT: 朝著作為操作系統的 LLMs》介紹了一種旨在克服當前大型語言模型（LLMs）的有限上下文窗口限制的新系統。以下是其亮點的詳細說明：

1.虛擬上下文管理：作者引入了一種技術，通過借鑒傳統操作系統中的分層存儲系統，擴展了LLMs的可用上下文范圍，超越了標準固定長度上下文窗口的限制。這種技術被稱為虛擬上下文管理，通過在快速和慢速存儲層之間的數據移動，實現了更大內存的幻象。

2.MemGPT系統：基于這種技術，派生出了MemGPT系統，它利用分層存儲結構和中斷來管理LLM、存儲器和用戶之間的數據流和控制。該系統可以在任務進行過程中調整上下文，更有效地利用有限的上下文。

3.在文檔分析和對話代理方面的性能：論文展示了MemGPT在文檔分析和多會話聊天領域的增強性能。它能夠分析大量文檔并保持長期交互，超越了LLM的上下文窗口限制。

很好，這至少證明 ChatGPT 看懂了 PDF 論文全文內容。你也可以就文本內容提出問題，讓它來回答。不過類似的內容，我在講 Chatdoc 的時候都演示過了。這回咱們要充分利用它的全模式功能，搞點兒新花樣。

我要求：

把上述內容，用圖展示出來，要求讓一個中學生能夠看懂

于是 ChatGPT 這樣繪制：

我們放大一下第一張圖。

這張圖非常有趣。它知道論文主角是一個機器大腦，要解決的問題是記憶體的限制。圖中主體設計成一種類似操作系統的架構，上面是個戴學士帽的機器人。聯接的小圖都是與上下文、記憶體、檢索能力相關，還提到了「快速」等特性。另外還有很多相關的文字作為講解介紹。

當然了，這個圖的毛病，也是顯而易見的。例如說里面出現了很多奇怪的單詞，都像是半文盲寫的 —— 有很多拼寫錯誤。不過你不用擔心，這只是個開始。你要相信 LLM 的演進速度。

繪圖做完了，咱們嘗試一下表格數據的讀取。這里我選擇了 Table 2 的內容作為樣例。

我要求 ChatGPT 來總結其內容，并且進行可視化：

這里咱們看看其操作過程的細節。

首先， ChatGPT 確實在上傳的 PDF 里面，找到了表格 2 對應的位置和內容。

然后，ChatGPT 進行了編程計算，最終給出了下圖的結果。

初看這張圖，你可能會很不以為然。沒錯，這張圖確實畫錯了。F1, 和 Recall 如果真的這么慘不忍睹，也就沒有匯報的必要了。但是，這錯誤也是有原因的。

原始論文中，對 （準確率）和其他三個指標，表現形式就不一樣 —— 前者是百分數，后者是小數。目前 ChatGPT 對于同一表格不同列數據這種轉換，還沒有做到靈活自如，因此才會出這樣的紕漏。

但是你看到，不論是模型類型、圖例說明和對應數據，ChatGPT 在讀取表格的時候，確實已經盡可能做到了一一對應。因此，只要你在后續對話中稍加提示，繪圖效果就會大不一樣。

所以，現在的 GPT-4 全模式 (All Tools) 確實是可以「看到」圖和表，這對于我們來說，意義很大 —— 論文中出現的數據，你至少可以更為靈活自如地進行二次分析與驗證了。

小結

本文我為你介紹了自己使用 GPT-4 全模式 (All Tools) 來輔助工作和學習的一些心得體會。總體來說，ChatGPT 全模式打通之后，可以更方便調用各種「藝能」。它可以幫助你更快速理解消化新信息、按照你的個性化要求給出樣例，根據上下文做出總結問答，并且幫你進行自動數據分析。希望這些功用的分享，可以幫助你更高效地完成任務，獲得新知。

祝（更強悍的）AI 工具使用愉快！

點贊 +「在看」，轉發給你身邊有需要的朋友。收不到推送？那是因為你只訂閱，卻沒有加星標。

歡迎訂閱我的小報童付費專欄，每季度更新不少于10篇文章。訂閱一整年價格優惠。

如果有問題咨詢，或者希望加入社群和熱愛鉆研的小伙伴們一起討論，訂閱知識星球吧。不僅包括小報童的推送內容，還可以自由發帖與提問。之前已經積累下的帖子和問答，就有數百篇。足夠你好好翻一陣子。知識星球支持72小時內無條件退款，所以你可以放心嘗試。

若文中部分鏈接可能無法正常顯示與跳轉，可能是因為微信公眾平臺的外鏈限制。如需訪問，請點擊文末「閱讀原文」鏈接，查看鏈接齊備的版本。

Redis中一個你絕對沒用過，但是特別好用性能炸裂的數據結構，分享！

你沒看錯，在刪除一個 key 時，如果姿勢不對，也有可能影響到 Redis 性能。

刪除一個 key，我們通常使用的是 DEL 命令，回想一下，你覺得 DEL 的時間復雜度是多少？

O(1) ？其實不一定。

當你刪除的是一個 String 類型 key 時，時間復雜度確實是 O(1)。

但當你要刪除的 key 是 List/Hash/Set/ZSet 類型，它的復雜度其實為 O(N)，N 代表元素個數。

也就是說，刪除一個 key，其元素數量越多，執行 DEL 也就越慢！

原因在于，刪除大量元素時，需要依次回收每個元素的內存，元素越多，花費的時間也就越久！

而且，這個過程默認是在主線程中執行的，這勢必會阻塞主線程，產生性能問題。

那刪除這種元素比較多的 key，如何處理呢？

我給你的建議是，分批刪除：

沒想到吧？一個小小的刪除操作，稍微不小心，也有可能引發性能問題，你在操作時需要格外注意。

6) 批量命令代替單個命令

當你需要一次性操作多個 key 時，你應該使用批量命令來處理。

批量操作相比于多次單個操作的優勢在于，可以顯著減少客戶端、服務端的來回網絡 IO 次數。

所以我給你的建議是：

7) 避免集中過期 key

Redis 清理過期 key 是采用定時 + 懶惰的方式來做的，而且這個過程都是在主線程中執行。

如果你的業務存在大量 key 集中過期的情況，那么 Redis 在清理過期 key 時，也會有阻塞主線程的風險。

想要避免這種情況發生，你可以在設置過期時間時，增加一個隨機時間，把這些 key 的過期時間打散，從而降低集中過期對主線程的影響。

8) 使用長連接操作 Redis，合理配置連接池

你的業務應該使用長連接操作 Redis，避免短連接。

當使用短連接操作 Redis 時，每次都需要經過 TCP 三次握手、四次揮手，這個過程也會增加操作耗時。

同時，你的客戶端應該使用連接池的方式訪問 Redis，并設置合理的參數，長時間不操作 Redis 時，需及時釋放連接資源。

9) 只使用 db0

盡管 Redis 提供了 16 個 db，但我只建議你使用 db0。

為什么呢？我總結了以下 3 點原因：

在一個連接上操作多個 db 數據時，每次都需要先執行 SELECT，這會給 Redis 帶來額外的壓力

使用多個 db 的目的是，按不同業務線存儲數據，那為何不拆分多個實例存儲呢？拆分多個實例部署，多個業務線不會互相影響，還能提高 Redis 的訪問性能

Redis Cluster 只支持 db0，如果后期你想要遷移到 Redis Cluster，遷移成本高

10) 使用讀寫分離 + 分片集群

如果你的業務讀請求量很大，那么可以采用部署多個從庫的方式，實現讀寫分離，讓 Redis 的從庫分擔讀壓力，進而提升性能。

如果你的業務寫請求量很大，單個 Redis 實例已無法支撐這么大的寫流量，那么此時你需要使用分片集群，分擔寫壓力。

11) 不開啟 AOF 或 AOF 配置為每秒刷盤

如果對于丟失數據不敏感的業務，我建議你不開啟 AOF，避免 AOF 寫磁盤拖慢 Redis 的性能。

如果確實需要開啟 AOF，那么我建議你配置為 ，把數據持久化的刷盤操作，放到后臺線程中去執行，盡量降低 Redis 寫磁盤對性能的影響。

12) 使用物理機部署 Redis

Redis 在做數據持久化時，采用創建子進程的方式進行。

而創建子進程會調用操作系統的 fork 系統調用，這個系統調用的執行耗時，與系統環境有關。

虛擬機環境執行 fork 的耗時，要比物理機慢得多，所以你的 Redis 應該盡可能部署在物理機上。

13) 關閉操作系統內存大頁機制

Linux 操作系統提供了內存大頁機制，其特點在于，每次應用程序向操作系統申請內存時，申請單位由之前的 4KB 變為了 2MB。

這會導致什么問題呢？

當 Redis 在做數據持久化時，會先 fork 一個子進程，此時主進程和子進程共享相同的內存地址空間。

當主進程需要修改現有數據時，會采用寫時復制（Copy On Write）的方式進行操作，在這個過程中，需要重新申請內存。

如果申請內存單位變為了 2MB，那么勢必會增加內存申請的耗時，如果此時主進程有大量寫操作，需要修改原有的數據，那么在此期間，操作延遲就會變大。

所以，為了避免出現這種問題，你需要在操作系統上關閉內存大頁機制。

好了，以上這些就是 Redis 「高性能」方面的實踐優化。如果你非常關心 Redis 的性能問題，可以結合這些方面針對性優化。

我們再來看 Redis 「可靠性」如何保證。

如何保證 Redis 的可靠性？

這里我想提醒你的是，保證 Redis 可靠性其實并不難，但難的是如何做到「持續穩定」。

下面我會從「資源隔離」、「多副本」、「故障恢復」這三大維度，帶你分析保障 Redis 可靠性的最佳實踐。

1) 按業務線部署實例

提升可靠性的第一步，就是「資源隔離」。

你最好按不同的業務線來部署 Redis 實例，這樣當其中一個實例發生故障時，不會影響到其它業務。

這種資源隔離的方案，實施成本是最低的，但成效卻是非常大的。

2) 部署主從集群

如果你只使用單機版 Redis，那么就會存在機器宕機服務不可用的風險。

所以，你需要部署「多副本」實例，即主從集群，這樣當主庫宕機后，依舊有從庫可以使用，避免了數據丟失的風險，也降低了服務不可用的時間。

在部署主從集群時，你還需要注意，主從庫需要分布在不同機器上，避免交叉部署。

這么做的原因在于，通常情況下，Redis 的主庫會承擔所有的讀寫流量，所以我們一定要優先保證主庫的穩定性，即使從庫機器異常，也不要對主庫造成影響。

而且，有時我們需要對 Redis 做日常維護，例如數據定時備份等操作，這時你就可以只在從庫上進行，這只會消耗從庫機器的資源，也避免了對主庫的影響。

3) 合理配置主從復制參數

在部署主從集群時，如果參數配置不合理，也有可能導致主從復制發生問題：

在這方面我給你的建議有以下 2 點：

設置合理的 repl-backlog 參數：過小的 repl-backlog 在寫流量比較大的場景下，主從復制中斷會引發全量復制數據的風險

設置合理的 slave client-output-buffer-limit：當從庫復制發生問題時，過小的 buffer 會導致從庫緩沖區溢出，從而導致復制中斷

4) 部署哨兵集群，實現故障自動切換

只部署了主從節點，但故障發生時是無法自動切換的，所以，你還需要部署哨兵集群，實現故障的「自動切換」。

而且，多個哨兵節點需要分布在不同機器上，實例為奇數個，防止哨兵選舉失敗，影響切換時間。

以上這些就是保障 Redis「高可靠」實踐優化，你應該也發現了，這些都是部署和運維層的優化。

除此之外，你可能還會對 Redis 做一些「日常運維」工作，這時你要注意哪些問題呢？

日常運維 Redis 需要注意什么？

如果你是 DBA 運維人員，在平時運維 Redis 時，也需要注意以下 6 個方面。

1) 禁止使用 KEYS//FLUSHDB 命令

執行這些命令，會長時間阻塞 Redis 主線程，危害極大，所以你必須禁止使用它。

如果確實想使用這些命令，我給你的建議是：

2) 掃描線上實例時，設置休眠時間

不管你是使用 SCAN 掃描線上實例，還是對實例做 bigkey 統計分析，我建議你在掃描時一定記得設置休眠時間。

防止在掃描過程中，實例 OPS 過高對 Redis 產生性能抖動。

3) 慎用 MONITOR 命令

有時在排查 Redis 問題時，你會使用 MONITOR 查看 Redis 正在執行的命令。

但如果你的 Redis OPS 比較高，那么在執行 MONITOR 會導致 Redis 輸出緩沖區的內存持續增長，這會嚴重消耗 Redis 的內存資源，甚至會導致實例內存超過 ，引發數據淘汰，這種情況你需要格外注意。

所以你在執行 MONITOR 命令時，一定要謹慎，盡量少用。

4) 從庫必須設置為 slave-read-only

你的從庫必須設置為 slave-read-only 狀態，避免從庫寫入數據，導致主從數據不一致。

除此之外，從庫如果是非 read-only 狀態，如果你使用的是 4.0 以下的 Redis，它存在這樣的 Bug：

從庫寫入了有過期時間的數據，不會做定時清理和釋放內存。

這會造成從庫的內存泄露！這個問題直到 4.0 版本才修復，你在配置從庫時需要格外注意。

5) 合理配置 timeout 和 tcp- 參數

如果因為網絡原因，導致你的大量客戶端連接與 Redis 意外中斷，恰好你的 Redis 配置的 參數比較小，此時有可能導致客戶端無法與服務端建立新的連接（服務端認為超過了 ）。

造成這個問題原因在于，客戶端與服務端每建立一個連接，Redis 都會給這個客戶端分配了一個 client fd。

當客戶端與服務端網絡發生問題時，服務端并不會立即釋放這個 client fd。

什么時候釋放呢？

Redis 內部有一個定時任務，會定時檢測所有 client 的空閑時間是否超過配置的 timeout 值。

如果 Redis 沒有開啟 tcp- 的話，服務端直到配置的 timeout 時間后，才會清理釋放這個 client fd。

在沒有清理之前，如果還有大量新連接進來，就有可能導致 Redis 服務端內部持有的 client fd 超過了 ，這時新連接就會被拒絕。

針對這種情況，我給你的優化建議是：

不要配置過高的 timeout：讓服務端盡快把無效的 client fd 清理掉

Redis 開啟 tcp-：這樣服務端會定時給客戶端發送 TCP 心跳包，檢測連接連通性，當網絡異常時，可以盡快清理僵尸 client fd

6) 調整 時，注意主從庫的調整順序

Redis 5.0 以下版本存在這樣一個問題：從庫內存如果超過了 ，也會觸發數據淘汰。

在某些場景下，從庫是可能優先主庫達到 的（例如在從庫執行 MONITOR 命令，輸出緩沖區占用大量內存），那么此時從庫開始淘汰數據，主從庫就會產生不一致。

要想避免此問題，在調整 時，一定要注意主從庫的修改順序：

直到 Redis 5.0，Redis 才增加了一個配置 replica-ignore-，默認從庫超過 不會淘汰數據，才解決了此問題。

好了，以上這些就是「日常運維」Redis 需要注意的，你可以對各個配置項查漏補缺，看有哪些是需要優化的。

接下來，我們來看一下，保障 Redis「安全」都需要注意哪些問題。

Redis 安全如何保證？

無論如何，在互聯網時代，安全問題一定是我們需要隨時警戒的。

你可能聽說過 Redis 被注入可執行腳本，然后拿到機器 root 權限的安全問題，都是因為在部署 Redis 時，沒有把安全風險注意起來。

針對這方面，我給你的建議是：

不要把 Redis 部署在公網可訪問的服務器上

部署時不使用默認端口 6379

以普通用戶啟動 Redis 進程，禁止 root 用戶啟動

限制 Redis 配置文件的目錄訪問權限

推薦開啟密碼認證

禁用/重命名危險命令（KEYS//FLUSHDB/CONFIG/EVAL）

只要你把這些做到位，基本上就可以保證 Redis 的安全風險在可控范圍內。

至此，我們分析了 Redis 在內存、性能、可靠性、日常運維方面的最佳實踐優化。

除了以上這些，你還需要做到提前「預防」。

如何預防 Redis 問題？

要想提前預防 Redis 問題，你需要做好以下兩個方面：

合理的資源規劃

完善的監控預警

先來說資源規劃。

在部署 Redis 時，如果你可以提前做好資源規劃，可以避免很多因為資源不足產生的問題。這方面我給你的建議有以下 3 點：

保證機器有足夠的 CPU、內存、帶寬、磁盤資源

提前做好容量規劃，主庫機器預留一半內存資源，防止主從機器網絡故障，引發大面積全量同步，導致主庫機器內存不足的問題

單個實例內存建議控制在 10G 以下，大實例在主從全量同步、RDB 備份時有阻塞風險

再來看監控如何做。

監控預警是提高穩定性的重要環節，完善的監控預警，可以把問題提前暴露出來，這樣我們才可以快速反應，把問題最小化。

這方面我給你的建議是：

做好機器 CPU、內存、帶寬、磁盤監控，資源不足時及時報警，任意資源不足都會影響 Redis 性能

設置合理的 slowlog 閾值，并對其進行監控，slowlog 過多及時報警

監控組件采集 Redis INFO 信息時，采用長連接，避免頻繁的短連接

做好實例運行時監控，重點關注 、、 指標，這些指標短時突增可能會有阻塞風險

總結

好了，總結一下，這篇文章我帶你全面分析了 Redis 最佳實踐的優化路徑，其中包括內存資源、高性能、高可靠、日常運維、資源規劃、監控、安全 7 個維度。

這里我畫成了思維導圖，方便你在實踐時做參考。

我還把這些實踐優化，按照「業務開發」和「運維」兩個維度，進一步做了劃分。

并且以「強制」、「推薦」、「參考」3 個級別做了標注，這樣你在實踐優化時，就會更明確哪些該做，哪些需要結合實際的業務場景進一步分析。

這些級別的實施規則如下：

如果你是業務開發人員，你需要了解 Redis 的運行機制，例如各個命令的執行時間復雜度、數據過期策略、數據淘汰策略等，使用合理的命令，并結合業務場景進行優化。

如果你是 DBA 運維人員，你需要在資源規劃、運維、監控、安全層面做到位，做到未雨綢繆。

歡迎掃碼加入儒猿技術交流群，每天晚上20:00都有Java面試、Redis、MySQL、、、Java架構等技術答疑分享，更能跟小伙伴們一起交流技術

另外推薦儒猿課堂的1元系列課程給您，歡迎加入一起學習~

互聯網Java工程師面試突擊課

（1元專享）

零基礎入門到項目實戰

（1元專享）

億級流量下的電商詳情頁系統實戰項目

（1元專享）

Kafka消息中間件內核源碼精講

（1元專享）

12個實戰案例帶你玩轉Java并發編程

（1元專享）

零基礎入門到精通

（1元專享）

基于Java手寫分布式中間件系統實戰

（1元專享）

基于的分庫分表實戰課

（1元專享）