簡介：以上文章講述的是【數(shù)據(jù)庫性能調(diào)優(yōu)知識與面試知識（詳解四服務(wù)器性能剖析）】接下來我總結(jié)一下【Redis入門知識點】。覺得我還可以的可以加群一起督促學習探討技術(shù)。QQ群：1076570504 個人學習資料庫http://www.aolanghs.com/ 微信公眾號搜索【歡少的成長之路】

• Redis是什么？為什么選擇Redis？
• 與Redis類似的系統(tǒng)有哪些？挑選一個你比較熟悉的簡單講解一下？
• Redis的五大數(shù)據(jù)類型應(yīng)用場景都是什么？
• 以上講述了五大類型，Java里完全也可以實現(xiàn)，為什么非要用Redis來替代呢？
• 一直往Redis里加數(shù)據(jù)，不會溢出嗎？它又是怎么刪除的呢？
• Redis與數(shù)據(jù)庫作交互，例如MySQL，它有事務(wù)，Redis有事務(wù)嗎？跟MySQL事務(wù)有什么區(qū)別？
• 提到Redis很多文章會提壓縮表與跳躍表，這兩個又是什么東東？
• 講述一下Redis的內(nèi)存淘汰機制？
• 內(nèi)存打滿或者電腦癱瘓如何保證數(shù)據(jù)的有效性？
• 應(yīng)用場景中你遇到過哪些問題呢？ 這些你又是怎么解決的？
• Redis集群有哪幾種模式？可以簡單介紹一下嗎？
• Redis如何解決并發(fā)的？
• Redis用在分布式的話又會遇到哪些問題呢？

TIP： 通過這篇文章你能學習到這些知識！想了解的繼續(xù)深入，不想了解的趕緊離開，我不想浪費你們的學習時間。找準自己的定位與目標，堅持下去，并且一定要高效。我跟你們一樣非常抵制垃圾文章，雷同文章，胡說八道的文章。

很多人會問，學底層多浪費時間，搞好實現(xiàn)功能不就好了嗎？

可以這樣想一下到了一定的工作年限技術(shù)的廣度深度都有一定的造詣了，你寫代碼就這樣了沒辦法優(yōu)化了，機器配置也是最好的了，那還能優(yōu)化啥？? 底層，我們都知道所有語言到最后要運行都是變成機器語言的，最后歸根究底都是要去跟機器交互的，那計算機的底層是不是最后還是要關(guān)注的東西了！

Redis

Redis是什么？

Redis相當于是一個內(nèi)存數(shù)據(jù)庫，說到數(shù)據(jù)庫，傳統(tǒng)的數(shù)據(jù)庫都是存在硬盤中，redis的特點是存在內(nèi)存中，所以讀寫速度非常的快，因此redis主要用于緩存業(yè)務(wù)。redis支持事務(wù)，持久化以及多種集群方案。

Tip：redis不負責編碼工作，put進行什么類型的值，get出去的時候也就是什么類型的值。之間是有一個二進制安全的

為什么選擇Redis？

我們要根據(jù)它的特點來論述。高并發(fā)，高性能！

我們先從高性能簡單介紹一下，因為是在內(nèi)存中操作所以它的讀寫能力非常的快，它可以比其他在磁盤上操作數(shù)據(jù)庫有更高的速度與性能。

高并發(fā)主要體現(xiàn)在直接操作內(nèi)存比操作數(shù)據(jù)庫的磁盤有著更高的效率與性能，所以它在接受請求的時候往往可以承受更高的并發(fā)量。從磁盤讀寫數(shù)據(jù)都是有磁盤IO的，而內(nèi)存的話就不需要這一點！

Memcached是什么？區(qū)別在哪？

memcached是一套分布式的快取系統(tǒng)，跟redis類似，和redis的區(qū)別如下。這里不過多介紹了，今天的主題是redis。

區(qū)別

redis支持五大數(shù)據(jù)類型，Memcached支持的數(shù)據(jù)類型極少一定程度上根本完成不了業(yè)務(wù)需求

redis支持事務(wù)

memcached沒有原生的集群模式，需要用戶單獨編寫。redis是支持原生cluster模式。

Memcached是多線程，非阻塞IO復用的網(wǎng)絡(luò)模型；Redis使用單線程的多路 IO 復用模型。

應(yīng)用場景

