你知道的越多浅碾，你不知道的越多
點(diǎn)贊再看大州，養(yǎng)成習(xí)慣
本文 GitHub https://github.com/JavaFamily 上已經(jīng)收錄，有一線大廠面試點(diǎn)思維導(dǎo)圖垂谢，也整理了很多我的文檔厦画，歡迎Star和完善，大家面試可以參照考點(diǎn)復(fù)習(xí)滥朱，希望我們一起有點(diǎn)東西根暑。
前言
作為一個(gè)在互聯(lián)網(wǎng)公司面一次拿一次Offer的面霸，打敗了無數(shù)競爭對(duì)手徙邻，每次都只能看到無數(shù)落寞的身影失望的離開排嫌，略感愧疚（請(qǐng)?jiān)试S我使用一下夸張的修辭手法）。
于是在一個(gè)寂寞難耐的夜晚缰犁，我痛定思痛淳地，決定開始寫互聯(lián)網(wǎng)技術(shù)棧面試相關(guān)的文章，希望能幫助各位讀者以后面試勢如破竹帅容，對(duì)面試官進(jìn)行360°的反擊颇象，吊打問你的面試官，讓一同面試的同僚瞠目結(jié)舌并徘，瘋狂收割大廠Offer遣钳！
所有文章的名字只是我的噱頭，我們應(yīng)該有一顆謙遜的心饮亏，所以希望大家懷著空杯心態(tài)好好學(xué)耍贾，一起進(jìn)步阅爽。
絮叨
男兒何不帶吳鉤，收取關(guān)山五十州 FPX ??B荐开，LPL兩年連冠?? ??B付翁！
看著金色的雨落下，我到窗邊晃听，發(fā)現(xiàn)天有點(diǎn)藍(lán)百侧，風(fēng)有點(diǎn)綿，我的眼角又濕了!
最近雙十一講道理有點(diǎn)忙的說能扒，直接肝爆佣渴，就是這樣作為暖男的我，還是給你們擠出時(shí)間搞出終章初斑，忍不住給自己點(diǎn)贊??
放個(gè)雙十一照片證明真的忙辛润，希望別取關(guān)！＜印砂竖！
現(xiàn)在你們?cè)诳吹臅r(shí)候，我應(yīng)該還在睡覺哈哈鹃答。困??
之前跟你們說的乎澄，限流，降級(jí)测摔，是不是在雙十一又應(yīng)驗(yàn)了置济，下單接口其實(shí)沒掛，犧牲部分用戶體驗(yàn)锋八，保住服務(wù)器浙于，你多點(diǎn)幾下是可以成功的，等流量高峰過去了查库，所有的用戶全部都恢復(fù)正常訪問路媚，服務(wù)器也沒啥事。
去年退款接口被打崩了樊销，今年阿里明顯也聰明了很多整慎。
正文
上幾期吊打系列我們提到了Redis的很多知識(shí)，還沒看的小伙伴可以回顧一下
那提到Redis我相信各位在面試，或者實(shí)際開發(fā)過程中對(duì)基本類型的使用場景，并發(fā)競爭帶來的問題淤袜，以及緩存數(shù)據(jù)庫雙寫入一致性的問題等痒谴，我們有請(qǐng)下一位受害者。
面試開始
一個(gè)大腹便便铡羡，穿著格子襯衣的中年男子积蔚，拿著一個(gè)滿是劃痕的mac向你走來，看著快禿頂?shù)念^發(fā)烦周，心想著肯定是尼瑪頂級(jí)架構(gòu)師吧尽爆！但是我們腹有詩書氣自華，虛都不虛读慎。（這不是第一篇文章的面試官么漱贱？）
小伙子，你還記得我在第一章里面問過你夭委，Redis有幾種基礎(chǔ)數(shù)據(jù)類型么幅狮？
嗯嗯，帥氣的面試官株灸，我肯定記得彪笼，沒齒難忘！Ｂ烨摇！
我特么謝謝你幅恋，都四面了還不給Offer杏死！
那你能說一下他們的特性，還有分別的使用場景么捆交？
行吧淑翼，那我先從String說起品追。
String：
這是最簡單的類型玄括，就是普通的 set 和 get，做簡單的 KV 緩存肉瓦。
但是真實(shí)的開發(fā)環(huán)境中遭京，很多仔可能會(huì)把很多比較復(fù)雜的結(jié)構(gòu)也統(tǒng)一轉(zhuǎn)成String去存儲(chǔ)使用，比如有的仔他就喜歡把對(duì)象或者List轉(zhuǎn)換為JSONString進(jìn)行存儲(chǔ)泞莉，拿出來再反序列話啥的哪雕。
我在這里就不討論這樣做的對(duì)錯(cuò)了，但是我還是希望大家能在最合適的場景使用最合適的數(shù)據(jù)結(jié)構(gòu)鲫趁，對(duì)象找不到最合適的但是類型可以選最合適的嘛斯嚎，之后別人接手你的代碼一看這么規(guī)范，誒這小伙子有點(diǎn)東西呀，看到你啥都是用的String堡僻，垃圾糠惫！
好了這些都是題外話了，道理還是希望大家記在心里钉疫，習(xí)慣成自然嘛硼讽，小習(xí)慣成就你。
String的實(shí)際應(yīng)用場景比較廣泛的有：
緩存功能：String字符串是最常用的數(shù)據(jù)類型陌选，不僅僅是Redis理郑，各個(gè)語言都是最基本類型，因此咨油，利用Redis作為緩存您炉，配合其它數(shù)據(jù)庫作為存儲(chǔ)層，利用Redis支持高并發(fā)的特點(diǎn)役电，可以大大加快系統(tǒng)的讀寫速度赚爵、以及降低后端數(shù)據(jù)庫的壓力。
計(jì)數(shù)器：許多系統(tǒng)都會(huì)使用Redis作為系統(tǒng)的實(shí)時(shí)計(jì)數(shù)器法瑟，可以快速實(shí)現(xiàn)計(jì)數(shù)和查詢的功能冀膝。而且最終的數(shù)據(jù)結(jié)果可以按照特定的時(shí)間落地到數(shù)據(jù)庫或者其它存儲(chǔ)介質(zhì)當(dāng)中進(jìn)行永久保存。
共享用戶Session：用戶重新刷新一次界面霎挟，可能需要訪問一下數(shù)據(jù)進(jìn)行重新登錄窝剖，或者訪問頁面緩存Cookie，但是可以利用Redis將用戶的Session集中管理酥夭，在這種模式只需要保證Redis的高可用赐纱，每次用戶Session的更新和獲取都可以快速完成。大大提高效率熬北。
Hash：
這個(gè)是類似 Map 的一種結(jié)構(gòu)疙描，這個(gè)一般就是可以將結(jié)構(gòu)化的數(shù)據(jù)，比如一個(gè)對(duì)象（前提是這個(gè)對(duì)象沒嵌套其他的對(duì)象）給緩存在 Redis 里讶隐，然后每次讀寫緩存的時(shí)候起胰，可以就操作 Hash 里的某個(gè)字段。
但是這個(gè)的場景其實(shí)還是多少單一了一些巫延，因?yàn)楝F(xiàn)在很多對(duì)象都是比較復(fù)雜的效五，比如你的商品對(duì)象可能里面就包含了很多屬性，其中也有對(duì)象炉峰。我自己使用的場景用得不是那么多火俄。
List：
List 是有序列表，這個(gè)還是可以玩兒出很多花樣的讲冠。
比如可以通過 List 存儲(chǔ)一些列表型的數(shù)據(jù)結(jié)構(gòu)瓜客，類似粉絲列表、文章的評(píng)論列表之類的東西。
比如可以通過 lrange 命令谱仪，讀取某個(gè)閉區(qū)間內(nèi)的元素玻熙，可以基于 List 實(shí)現(xiàn)分頁查詢，這個(gè)是很棒的一個(gè)功能疯攒，基于 Redis 實(shí)現(xiàn)簡單的高性能分頁嗦随，可以做類似微博那種下拉不斷分頁的東西，性能高敬尺，就一頁一頁走枚尼。
比如可以搞個(gè)簡單的消息隊(duì)列，從 List 頭懟進(jìn)去砂吞，從 List 屁股那里弄出來署恍。
List本身就是我們?cè)陂_發(fā)過程中比較常用的數(shù)據(jù)結(jié)構(gòu)了，熱點(diǎn)數(shù)據(jù)更不用說了蜻直。
消息隊(duì)列：Redis的鏈表結(jié)構(gòu)盯质，可以輕松實(shí)現(xiàn)阻塞隊(duì)列，可以使用左進(jìn)右出的命令組成來完成隊(duì)列的設(shè)計(jì)概而。比如：數(shù)據(jù)的生產(chǎn)者可以通過Lpush命令從左邊插入數(shù)據(jù)呼巷，多個(gè)數(shù)據(jù)消費(fèi)者，可以使用BRpop命令阻塞的“搶”列表尾部的數(shù)據(jù)赎瑰。
-
文章列表或者數(shù)據(jù)分頁展示的應(yīng)用王悍。
比如，我們常用的博客網(wǎng)站的文章列表餐曼，當(dāng)用戶量越來越多時(shí)配名，而且每一個(gè)用戶都有自己的文章列表，而且當(dāng)文章多時(shí)晋辆，都需要分頁展示，這時(shí)可以考慮使用Redis的列表宇整，列表不但有序同時(shí)還支持按照范圍內(nèi)獲取元素瓶佳，可以完美解決分頁查詢功能。大大提高查詢效率鳞青。
Set：
Set 是無序集合霸饲，會(huì)自動(dòng)去重的那種。
直接基于 Set 將系統(tǒng)里需要去重的數(shù)據(jù)扔進(jìn)去臂拓，自動(dòng)就給去重了厚脉，如果你需要對(duì)一些數(shù)據(jù)進(jìn)行快速的全局去重，你當(dāng)然也可以基于 JVM 內(nèi)存里的 HashSet 進(jìn)行去重胶惰，但是如果你的某個(gè)系統(tǒng)部署在多臺(tái)機(jī)器上呢傻工？得基于Redis進(jìn)行全局的 Set 去重。
可以基于 Set 玩兒交集、并集中捆、差集的操作鸯匹，比如交集吧，我們可以把兩個(gè)人的好友列表整一個(gè)交集泄伪，看看倆人的共同好友是誰殴蓬？對(duì)吧。
反正這些場景比較多蟋滴，因?yàn)閷?duì)比很快染厅，操作也簡單，兩個(gè)查詢一個(gè)Set搞定津函。
Sorted Set：
Sorted set 是排序的 Set肖粮，去重但可以排序，寫進(jìn)去的時(shí)候給一個(gè)分?jǐn)?shù)球散，自動(dòng)根據(jù)分?jǐn)?shù)排序尿赚。
有序集合的使用場景與集合類似，但是set集合不是自動(dòng)有序的蕉堰，而Sorted set可以利用分?jǐn)?shù)進(jìn)行成員間的排序凌净，而且是插入時(shí)就排序好。所以當(dāng)你需要一個(gè)有序且不重復(fù)的集合列表時(shí)屋讶，就可以選擇Sorted set數(shù)據(jù)結(jié)構(gòu)作為選擇方案冰寻。
排行榜：有序集合經(jīng)典使用場景。例如視頻網(wǎng)站需要對(duì)用戶上傳的視頻做排行榜皿渗，榜單維護(hù)可能是多方面：按照時(shí)間斩芭、按照播放量、按照獲得的贊數(shù)等乐疆。
-
用Sorted Sets來做帶權(quán)重的隊(duì)列划乖，比如普通消息的score為1，重要消息的score為2挤土，然后工作線程可以選擇按score的倒序來獲取工作任務(wù)琴庵。讓重要的任務(wù)優(yōu)先執(zhí)行。
微博熱搜榜仰美，就是有個(gè)后面的熱度值迷殿，前面就是名稱
小結(jié)
Redis基礎(chǔ)類型有五種，這個(gè)我在基礎(chǔ)里面也有提到了咖杂，這個(gè)問題其實(shí)一般都是對(duì)P6以下庆寺，也就是1-3年左右的小伙伴可能是會(huì)問得比較多的問題。
能回答出來五種我想大家都可以诉字，但是不知道大家是否知道懦尝，五種類型具體的使用場景知纷，以及什么時(shí)候用什么類型最合適呢？
要是你回答的不好导披，沒說出幾種數(shù)據(jù)類型屈扎，也沒說什么場景，你完了撩匕，面試官對(duì)你印象肯定不好鹰晨，覺得你平時(shí)就是做個(gè)簡單的 set 和 get。所以看似很簡單的面試題實(shí)則最容易看出你的深淺了止毕，大家都要注意打好基礎(chǔ)模蜡。
你有沒有考慮過，如果你多個(gè)系統(tǒng)同時(shí)操作（并發(fā)）Redis帶來的數(shù)據(jù)問題扁凛？
嗯嗯這個(gè)問題我以前開發(fā)的時(shí)候遇到過忍疾，其實(shí)并發(fā)過程中確實(shí)會(huì)有這樣的問題，比如下面這樣的情況
系統(tǒng)A谨朝、B卤妒、C三個(gè)系統(tǒng)，分別去操作Redis的同一個(gè)Key字币，本來順序是1则披，2，3是正常的洗出，但是因?yàn)橄到y(tǒng)A網(wǎng)絡(luò)突然抖動(dòng)了一下士复，B，C在他前面操作了Redis翩活，這樣數(shù)據(jù)不就錯(cuò)了么阱洪。
就好比下單，支付菠镇，退款三個(gè)順序你變了冗荸，你先退款，再下單利耍，再支付蚌本，那流程就會(huì)失敗，那數(shù)據(jù)不就亂了堂竟？你訂單還沒生成你卻支付，退款了玻佩？明顯走不通了出嘹，這在線上是很恐怖的事情。
那這種情況怎么解決呢咬崔？
我們可以找個(gè)管家?guī)臀覀児芾砗脭?shù)據(jù)的嘛税稼！
某個(gè)時(shí)刻烦秩，多個(gè)系統(tǒng)實(shí)例都去更新某個(gè) key±善停可以基于 Zookeeper 實(shí)現(xiàn)分布式鎖只祠。每個(gè)系統(tǒng)通過 Zookeeper 獲取分布式鎖，確保同一時(shí)間扰肌，只能有一個(gè)系統(tǒng)實(shí)例在操作某個(gè) Key抛寝，別人都不允許讀和寫。
你要寫入緩存的數(shù)據(jù)曙旭，都是從 MySQL 里查出來的盗舰，都得寫入 MySQL 中，寫入 MySQL 中的時(shí)候必須保存一個(gè)時(shí)間戳桂躏，從 MySQL 查出來的時(shí)候钻趋，時(shí)間戳也查出來。
每次要寫之前剂习，先判斷一下當(dāng)前這個(gè) Value 的時(shí)間戳是否比緩存里的 Value 的時(shí)間戳要新蛮位。如果是的話，那么可以寫鳞绕，否則失仁，就不能用舊的數(shù)據(jù)覆蓋新的數(shù)據(jù)。
你只要用緩存猾昆，就可能會(huì)涉及到緩存與數(shù)據(jù)庫雙存儲(chǔ)雙寫陶因，你只要是雙寫，就一定會(huì)有數(shù)據(jù)一致性的問題垂蜗，那么你如何解決一致性問題楷扬？
一般來說，如果允許緩存可以稍微的跟數(shù)據(jù)庫偶爾有不一致的情況贴见，也就是說如果你的系統(tǒng)不是嚴(yán)格要求 “緩存+數(shù)據(jù)庫” 必須保持一致性的話烘苹，最好不要做這個(gè)方案，即：讀請(qǐng)求和寫請(qǐng)求串行化片部，串到一個(gè)內(nèi)存隊(duì)列里去镣衡。
串行化可以保證一定不會(huì)出現(xiàn)不一致的情況，但是它也會(huì)導(dǎo)致系統(tǒng)的吞吐量大幅度降低档悠，用比正常情況下多幾倍的機(jī)器去支撐線上的一個(gè)請(qǐng)求廊鸥。
把一些列的操作都放到隊(duì)列里面，順序肯定不會(huì)亂辖所，但是并發(fā)高了惰说，這隊(duì)列很容易阻塞，反而會(huì)成為整個(gè)系統(tǒng)的弱點(diǎn)缘回，瓶頸
你了解最經(jīng)典的KV吆视、DB讀寫模式么典挑？
最經(jīng)典的緩存+數(shù)據(jù)庫讀寫的模式，就是 Cache Aside Pattern
- 讀的時(shí)候啦吧，先讀緩存您觉，緩存沒有的話，就讀數(shù)據(jù)庫授滓，然后取出數(shù)據(jù)后放入緩存琳水，同時(shí)返回響應(yīng)。
- 更新的時(shí)候褒墨，先更新數(shù)據(jù)庫炫刷，然后再刪除緩存。
為什么是刪除緩存郁妈，而不是更新緩存浑玛？
原因很簡單逝撬，很多時(shí)候抓督，在復(fù)雜點(diǎn)的緩存場景淆攻，緩存不單單是數(shù)據(jù)庫中直接取出來的值避凝。
比如可能更新了某個(gè)表的一個(gè)字段双吆，然后其對(duì)應(yīng)的緩存陆爽，是需要查詢另外兩個(gè)表的數(shù)據(jù)并進(jìn)行運(yùn)算缸废，才能計(jì)算出緩存最新的值的同云。
另外更新緩存的代價(jià)有時(shí)候是很高的仆百。是不是說厕隧，每次修改數(shù)據(jù)庫的時(shí)候，都一定要將其對(duì)應(yīng)的緩存更新一份俄周？也許有的場景是這樣吁讨，但是對(duì)于比較復(fù)雜的緩存數(shù)據(jù)計(jì)算的場景，就不是這樣了峦朗。如果你頻繁修改一個(gè)緩存涉及的多個(gè)表建丧，緩存也頻繁更新。但是問題在于波势，這個(gè)緩存到底會(huì)不會(huì)被頻繁訪問到翎朱？
舉個(gè)栗子：一個(gè)緩存涉及的表的字段，在 1 分鐘內(nèi)就修改了 20 次尺铣，或者是 100 次拴曲，那么緩存更新 20 次、100 次凛忿；但是這個(gè)緩存在 1 分鐘內(nèi)只被讀取了 1 次澈灼，有大量的冷數(shù)據(jù)。
實(shí)際上侄非，如果你只是刪除緩存的話蕉汪，那么在 1 分鐘內(nèi)，這個(gè)緩存不過就重新計(jì)算一次而已逞怨，開銷大幅度降低者疤。用到緩存才去算緩存。
其實(shí)刪除緩存叠赦，而不是更新緩存驹马，就是一個(gè) Lazy 計(jì)算的思想，不要每次都重新做復(fù)雜的計(jì)算除秀，不管它會(huì)不會(huì)用到糯累，而是讓它到需要被使用的時(shí)候再重新計(jì)算。
像 Mybatis册踩，Hibernate泳姐，都有懶加載思想。查詢一個(gè)部門暂吉，部門帶了一個(gè)員工的 List胖秒，沒有必要說每次查詢部門，都里面的 1000 個(gè)員工的數(shù)據(jù)也同時(shí)查出來啊慕的。80% 的情況阎肝，查這個(gè)部門，就只是要訪問這個(gè)部門的信息就可以了肮街。先查部門风题，同時(shí)要訪問里面的員工，那么這個(gè)時(shí)候只有在你要訪問里面的員工的時(shí)候嫉父，才會(huì)去數(shù)據(jù)庫里面查詢 1000 個(gè)員工沛硅。
Redis 和 Memcached 有啥區(qū)別，為啥選擇用Redis作為你們的緩存中間件熔号？
Redis 支持復(fù)雜的數(shù)據(jù)結(jié)構(gòu)：
Redis 相比 Memcached 來說稽鞭，擁有更多的數(shù)據(jù)結(jié)構(gòu)，能支持更豐富的數(shù)據(jù)操作引镊。如果需要緩存能夠支持更復(fù)雜的結(jié)構(gòu)和操作朦蕴， Redis 會(huì)是不錯(cuò)的選擇。
Redis 原生支持集群模式：
在 redis3.x 版本中弟头，便能支持 Cluster 模式吩抓，而 Memcached 沒有原生的集群模式，需要依靠客戶端來實(shí)現(xiàn)往集群中分片寫入數(shù)據(jù)赴恨。
性能對(duì)比：
由于 Redis 只使用單核疹娶，而 Memcached 可以使用多核，所以平均每一個(gè)核上 Redis 在存儲(chǔ)小數(shù)據(jù)時(shí)比 Memcached 性能更高伦连。而在 100k 以上的數(shù)據(jù)中雨饺，Memcached 性能要高于 Redis钳垮，雖然 Redis 最近也在存儲(chǔ)大數(shù)據(jù)的性能上進(jìn)行優(yōu)化，但是比起 Remcached额港，還是稍有遜色饺窿。
Tip：其實(shí)面試官這么問，是想看你知道為啥用這個(gè)技術(shù)棧么移斩？你為啥選這個(gè)技術(shù)棧肚医，你是否做過技術(shù)選型的對(duì)比，優(yōu)缺點(diǎn)你是否了解向瓷，你啥都不知道肠套，只是為了用而用，那你可能就差點(diǎn)意思了猖任。
Redis 的線程模型了解么你稚？
Redis 內(nèi)部使用文件事件處理器 file event handler，這個(gè)文件事件處理器是單線程的朱躺，所以 Redis 才叫做單線程的模型入宦。它采用 IO 多路復(fù)用機(jī)制同時(shí)監(jiān)聽多個(gè) Socket，根據(jù) Socket 上的事件來選擇對(duì)應(yīng)的事件處理器進(jìn)行處理室琢。
文件事件處理器的結(jié)構(gòu)包含 4 個(gè)部分：
- 多個(gè) Socket
- IO 多路復(fù)用程序
- 文件事件分派器
- 事件處理器（連接應(yīng)答處理器乾闰、命令請(qǐng)求處理器、命令回復(fù)處理器）
多個(gè) Socket 可能會(huì)并發(fā)產(chǎn)生不同的操作盈滴，每個(gè)操作對(duì)應(yīng)不同的文件事件涯肩，但是 IO 多路復(fù)用程序會(huì)監(jiān)聽多個(gè) Socket，會(huì)將 Socket 產(chǎn)生的事件放入隊(duì)列中排隊(duì)巢钓，事件分派器每次從隊(duì)列中取出一個(gè)事件病苗，把該事件交給對(duì)應(yīng)的事件處理器進(jìn)行處理。
面試結(jié)束
小伙子對(duì)你面試了四輪症汹，你說話有理有據(jù)硫朦，邏輯清晰，來公司后肯定是一把好手背镇，我想要不你來當(dāng)我的Leader吧咬展，哈哈？
面試官別跟我開玩笑了瞒斩，我跟您這樣日積月累的技術(shù)專家還是有很多差距的破婆，您的經(jīng)驗(yàn)和技術(shù)上的深度，沒有很長時(shí)間的磨練是無法達(dá)到的胸囱，我還得多跟您學(xué)習(xí)祷舀。
好的，小伙子有點(diǎn)東西，你年少有為不自卑裳扯，知道什么是珍貴抛丽，就是你了來上班吧。
好的面試官饰豺，不過我想我在Java基礎(chǔ)铺纽，MQ，Dubbo等等領(lǐng)域還有好多知識(shí)點(diǎn)您沒問我哟忍，要不下次繼續(xù)面我？
強(qiáng)行陷寝，為吊打下一期埋伏筆哈哈锅很，下期寫啥你們定！７锱堋爆安！
能撐到最后，你自己都忍不住自己給自己點(diǎn)個(gè)贊了!
（暗示點(diǎn)贊仔引，每次都看了不點(diǎn)贊扔仓，你們想白嫖我么？你們好壞喲咖耘，不過我喜歡）翘簇。
《吊打面試官》Redis系列 ---- 全劇終
總結(jié)
既然都說了是Redis的終章我最后也做個(gè)Redis方面常見面試題，題目的總結(jié)儿倒，答案大家要去思考我前面的文章基本上都提到了版保，結(jié)果可以去我公眾號(hào)回復(fù)【答案】獲取，不過我還是希望大家能看到題目就能想到答案夫否，并且記在心中彻犁，教大家怎么回答只是幫大家組織下語言，真正的場景解決方案還是要大家理解的凰慈。
（周三以后出答案汞幢，我先睡會(huì)）
- 0、在集群模式下微谓，Redis 的 Key 是如何尋址的森篷？分布式尋址都有哪些算法？了解一致性 Hash 算法嗎豺型？
- 1疾宏、使用Redis有哪些好處？
- 2触创、Redis相比Memcached有哪些優(yōu)勢坎藐？
- 3、Redis常見性能問題和解決方案
- 4、MySQL里有2000w數(shù)據(jù)岩馍，Redis中只存20w的數(shù)據(jù)碉咆，如何保證Redis中的數(shù)據(jù)都是熱點(diǎn)數(shù)據(jù)？
- 5蛀恩、Memcache與Redis的區(qū)別都有哪些疫铜？
- 6、Redis 常見的性能問題都有哪些双谆？如何解決壳咕？
- 7、在什么樣的場景下可以充分的利用Redis的特性顽馋，大大提高Redis的效率谓厘？
- 8、Redis的緩存雪崩寸谜、穿透竟稳、擊穿了解么？有什么異同點(diǎn)熊痴？分別怎么解決他爸？
- 9、Redis的基本類型有哪些果善？他們的使用場景了解么诊笤？比較高級(jí)的用法你使用過么？
- 10巾陕、Redis主從怎么同步數(shù)據(jù)的盏混？集群的高可用怎么保證？持久化機(jī)制了解么惜论？
- 11许赃、為什么 redis 單線程卻能支撐高并發(fā)？
- 12馆类、如何保證緩存和數(shù)據(jù)庫數(shù)據(jù)的一致性混聊？
- 13、項(xiàng)目中是怎么用緩存的乾巧，用了緩存之后會(huì)帶來什么問題句喜？
絮叨+
最后我想說的就是，我這四章只是介紹到了一些Redis面試比較常見的問題沟于，其實(shí)還有很多點(diǎn)我都沒回答到咳胃，大家如果為了對(duì)付面試可能是夠用了，但是我們技術(shù)人員還是要保持對(duì)技術(shù)的敬畏心旷太，你不能淺嘗即止展懈，還是要深究的销睁。
你永遠(yuǎn)只會(huì)用，不去考慮用了會(huì)帶來的問題存崖，以及出現(xiàn)問題之后的解決方案冻记，我覺得你大概率會(huì)停滯不前，既然入都入了這行了来惧，為啥不武裝一下自己冗栗。
其實(shí)學(xué)習(xí)技術(shù)是個(gè)反哺的過程，學(xué)習(xí)的時(shí)候可能你只是感覺知識(shí)廣度供搀、深度上去了隅居，一個(gè)知識(shí)點(diǎn)你這樣，兩個(gè)葛虐、三個(gè)知識(shí)點(diǎn)你都這樣胎源，最后你發(fā)現(xiàn)你的技術(shù)已經(jīng)跟身邊一樣P6的仔不一樣了，這樣你可能在團(tuán)隊(duì)重大項(xiàng)目的貢獻(xiàn)都上去了挡闰，那P7的晉升幾率是不是大了，錢是不是上去了掰盘，女朋友是不是好看了摄悯，房子是不是大了。
點(diǎn)關(guān)注愧捕，不迷路
好了各位奢驯，以上就是這篇文章的全部內(nèi)容了，能看到這里的人呀次绘，都是人才瘪阁。
我后面會(huì)每周都更新幾篇一線互聯(lián)網(wǎng)大廠面試和常用技術(shù)棧相關(guān)的文章，非常感謝人才們能看到這里邮偎，如果這個(gè)文章寫得還不錯(cuò)管跺，覺得「敖丙」我有點(diǎn)東西的話 求點(diǎn)贊?? 求關(guān)注?? 求分享?? 對(duì)暖男我來說真的 非常有用！：探豁跑！
創(chuàng)作不易，各位的支持和認(rèn)可泻云，就是我創(chuàng)作的最大動(dòng)力艇拍，我們下篇文章見！
敖丙 | 文 【原創(chuàng)】
如果本篇博客有任何錯(cuò)誤宠纯，請(qǐng)批評(píng)指教卸夕，不勝感激 ！
文章每周持續(xù)更新婆瓜，可以微信搜索「 三太子敖丙 」第一時(shí)間閱讀和催更（比博客早一到兩篇喲）快集，本文 GitHub https://github.com/JavaFamily 已經(jīng)收錄，有一線大廠面試點(diǎn)思維導(dǎo)圖，也整理了很多我的文檔碍讨，歡迎Star和完善治力，大家面試可以參照考點(diǎn)復(fù)習(xí)，希望我們一起有點(diǎn)東西勃黍。
