這個問題呢，可以說是後端開發面試最高頻次的問題之一了，小編幾乎每次都碰到。眾所周知，Redis是非常快的，那麼快到什麼地步呢？根據官方提供的資料為：讀的速度是110000次/s，寫的速度是81000次/s 。要知道
這個速度可以承載我們實際工作中99。99%的場景了。那麼Redis為啥這麼快呢？原因無非以下幾點，後面小編會一一展開解說的。
Redis的核心處理是單執行緒的
Redis是基於記憶體的KV資料庫
Redis整合了IO多路複用技術
Redis屬於非CPU密集型任務
核心處理執行緒為單執行緒
各位小夥伴是不是有點懵圈了，9102年都過去了，居然還有基於單執行緒的資料庫，
QPS居然還能達到每秒10W+。沒錯，這就是Redis。
首先我們需要知道的是Redis並不是嚴格意義上的單執行緒，只是核心處理執行緒是單執行緒而已。
Redis還有很多邊角料的處理執行緒，如記憶體淘汰，AOF檔案重寫等。
這裡特別需要指出Redis 6。0，有人認為6。0後Redis之後開啟了多執行緒。為了防止後面有人和小編battle，故而特地說一下。小編認為這個更像是一個“偽多執行緒
”，為什麼這麼說呢？因為6。0引入的多執行緒只是為了處理請求資料的協議解析，它主要是解決高併發場景下，單執行緒解析請求資料協議帶來的壓力。請求資料的協議解析由多執行緒完成之後，後面的請求處理階段依舊還是單執行緒排隊處理。所以小編總結一下，
核心處理執行緒一直是單執行緒
。
上面我們已經知道了Redis的核心處理執行緒是單執行緒，單執行緒給人的直觀感受就是比多執行緒慢，但是單執行緒有單執行緒的優點。主要集中在兩點，
一個是沒有了多執行緒上下文頻繁切換的效能損耗，另一個是訪問共享資源時不需要加鎖解鎖操作
。
基於以上特性，Redis採用單執行緒能足夠達到非常高的效能，所以Redis沒有采用多執行緒模型。
說完了優點，小編說一下單
執行緒的缺點。單執行緒處理最大的缺點就是容易阻塞，如果前一個請求比較耗時，那麼整個Redis就會阻塞住，其他請求也無法進來，直到這個耗時久的操作處理完成並返回，其他請求才能被處理到。
基於記憶體的KV資料庫
稍微對計算機硬體有點了解的同學應該都會知道，不同的硬體訪問速度是有著成百上千倍的差距的。最快的一般是暫存器，但是由於成本太高了，一般人用不起，不利於普及，故而選擇了一個比較折中的方案——【記憶體】。記憶體訪問速度一般是納秒級（10的-9次方），磁碟的訪問速度一般是微秒級（10的-3次方）。所以這個層面決定了Redis比那些將資料存放在磁碟的資料庫快了幾個量級
此外Redis還是KV型資料庫，
它內部維護了一個雜湊表，根據指定的key進行訪問，
理論上只需要O（1）的時間複雜度便可以實現存取操作。前提是雜湊函式比較完美，沒有過多的雜湊衝突。
IO多路複用技術
前面我們已經知道Redis採用單執行緒，那麼它是如何處理多個客戶端連線請求呢。答案是
Redis整合了IO多路複用技術
。常見的IO多路複用技術主要有select，poll，epoll（後續小編會專門講述一下這一個知識點，本次不做贅述）。而其中效率最好的便是epoll，Redis便是使用了epoll。
Redis採用了IO多路複用技術和非阻塞IO，這個技術由作業系統實現提供，Redis可以方便地作業系統的API即可。Redis可以在單執行緒中監聽多個Socket的請求，在任意一個Socket可讀/可寫時，Redis去讀取客戶端請求，在記憶體中操作對應的資料，然後再寫回到Socket中。整個過程非常高效，Redis利用了IO多路複用技術的事件驅動模型，保證在監聽多個Socket連線的情況下，只針對有活動的Socket採取反應。
非CPU密集型任務
前面我們已經知道Redis採用單執行緒，那麼必然有一個很嚴重的缺點，那就無法使用多核CPU。不過好在Redis的大部分操作並不是CPU密集型任務，而Redis的瓶頸在於記憶體和網路頻寬。在高併發請求下，Redis需要更多的記憶體和更高的網路頻寬，否則瓶頸很容易出現在記憶體不夠用和網路延遲等待的情況。
資料環節
又到了大家期待的福利時間了。本次贈送的是Redis常見面試題。
廢話不多說，各位看官大人要怎麼獲取呢。很簡單，
關注小編，私信「資料」即可獲得免費獲取方式。
如果大家有比較好的資源歡迎相互交流，共同提高。同時有部分素材來源於網路，如侵，聯刪
。