Redis的五大數(shù)據(jù)類型應(yīng)用場景都是什么？

hash：因為它的映射關(guān)系的特性，特別適合存一些存儲對象。比如用戶詳情，商品詳情，訂單詳情等。

string：是簡單的key-value結(jié)構(gòu)，value不僅可以是string類型也可以是數(shù)字，比如生活中常見的關(guān)注數(shù)，粉絲數(shù)等等。

list：是一個鏈表，有序的可重復存儲。它的應(yīng)用場景非常的多，比如關(guān)注列表，分析列表，消息列表，高性能分頁（下拉數(shù)據(jù)一直不斷刷新的那種）等。這里需要著重強調(diào)一下list有單鏈表以及雙鏈表。這里的redis list實現(xiàn)的是雙向鏈表，所以可以支持反向查詢和遍歷。

set：無序的，不支持重復存儲。主要通過交并差集操作實現(xiàn)一些類似于微博的共同好友，共同粉絲，隨機事件，抽獎，選名等功能。

sorted set：比set增加了一個權(quán)重閾值。也就是參照的意思，第一新增了score分值，rank排名。主要用于一些直播系統(tǒng)中的實時排名信息。包括在線用戶列表，禮物排行列表，彈幕消息列表等功能。

Java里完全也可以實現(xiàn)，為什么非要用Redis來替代呢？

輕量級！

數(shù)據(jù)放入的是Redis不在本地CPU，所以不會影響當前的程序。如果放在本地數(shù)據(jù)量到了一定級別的時候有可能數(shù)據(jù)量已經(jīng)消耗完了CPU的內(nèi)存，會超過本地CPU溢出，所以分離了占用的位置。

過期策略

Redis過期是什么

redis可以自己手動設(shè)置一些值的過期時間，在我們set一個值的時候都可以規(guī)定這個值什么時候過期，這點的好處是極大的提高了數(shù)據(jù)的可用性。比如我們的短信驗證碼，token登錄信息等功能

Redis的數(shù)據(jù)是按照什么刪除的？

redis數(shù)據(jù)的刪除主要分兩種。第一種是定期刪除，第二種是惰性刪除。

顧名思義。

定期刪除就是每隔一段時間定期遍歷數(shù)據(jù)采用隨機刪除的思想（如果不采用隨機刪除的話那么大的數(shù)據(jù)量是非常影響性能的）。這樣的話極大的影響了CPU的性能。

惰性刪除是指在定期刪除的基礎(chǔ)上因為采用隨機刪除的關(guān)系所以會導致一部分數(shù)據(jù)經(jīng)過定期刪除后依然沒有被刪除，所以就有了惰性刪除。假如你的過期key通過定期刪除沒有被刪除，那么惰性刪除要做的就是，客戶端如果再一次訪問這個過期的key，或者系統(tǒng)去查一下這個key才會被redis刪除。這就是所謂的惰性刪除。

如果定期刪除漏掉了很多過期 key，然后你也沒及時去查， 也就沒走惰性刪除，此時會怎么樣？如果大量過期key堆積在內(nèi)存里，導致redis內(nèi)存塊耗盡了。怎么解決這個問題 呢？redis 內(nèi)存淘汰機制展開了。

內(nèi)存淘汰機制

Redis的數(shù)據(jù)淘汰策略（暫時簡單介紹吧后續(xù)會出一份Redis底層實現(xiàn)的文章）

volatile-lru：從已設(shè)置過期時間的數(shù)據(jù)集中挑選最近最少使用的數(shù)據(jù)淘汰

volatile-ttl：從已設(shè)置過期時間的數(shù)據(jù)集中挑選將要過期的數(shù)據(jù)淘汰

volatile-random：從已設(shè)置過期時間的數(shù)據(jù)集中任意選擇數(shù)據(jù)淘汰

allkeys-lru：當內(nèi)存不足以容納新寫入數(shù)據(jù)時，在鍵空間中，移除最近最少使用的key（這個是最常用的）.

allkeys-random：從數(shù)據(jù)集中任意選擇數(shù)據(jù)淘汰

no-eviction：禁止驅(qū)逐數(shù)據(jù)，也就是說當內(nèi)存不足以容納新寫入數(shù)據(jù)時，新寫入操作會報錯。（這個應(yīng)該沒人使用吧！）

事務(wù)

概念

