哈嘍！大家好，我是小奇，一位不靠譜的程式設計師
小奇打算以輕鬆幽默的對話方式來分享一些技術，如果你覺得通過小奇的文章學到了東西，那就給小奇一個贊吧
文章持續更新
一、前言
作為一名Java程式設計師，Redis底層的一些原理是我們不必學會就可以搬磚工作的一種技能點，但是小奇為什麼還要講一下呢？難道就是為了浪費大家1分鐘的寶貴時間，一個人1分鐘，50萬人就是1年，5000萬人就是100年，賺了，小奇以一己之力成功搞掛一個人（血賺）。
當然不是，並且小奇的文章也沒有那麼多人看，最多也就浪費個腎吧。
學習Redis底層原理是因為面試官要問啊！，所以我們就要學，什麼？不實用的你不學？那鄰居小奇可要使勁學啦，到時候面試官只要小奇不要你。
至於你問為什麼面試官要問Redis底層原理呢，這個。。。我把這次機會留給你，下次你面試的時候面試官問：“講一下Redis底層原理”。你：“面試官你好，請問為什麼你要問Redis底層原理呢，你給我臺電腦，我五分鐘給你搭建好圖書管理系統他不香嗎，我們們鍵盤上見真章”。這時面試官就會告訴你答案，你就可以把答案打在評論區，讓小奇以及眾多小夥伴一起知道一下到底為什麼要問？
二、面試
在一個晴朗的週日，我來到了一個陌生的園區（別問為什麼是週日，問就是997，不過為了填飽肚子的打工人，只能明知山有虎、偏向虎山行），坐在陌生的會議室，等待HR小姐姐去叫面試官，此時我的心情和各位小夥伴一樣五味雜陳，擔心面試官問的會不會很難？問到我的知識盲區我該怎麼辦？一會自我介紹的時候要不要吹一下我和小奇的關係？
一位英俊瀟灑，眼神犀利的面試官走了進來，看到他那犀利、彷彿能看穿一切的眼神 ，我在想要不然一會就不要20k了，要8k得了，這個面試官一看就不好糊弄啊，但是我想起來我來之前剛看了小奇的趣學程式設計系列，我已經完全學會了小奇的精髓，我頓時就來了底氣，決定一會要30k，不給就學小奇賴著不走（哈哈）
面試官：小奇是吧，帶簡歷了嗎？
我：沒帶，現在彩印兩塊一張，我簡歷五張，每次面試都要花費十塊，我朋友說了還沒工作就先讓你掏錢的工作不要去。
面試官：。。。那你靠什麼來征服我，讓我錄用你
我：氣質？
（此時面試官並沒有叫保安，而是從門後拿出了恭候我多時的棍子，我瞬間慫了）
我只好從我的雙肩包中拿出了我上午從其他公司面試官手中要回的簡歷，上午的情形是這樣的。
上午的面試官：今天的面試就到這吧，回去等通知吧！
我：面試官你好，如果貴公司不打算錄取我的話，能不能把我的紙質簡歷還給我，我下午還有一家面試。
上午的面試官：我說你的簡歷怎麼皺皺巴巴，原來你一直在迴圈利用啊！這個症狀出現多久了？
我：半拉月了。。。
（當我把皺皺巴巴的簡歷交給面試官後，這場面試才得以繼續進行。。。）
三、Redis如何實現持久化
面試官：我看你簡歷上寫的精通Redis？（哼，面試官輕蔑的一笑）
（看著面試官輕蔑的笑容，我忍不住拿出了我的Redis書籍推給了他）
我：這本書我倒背如流，你隨便提問，答不上來算我輸，答上來你就要為你的輕蔑向我道歉。
（我的笑容逐漸自信。。。）
（此時面試官看著書若有所思，我懷疑他肯定在想他對這本書的瞭解程度吧）
面試官：好吧，那你先說一下Redis如何實現持久化的
我：Redis主要有兩種持久化方式，一種是RDB（快照）方式，另一種是AOF格式。
面試官：可以說一說兩者的區別和如何配置使用嗎
我們可以想象一下我現在要記錄一個人的姿勢是什麼樣子的，那麼我只能通過拍照，或者描述來記錄
RDB（快照）方式可以理解我想知道目前一個人的姿勢是什麼樣子的，那麼我就給他拍一張照片，那麼照片上就是他這個人的姿勢。
AOF可以理解為動作的描述，我通過對這個人每一個動作的描述來知道這個人的姿勢是什麼樣子的，比如這個人左手六、右手七、左腳畫圓、右腳踢，那麼我通過這些動作就知道這個人目前的姿勢。
所以RDB快照就相當於將Redis中的資料儲存了下來，恢復的時候只需要將照片拿出來，人根據姿勢恢復就行了。
而AOF相當於將Redis中的每一條執行命令記錄了下來，恢復的時候需要根據命令一條一條的來，先左手六、再右手七、再左腳畫圓、再右腳踢。。。（如果想不明白可以按照姿勢試一下就明白了）
RDB在redis.conf目錄中進行配置，命令格式為 save [時間] [次數]
那save 60 10000來舉例，含義是如果在60秒內有至少10000條改動，那麼就自動儲存一次，也就是拍一張照片，那麼中間如果改動到500條的時候Redis掛了，那麼這500條改動就找不到了。
如果執行save命令會造成Redis正常讀寫收到影響，我們可以用bgsave（寫時複製）命令來生成RDB快照，bgsave是用一個子執行緒來實現快照功能，主執行緒繼續他的讀寫任務
使用AOF來儲存資料就不會有RDB快照中Redis當機所產生的風險了，因為AOF儲存的是每一條命令，但是AOF也並不是只能每一條命令就儲存一次，這樣會耗費效能，我們可以設定為每1秒執行一次儲存，這樣就算丟失也只會丟失1秒的資料
可以通過配置檔案中的appendonly設定為yes來開啟AOF功能
AOF有三個儲存策略
appendfsync always：每次有新命令就儲存下來，效能最慢，但是最安全
appendsync everysec：每秒儲存一次命令，足夠快，故障時只會丟失1秒鐘的資料
appendfsync no：從不儲存，將資料交給作業系統來處理。更快，也更不安全
推薦使用每秒儲存一次命令的方式
1、AOF重寫
面試官：AOF中那麼多命令恢復起來太麻煩，有沒有什麼優化的方式
AOF檔案中有太多沒用的指令，所以AOF會定期根據記憶體的最新資料生成AOF檔案
例如我們記錄一個人的動作，發現他先抬手，再放下手、然後再抬手，那我我們可以將動作合併為一個動作就是抬手，因為執行抬手，放手，抬手三個動作和只執行一個抬手的動作是一樣的
我們可以配置AOF重寫的頻率，有兩個配置項
auto-aof-rewrite-percentage 100 （aof檔案自上一次重寫後檔案大小增長了100%則再次觸發重寫）
auto-aof-rewrite-min-size 64mb （aof檔案至少要達到64M才會自動重寫，檔案太小恢復速度本來就很快，重寫的意義不大）
aof可以手動重寫，命令為：bgrewriteaof，此時也會使用一個子程式來重寫，不會對redis的正常命令有影響
2、RDB和AOF混合使用
面試官：RDB和AOF各有優缺點，我們該怎麼選擇
在redis啟動的時候如果即配置RDB又配置AOF，則優先使用AOF，因為AOF更加安全，但是效能不太好，但是我們可以混合使用，達到更好的效果
將RDB和AOF混合使用，例如恢復的時候先根據照片恢復最後一次拍照記錄的樣子，然後再恢復拍照後記錄的動作
配置開啟混合使用：aof‐use‐rdb‐preamble yes
四、Redis主從架構
面試官：可以聊一聊redis的主從架構模式，以及怎樣搭建嗎
我：可以，redis的主從架構模式其實是用一個redis節點來做寫操作（主節點），多個redis節點來做讀操作（從節點），主節點會將寫入的資料同步給從節點，以保證從從節點讀取的資料是最新的資料
搭建方式：主節點不用修改任何配置，從節點修改redis.conf配置檔案
配置主節點的ip埠：replicaof （代表從節點從哪個主節點同步資料）
配置好從節點後啟動從節點，這個時候啟動從節點，從節點會從主節點去初次獲取資料
五、Redis哨兵架構
面試官：可以聊一聊redis的哨兵架構模式，以及怎樣搭建嗎
我：好的，哨兵架構是在主從架構上衍生出來的，因為主從架構中如果主節點掛了，那麼我們就不能夠寫入資料了，只能從從節點中讀取資料，這樣是很不方便的。
那麼我們弄一個哨兵叢集來監視這些節點，當主節點掛了以後我們哨兵選舉一個從節點成為主節點，並讓寫資料的命令得以繼續執行（我們用比較有名的村莊來舉例。。。）。
搭建：複製一份sentinel.conf檔案進行修改，redis中預設有這個檔案
修改埠號，以及sentinel命令，格式為：sentinel monitor <主節點名稱><埠>
quorum是一個數字型別，意思是有多少個sentinel認為這個主節點失效時才算真正的失效，比如我配置了三個sentinel，那麼我這裡2的含義就是有兩個sentinel認為當前主節點失效就算失效了。
面試官：小夥子真厲害啊，我這邊沒有什麼要問的了，你還有什麼問題要問（面試官兩眼放光）
我：額。。。面試官這個我的紙質簡歷可以給我嗎，可以不往我的簡歷上寫寫畫畫嗎，我明天的面試還要用。
面試官：還面啥別的公司啊，就來我這吧，條件隨便開
我：那就100k吧（此時面試官又拿起了他準備好的棍子）
面試官：你要是不來就給我推薦一下，讓別人來我這面試一下
我：你先好好學習一下Redis吧，今天幸虧只是我來了，如果是小奇的忠實讀者來了，你將會被虐的很慘的。（我將我的《Redis設計與實現》留給了面試官，轉身留下了帥氣的背影，而面試官落寞無神的呆呆的坐在那裡，彷彿一個億離他而去。。。）
六、總結
這裡關於Redis還沒有整理完畢，文章後面持續更新，建議收藏。
文章中涉及到的命令大家一定要像我一樣每個都敲幾遍，只有在敲的過程中才能發現自己對命令是否真正的掌握了。
如果覺得我的文章還不錯的話就點個贊吧。