已獲千贊，完整版開放免費下載下傳！
阻塞IO
我們知道在調用某個函數的時候無非就是兩種情況，要麼馬上傳回，然後根據傳回值進行接下來的業務處理。當在使用阻塞IO的時候，應用程式會被無情的挂起，等待核心完成操作，因為此時的核心可能将CPU時間切換到了其他需要的程序中，在我們的應用程式看來感覺被卡主(阻塞)了。
非阻塞IO
當使用非阻塞函數的時候，和阻塞IO類比，核心會立即傳回，傳回後獲得足夠的CPU時間繼續做其他的事情。
IO複用模型
當使用fgets等待标準輸入的時候，如果此時套接字有資料但不能讀出。IO多路複用意味着可以将标準輸入、套接字等都當做IO的一路，任何一路IO有事件發生，都将通知相應的應用程式去處理相應的IO事件，在我們看來就反複同時可以處理多個事情。這就是IO複用。
信号驅動IO
在信号驅動式 I/O 模型中，應用程式使用套接口進行信号驅動 I/O，并安裝一個信号處理函數，程序繼續運作并不阻塞。當資料準備好時，程序會收到一個 SIGIO 信号，可以在信号處理函數中調用 I/O 操作函數處理資料。
異步IO
用程式告知核心啟動某個操作，并讓核心在整個操作（包括将資料從核心拷貝到應用程式的緩沖區）完成後通知應用程式。那麼和信号驅動有啥不一樣?
講講select和epoll的差別？
這裡一樣的套路，先說出兩者的用途，然後兩者的優缺點。
select的缺點
select傳回的是含有整個句柄的數組，應用程式需要周遊整個數組才能發現哪些句柄發生了事件
select的觸發方式是水準觸發，應用程式如果沒有完成對一個已經就緒的檔案描述符進行IO操作，那麼之後每次select調用還是會将這些檔案描述符通知程序
核心 / 使用者空間記憶體拷貝問題，select每次都會改變核心中的句柄資料結構集，因而每次select調用時都需要從使用者空間向核心空間複制所有的句柄資料結構，産生巨大的開銷
單個程序能夠監視的檔案描述符的數量存在最大限制，通常是1024，當然可以更改數量
epoll實作
epoll在核心中會維護一個紅黑樹和一個雙向連結清單，紅黑樹存放通過epoll_ctl方法向epoll對象中添加進來的事件，是以不需要每次調用epoll_wait都全量複制所有的事件結構。雙向連結清單存放就緒的事件，所有添加到epoll中的事件都會與裝置(網卡)驅動程式建立回調關系，也就是說，當相應的事件發生時會調用這個回調方法，這個回調方法在核心中叫ep_poll_callback,它會将發生的事件添加到rdlist雙連結清單中。調用epoll_wait就會直接傳回連結清單中的就緒事件，效率高。
select适合少量活躍連接配接，一般幾千。
epoll适合大量不太活躍的連接配接。
樂觀鎖和悲觀鎖了解嗎？
這個問題延伸的問題會很多，比如線程安全，CAS原理，優缺點等。
啥是悲觀和樂觀，咋們面試的時候不得樂觀一些。想給面試來一波官方解釋，然後大白話解釋一波就差不多了。
官方：悲觀鎖是總是假設最壞的情況，每次那資料都認為别人會修改它，是以每次去那資料都要上鎖，這樣别人去拿這個資料就會阻塞。樂觀鎖就不一樣了，總是覺得一切都是最好的安排，每次拿資料都認為别人不會修改，是以也就不上鎖，但是在更新的時候會判斷這個期間别人有沒有更新這個資料。
什麼是緩存穿透？如何避免？什麼是緩存雪崩？何如避免？
緩存穿透
一般來說，緩存系統會通過key去緩存查詢，如果不存在對應的value，就應該去後端系統查找（比如DB）。這個時候如果一些惡意的請求到來，就會故意查詢不存在的key,當某一時刻的請求量很大，就會對後端系統造成很大的壓力。這就叫做緩存穿透。
如何避免？
對查詢結果為空的情況也進行緩存，緩存時間設定短一點，或者該key對應的資料insert了之後清理緩存。對一定不存在的key進行過濾。可以把所有的可能存在的key放到一個大的Bitmap中，查詢時通過該bitmap過濾。
緩存雪崩
當緩存伺服器重新開機或者大量緩存集中在某一個時間段失效，這樣在失效的時候，會給後端系統帶來很大壓力。導緻系統崩潰。
在緩存失效後，通過加鎖或者隊列來控制讀資料庫寫緩存的線程數量。比如對某個key隻允許一個線程查詢資料和寫緩存，其他線程等待。
做二級緩存，A1為原始緩存，A2為拷貝緩存，A1失效時，可以通路A2，A1緩存失效時間設定為短期，A2設定為長期。
不同的key，設定不同的過期時間，讓緩存失效的時間點盡量均勻。
如果是後端/服務端面試的同學，怎麼說都的去找一本redis書來看看，其出現的機率隻有那麼大了，切記切記。看看B站問了哪幾個問題。
redis的淘汰删除政策了解嗎？
能說不了解嗎，就算是沒有聽說過，咋們也可以來一句：“不好意思面試官，這一塊還不怎麼深入，但是從字面意思來了解巴拉巴拉”，不至于一臉懵逼。下面我們看看redis的緩存政策
Redis中通過maxmemory參數來設定記憶體的使用上限，如果Redis所使用記憶體超過設定的最大值，那麼會根據配置檔案中的政策選取要删除的key來删除，進而留出新的鍵值空間。主要的六種淘汰key政策
volatile-lru
在鍵空間中設定過期時間，移除哪些最近最少使用的key，占着茅坑不拉屎的key
allkeys-lru
移除最近最少使用的key
volatile-random
在鍵空間中設定過期時間，随機移除一個key
allkeys-random
随機移除一個key
noeviction
當記憶體使用達到閥值的時候，所有引起申請記憶體的指令會報錯；
ok，現在知道了需要淘汰哪些key，那我們如何去淘汰這些key
定時删除
很簡單，設定一個鬧鐘，鬧鐘響了就删除即可。這種方式對于記憶體來說還是比較友好，記憶體不需要啥額外的操作，直接通過定時器就可保證盡快的删除。對于CPU來說就有點麻煩了，如果過期鍵比較多，那麼定時器也就多，這删除操作就會占用太多的CPU資源
惰性删除
每次從鍵空間擷取鍵的時候檢查鍵的過期時間，如果過期了，删除完事。
定期删除
每隔一段時間就去資料庫檢查，删除過期的鍵
這種方案是定時删除和惰性删除的中和方法，既通過限制删除操作執行的時長來減少對CPU時間的影響，也能減少記憶體的浪費。但是難點在于間隔時長需要根據業務情況而定。
mysql中使用的鎖有哪些？什麼時候使用行鎖，什麼時候會使用表鎖？
InnoDB中的行鎖是通過索引上的索引項實作，主要特點是，隻有通過索引條件檢索資料，InnoDB才會使用行級鎖，否則InnoDB将使用表鎖。
這裡注意，在Mysql中，行級鎖不是鎖記錄而是鎖索引。索引又分為主鍵索引和非主鍵索引兩種。如果在一條語句中操作了非主鍵索引，Mysql會鎖定該非主鍵索引，再鎖定相關的主鍵索引。
了解過間隙鎖嗎？間隙鎖的加鎖範圍是怎麼确定的？
了解B+樹嗎？B+樹什麼時候會出現結點分裂？
這個回答在上一篇的B+樹已經詳細說了。這裡簡述一下
将已滿結點進行分裂，将已滿節點後M/2節點生成一個新節點，将新節點的第一個元素指向父節點。
父節點出現已滿，将父節點繼續分裂。
一直分裂，如果根節點已滿，則需要分類根節點，此時樹的高度增加。
事務還沒執行完資料庫挂了，重新開機的時候會發生什麼？
undo日志和redo日志分别是幹嘛的？
redo log重做日志是InnDB存儲引擎層的，用來保證事務安全。在事務送出之前，每個修改操作都會記錄變更後的資料，儲存的是實體日志-資料，防止發生故障的時間點，有髒頁未寫入磁盤，在重新開機mysql的時候，根據redo log進行重做進而達到事務的持久性
undo log復原日志儲存了事務發生之前的資料的一個版本，可以用于復原，同時也提供多版本并發控制下的讀。
簡單講講資料庫的MVCC的實作原理？
細說太多了，幾個大寫字母代表啥，這幾個大寫字母又是如何關聯起來完事。細問再深究
mysql的binlog日志什麼時候會使用？
首先應該知道binlog是一個二進制檔案，記錄所有增删改操作，節點之間的複制都會依靠binlog來完成。從底層原理來說，binlog有三個模式
模式1--row模式
每一行的資料被修改就會記錄在日志中，然後在slave段對相同的資料進行修改。比如說"update xx where id in(1,2,3,4,5)"，使用此模式就會記錄5條記錄
模式2--statement模式
修改資料的sql會記錄到master的binlog中。slave在複制的時候sql thread會解析成和原來maseter端執行過的相同的sql在此執行
模式3--mixed模式
mixed模式即混合模式，Mysql會根據執行的每一條具體sql區分對待記錄的日志形式。那麼binlog的主從同步流程到底是咋樣的
流程簡述：
Master執行完增删改操作後都會記錄binlog日志,當需要同步的時候會主動通知slave節點，slave收到通知後使用IO THREAD主動去master讀取binlog寫入<code>relay</code>日志(中轉日志),然後使 SQL THREAD完成對relay日志的解析然後入庫操作,完成同步。
使用LRU時，如果短時間内會出現大量隻會使用一次的資料，可能導緻之前大量高頻使用的緩存被删除，請問有什麼解決辦法?
了解過循環連結清單嗎？他的長度怎麼計算？
他的主要特點是連結清單中的最後一個節點的指針域指向頭結點，整個連結清單形成一個環。****這裡循環連結清單判斷連結清單結束的标志是，判斷尾節點是不是指向頭結點
哪種資料結構可以支援快速插入，删除，查找等操作？
思考這個問題的時候，我們不凡複習下不錯的二分查找，它依賴數組随機通路的特性，其查找時間複雜度為O(log n)。如果我們将元素放傳入連結表中，二分查找還好使嗎？這就是今天和大家分享的跳表
了解跳表
假設使用單連結清單存儲n個元素，其中元素有序如下圖所示
從連結清單中查找一個元素，自然從頭開始周遊找到需要查找的元素，此時的時間複雜度為O(n)。那采用什麼方法可以提高查詢的效率呢？問就是加索引，如何加，我們從這部分資料中抽取幾個元素出來作為單獨的一個連結清單，如下圖所示]
假設此時咋們查找元素16，首先一級索引處尋找，當找到元素14的時候，下一個節點的值為18，意味着我們尋找的數在這兩個數的中間。此時直接從14節點指針下移到下面的原始連結清單中，繼續周遊，正好下一個元素就是我們尋找的16。好了，我們小結一下，如果從原始連結清單中尋找元素16，需要周遊比較8次，如果通過索引連結清單尋找我們隻需要5次即可。
我們繼續查找元素16，此時比較次數變為4次。這樣看來，加一層索引查找的次數就變少，如果有n個元素到底有多少索引？
假設我們按照每兩個結點就抽出一個結點作為上一層的索引節點，第一層是以節點個數n/2，第二層為n/4,第x級索引的結點個數是第x-1級索引的結點個數的1/2，那第x級索引結點的個數就是n/(2x)。假設索引有y級，我們可以得到n/(2y)=2，進而求得y=log2n-1。
這麼多索引是不是就很浪費記憶體嘞？
假設原始連結清單大小為n，那第一級索引大約有 n/2 個結點，第二級索引大約有 n/4 個結點，以此類推，每上升一級就減少一半，直到剩下 2 個結點。如果我們把每層索引的結點數寫出來，就是一個等比數列。這幾級索引的結點總和就是 n/2+n/4+n/8…+8+4+2=n-2 。是以，跳表的空間複雜度是 O(n) 。那還能不能降低一些呢。機智的你應該就考慮到假設每三個結點抽取一個節點作為索引連結清單的節點。
跳表與二叉查找樹
兩者其查找的時間複雜度均為O(logn) ，那跳表還有哪些優勢？
先看二叉查找樹，
這種結構會導緻二叉查找樹的查找效率變為 O(n),。
跳表與紅黑樹
說實話，紅黑樹确實比較複雜，面試的時候讓你寫紅黑樹，你就給他大嘴巴子？
紅黑樹需要通過左右旋的方式去維持樹大小平衡。而跳表是通過随機函數來維護前面提到的 “ 平衡性 ” 。當我們往跳表中插入資料的時候，我們可以選擇同時将這個資料插入到部分索引層中。如何選擇加入哪些索引層呢？
我們通過一個随機函數，來決定将這個結點插入到哪幾級索引中，比如随機函數生成了值 K ，那我們就将這個結點添加到第一級到第 K 級這 K 級索引中。當我們往跳表中插入資料的時候，我們可以選擇同時将這個資料插入到部分索引層中。
小結
Redis中的有序集合采用了跳表的方式來實作，其實還采用了散清單等資料結構進行融合。它在插入，删除等都有比較快的速度，雖然紅黑樹也可以做到，但是紅黑樹對于按照區間查找資料這個操作，跳表可以做到 O(logn) 的時間複雜度定位區間的起點，然後在原始連結清單中順序往後周遊就可以了
請記下以下幾點:
公司招你去是幹活了，不會因為你怎麼怎麼的而降低對你的要求标準。
工具上面寫代碼和手撕代碼完全不一樣。
珍惜每一次面試機會并學會複盤。
對于應屆生主要考察的還是計算機基礎知識的掌握，項目要求沒有那麼高，是自己做的就使勁摳細節，做測試，隻有這樣，才知道會遇到什麼問題，遇到什麼難點，如何解決的。進而可以侃侃而談了。
非科班也不要怕，怕了你就輸了！一定要多嘗試。