Redis 事務(wù)的本質(zhì)是一組命令的集合。事務(wù)支持一次執(zhí)行多個命令，一個事務(wù)中所有命令都會被序列化。在事務(wù)執(zhí)行過程，會按照順序串行化執(zhí)行隊列中的命令，其他客戶端提交的命令請求不會插入到事務(wù)執(zhí)行命令序列中。

總結(jié)說：redis事務(wù)就是一次性、順序性、排他性的執(zhí)行一個隊列中的一系列命令

Redis事務(wù)沒有隔離級別的概念

批量操作在發(fā)送 EXEC 命令前被放入隊列緩存，并不會被實際執(zhí)行，也就不存在事務(wù)內(nèi)的查詢要看到事務(wù)里的更新，事務(wù)外查詢不能看到

Redis不保證原子性

Redis中，單條命令是原子性執(zhí)行的，但事務(wù)不保證原子性，且沒有回滾。事務(wù)中任意命令執(zhí)行失敗，其余的命令仍會被執(zhí)行

Redis事務(wù)的三個階段

• 開始事務(wù)
• 命令入隊
• 執(zhí)行事務(wù)

Redis事務(wù)命令操作（本篇文章介紹大概的知識點，比如常用命令自己搜watch，exec命令找案例，不過多介紹了）

• watch key1 key2 … : 監(jiān)視一或多個key,如果在事務(wù)執(zhí)行之前，被監(jiān)視的key被其他命令改動，則事務(wù)被打斷 （ 類似樂觀鎖 ）
• multi : 標記一個事務(wù)塊的開始（ queued ）
• exec : 執(zhí)行所有事務(wù)塊的命令 （ 一旦執(zhí)行exec后，之前加的監(jiān)控鎖都會被取消掉 ）
• discard : 取消事務(wù)，放棄事務(wù)塊中的所有命令
• unwatch : 取消watch對所有key的監(jiān)控

壓縮表與跳躍表

壓縮表與跳躍表之間的關(guān)系就是 單個元素過于龐大時，轉(zhuǎn)換為跳躍表。簡單來說，也就是犧牲空間換速度的一種方案。任何一種便捷的技術(shù)都會有弊端的！

持久性

概念

持久化就是把內(nèi)存的數(shù)據(jù)寫到磁盤中去，防止服務(wù)宕機了內(nèi)存數(shù)據(jù)丟失。Redis 提供了兩種持久化方式:RDB（默認） 和AOF

RDB

RDB也就是快照，快照的作用就是在Redis崩掉的時候起到了恢復的作用。快照是保存當前某一個時間點范圍的數(shù)據(jù)，每個小時保存一次。 例如9點整開啟一次快照，在9點59的時候系統(tǒng)崩掉了。那么就損失了59分鐘的數(shù)據(jù)。這種的弊端是性能挺好，就是丟失的數(shù)據(jù)比較多一些。

AOF

AOF是追加文件的方式。AOF實時性更好。這種方式默認是不開啟的。AOF是實時的，所以就算丟失數(shù)據(jù)頂多只會丟失一秒的數(shù)據(jù)

持久性的方案

首先利用RDB快照進行整點恢復。然后再利用AOF進行剩余部分的實時恢復。RDB的恢復速度非常快，AOF恢復速度雖然慢一點但是恢復的數(shù)據(jù)量不大因為最多只會恢復一個小時內(nèi)的數(shù)據(jù)量。

還是舉以上的例子：9點鐘利用RDB進行了一次快照保存數(shù)據(jù)，9點59分的時候來了一個原子彈把服務(wù)器炸成灰了。持久化的方案就是利用RDB快照恢復了大部分的數(shù)據(jù)，但是丟失了59分鐘的數(shù)據(jù)，因為RDB是一個小時執(zhí)行一次快照所以RDB解決不了。利用AOF恢復剩下的59分的數(shù)據(jù)不需要利用AOF恢復整體的數(shù)據(jù)了。

常見問題

• 緩存穿透
• 緩存雪崩
• 緩存預(yù)熱
• 緩存降級

緩存穿透以及解決方案

緩存穿透：一般訪問緩存的流程，如果緩存中存在查詢的商品數(shù)據(jù)，那么直接返回。 如果緩存中不存在商品數(shù)據(jù)，就要訪問數(shù)據(jù)庫。由于不恰當?shù)臉I(yè)務(wù)功能實現(xiàn)，或者外部惡意攻擊不斷地請求某些不存在的數(shù)據(jù)內(nèi)存，由于緩存中沒有保存該數(shù)據(jù)，導致所有的請求都會落到數(shù)據(jù)庫上，對數(shù)據(jù)庫可能帶來一定的壓力，甚至崩潰。

