C++編程經驗(10):無鎖編程其實沒那么玄乎
803
2022-05-29
哈嘍!大家好,我是小奇,一位不靠譜的程序員
小奇打算以輕松幽默的對話方式來分享一些技術,如果你覺得通過小奇的文章學到了東西,那就給小奇一個贊吧
文章持續更新,可以微信搜索【小奇JAVA面試】第一時間閱讀,回復【資料】更有我為大家準備的福利喲!
文章目錄
一、前言
二、面試
三、Redis如何實現持久化
1、AOF重寫
2、RDB和AOF混合使用
四、Redis主從架構
五、Redis哨兵架構
六、總結
一、前言
作為一名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還沒有整理完畢,文章后面持續更新,建議。
文章中涉及到的命令大家一定要像我一樣每個都敲幾遍,只有在敲的過程中才能發現自己對命令是否真正的掌握了。
如果覺得我的文章還不錯的話就點個贊吧,另外可以微信搜索【小奇JAVA面試】閱讀更多的好文章,獲取我為大家準備的資料。
Redis
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。