解決方案：

針對緩存穿透的情況， 簡單的對策就是將不存在的數(shù)據(jù)訪問結(jié)果， 也存儲到緩存中，避免緩存訪問的穿透。最終不存在商品數(shù)據(jù)的訪問結(jié)果也緩存下來。有效的避免緩存穿透的風險

緩存雪崩以及解決方案

緩存雪崩：

當緩存重啟或者大量的緩存在某一時間段失效，這樣就導致大批流量直接訪問數(shù)據(jù)庫，對 DB 造成壓力， 從而引起 DB 故障，系統(tǒng)崩潰。

舉例來說， 我們在準備一項搶購的促銷運營活動，活動期間將帶來大量的商品信息、庫存等相關(guān)信息的查詢。 為了避免商品數(shù)據(jù)庫的壓力，將商品數(shù)據(jù)放入緩存中存儲。 不巧的是，搶購活動期間，大量的熱門商品緩存同時失效過期了，導致很大的查詢流量落到了數(shù)據(jù)庫之上。對于數(shù)據(jù)庫來說造成很大的壓力。

解決方案：

將商品根據(jù)品類熱度分類， 購買比較多的類目商品緩存周期長一些， 購買相對冷門的類目
商品，緩存周期短一些；

在設(shè)置商品具體的緩存生效時間的時候， 加上一個隨機的區(qū)間因子， 比如說 5~10 分鐘
之間來隨意選擇失效時間；

提前預(yù)估 DB 能力， 如果緩存掛掉，數(shù)據(jù)庫仍可以在一定程度上抗住流量的壓力

這三個策略能夠有效的避免短時間內(nèi)，大批量的緩存失效的問題

緩存預(yù)熱以及解決方案

緩存預(yù)熱就是系統(tǒng)上線后，將相關(guān)的緩存數(shù)據(jù)直接加載到緩存系統(tǒng)。這樣就可以避免在用戶請求的時候，先查詢數(shù)據(jù)庫，然后再將數(shù)據(jù)緩存的問題。用戶直接查詢事先被預(yù)熱的緩存數(shù)據(jù)。如果不進行預(yù)熱， 那么 Redis 初識狀態(tài)數(shù)據(jù)為空，系統(tǒng)上線初期，對于高并發(fā)的流量，都會訪問到數(shù)據(jù)庫中， 對數(shù)據(jù)庫造成流量的壓力。如圖所示：

解決方案：

數(shù)據(jù)量不大的時候，工程啟動的時候進行加載緩存動作；

數(shù)據(jù)量大的時候，設(shè)置一個定時任務(wù)腳本，進行緩存的刷新；

數(shù)據(jù)量太大的時候，優(yōu)先保證熱點數(shù)據(jù)進行提前加載到緩存

緩存降級以及解決方案

降級的情況，就是緩存失效或者緩存服務(wù)掛掉的情況下，我們也不去訪問數(shù)據(jù)庫。我們直接訪問內(nèi)存部分數(shù)據(jù)緩存或者直接返回默認數(shù)據(jù)。舉例來說：對于應(yīng)用的首頁，一般是訪問量非常大的地方，首頁里面往往包含了部分推薦商品的展示信息。這些推薦商品都會放到緩存中進行存儲，同時我們?yōu)榱吮苊饩彺娴漠惓Ｇ闆r，對熱點商品數(shù)據(jù)也存儲到了內(nèi)存中。同時內(nèi)存中還保留了一些默認的商品信息。

降級一般是有損的操作，所以盡量減少降級對于業(yè)務(wù)的影響程度。

集群

作為緩存數(shù)據(jù)庫，肯定要考慮緩存服務(wù)穩(wěn)定性相關(guān)的保障機制

持久化機制就是保證系統(tǒng)崩潰的一個機制

內(nèi)存淘汰機制就是保證系統(tǒng)內(nèi)數(shù)據(jù)是否一直有效的一個機制

那么如果單機數(shù)據(jù)直接掛掉，電腦炸成渣了怎么辦？怎么保證數(shù)據(jù)的備份呢？ 單點故障！延伸了集群！

Redis集群模式一共有三種

• 主從模式
• 哨兵模式
• cluster模式

解釋一下：

單機模式下如果數(shù)據(jù)被炸毀，也就是出現(xiàn)了單點故障，可以利用主從復制方式，進行多臺redis數(shù)據(jù)的全量同步。主從復制集群主要有三種分別是強一致性，弱一致性，最終一致性。強一致性可以保證redis1與redis2數(shù)據(jù)保證同步，但是真實的場景中往往影響性能。redis3與redis4無法保證數(shù)據(jù)必須一致，不出意外的話這種方式既可以解決主從復制也可以解決性能的問題所以這種方式是默認的。redis5與redis6利用黑盒最終一致性。

主從復制

顧名思義，Redis服務(wù)器分為兩類也就是主服務(wù)器(Master)與從數(shù)據(jù)庫(Slave)。這是為了避免單點故障的數(shù)據(jù)丟失引出的一個方案。通常的做法就是一臺服務(wù)器的數(shù)據(jù)復制多個副本以部署在不同的服務(wù)器上。即使有一臺服務(wù)器崩掉了也不至于癱瘓整個服務(wù)，另外幾臺服務(wù)器依然可以為系統(tǒng)提供服務(wù)。

Redis 提供了復制功能。可以實現(xiàn)當一臺數(shù)據(jù)庫中的數(shù)據(jù)更新后，自動將更新的數(shù)據(jù)同步到其他數(shù)據(jù)庫上。

優(yōu)點

一個主，可以有多個從，并以非阻塞的方式完成數(shù)據(jù)同步；

從服務(wù)器提供讀服務(wù)，分散主服務(wù)的壓力，實現(xiàn)讀寫分離；

從服務(wù)器之前可以彼此連接和同步請求，減少主服務(wù)同步壓力。

缺點

不具備容錯和恢復功能，主服務(wù)存在單點風險；

Redis 的主從復制采用全量復制，需要服務(wù)器有足夠的空余內(nèi)存；

主從模式較難支持在線擴容

哨兵模式

Redis 提供的 sentinel（哨兵）機制，通過 sentinel (哨兵)模式啟動redis后，自動監(jiān)控 主Master/從Slave的運行狀態(tài)，基本原理是：心跳機制 + 投票裁決。

簡單來說，哨兵的作用就是監(jiān)控 Redis 系統(tǒng)的運行狀況。它的功能包括以下兩個：

監(jiān)控主數(shù)據(jù)庫和從數(shù)據(jù)庫是否正常運行；

主數(shù)據(jù)庫出現(xiàn)故障時自動將從數(shù)據(jù)庫轉(zhuǎn)換為主數(shù)據(jù)庫。

哨兵模式主要有下面幾個內(nèi)容：

監(jiān)控（ Monitoring ）：Sentinel 會定期檢查主從服務(wù)器是否處于正常工作狀態(tài)。

提醒（ Notification ）：當被監(jiān)控的某個 Redis 服務(wù)器出現(xiàn)異常時，Sentinel 可以通過API 向管理員或者其他應(yīng)用程序發(fā)送通知。

自動故障遷移（Automatic failover）：當一個主服務(wù)器不能正常工作時，Sentinel 會開始一次自動故障遷移操作，它會將失效主服務(wù)器的其中一個從服務(wù)器升級為新的主服務(wù)器，并讓失效主服務(wù)器的其他從服務(wù)器改為復制新的主服務(wù)器；當客戶端試圖連接失效的主服務(wù)器時，集群也會向客戶端返回新主服務(wù)器的地址， 使得集群可以使用新主服務(wù)器代替失效服務(wù)器。

Redis Sentinel 是一個分布式系統(tǒng)，你可以在一個架構(gòu)中運行多個 Sentinel （哨兵）進程（ progress ）

優(yōu)點

哨兵模式主從可以切換，具備基本的故障轉(zhuǎn)移能力；

哨兵模式具備主從模式的所有優(yōu)點。

缺點

哨兵模式也很難支持在線擴容操作；

集群的配置信息管理比較復雜

cluster模式

Redis Cluster 是一種服務(wù)器 Sharding 技術(shù)，采用無中心結(jié)構(gòu)，每個節(jié)點保存數(shù)據(jù)和整個集群狀態(tài),每個節(jié)點都和其他所有節(jié)點連接。

Cluster 集群結(jié)構(gòu)特點：

Redis Cluster 所有的物理節(jié)點都映射到 [ 0-16383 ] slot 上（不一定均勻分布），Cluster
負責維護節(jié)點、桶、值之間的關(guān)系；

在 Redis 集群中放置一個 key-value 時，根據(jù) CRC16(key) mod 16384 的值，從之前
劃分的 16384 個桶中選擇一個；

所有的 Redis 節(jié)點彼此互聯(lián)（PING-PONG 機制），內(nèi)部使用二進制協(xié)議優(yōu)化傳輸效率；

超過半數(shù)的節(jié)點檢測到某個節(jié)點失效時則判定該節(jié)點失效；

使用端與 Redis 節(jié)點鏈接,不需要中間 proxy 層，直接可以操作，使用端不需要連接集群
所有節(jié)點，連接集群中任何一個可用節(jié)點即可。

優(yōu)點

無中心架構(gòu)，節(jié)點間數(shù)據(jù)共享，可動態(tài)調(diào)整數(shù)據(jù)分布；

節(jié)點可動態(tài)添加刪除，擴展性比較靈活；

部分節(jié)點異常，不影響整體集群的可用性。

缺點

集群實現(xiàn)比較復雜；

批量操作指令（ mget、mset 等）支持有限；

事務(wù)操作支持有限

如何解決并發(fā)？

多實例的方式

分布式的話又會遇到哪些問題呢？

redis分布式并發(fā)競爭key的問題

所謂 Redis 的并發(fā)競爭 Key 的問題也就是多個系統(tǒng)同時對一個 key 進行操作，但是最后執(zhí)行的順序和我們期望的順序不同，這樣也就導致了結(jié)果的不同！

推薦一種方案：分布式鎖（zookeeper 和 redis 都可以實現(xiàn)分布式鎖）。（如果不存在 Redis的并發(fā)競爭 Key 問題，不要使用分布式鎖，這樣會影響性能）

基于zookeeper臨時有序節(jié)點可以實現(xiàn)的分布式鎖。大致思想為：每個客戶端對某個方法加鎖時，在zookeeper上的與該方法對應(yīng)的指定節(jié)點的目錄下，生成一個唯一的瞬時有序節(jié)點。判斷是否獲取鎖的方式很簡單，只需要判斷有序節(jié)點中序號最小的一個。當釋放鎖的時候，只需將這個瞬時節(jié)點刪除即可。同時，其可以避免服務(wù)宕機導致的鎖無法釋放，而產(chǎn)生的死鎖問題。完成業(yè)務(wù)流程后，刪除對應(yīng)的子節(jié)點釋放鎖。在實踐中，當然是從以可靠性為主。所以首推Zookeeper。參考：https://www.jianshu.com/p/8bddd381de06

如何保證緩存與數(shù)據(jù)庫雙寫時的數(shù)據(jù)一致性？

你只要用緩存，就可能會涉及到緩存與數(shù)據(jù)庫雙存儲雙寫，你只要是雙寫，就一定會有數(shù)據(jù)一致性的問題，那么你如 何解決一致性問題？

一般來說，就是如果你的系統(tǒng)不是嚴格要求緩存+數(shù)據(jù)庫必須一致性的話，緩存可以稍微的跟數(shù)據(jù)庫偶爾有不一致的 情況，最好不要做這個方案，讀請求和寫請求串行化，串到一個內(nèi)存隊列里去，這樣就可以保證一定不會出現(xiàn)不一致 的情況串行化之后，就會導致系統(tǒng)的吞吐量會大幅度的降低，用比正常情況下多幾倍的機器去支撐線上的一個請求。參考https://zhuanlan.zhihu.com/p/63428500

這篇文章的描述是跟馬士兵教育視頻，敖丙，DeepInThought，問天 學習之后自己優(yōu)化升級的！感謝這幾位大佬！

知道的越多，不知道的就越多。找準方向，堅持自己的定位！加油向前不斷前行，終會有柳暗花明的一天！
創(chuàng)作不易，你們的支持就是對我最大認可！
文章將持續(xù)更新，我們下期見！【下期將更新SpringCloud入門 QQ群：1076570504 微信公眾號搜索【歡少的成長之路】請多多支持！

總結(jié)

以上是生活随笔為你收集整理的Redis你能跟面试官聊哪些？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。