歡迎光臨
每天分享高質量文章

四個大點,搞懂 Redis 到底快在哪裡?

  • 前言
  • 一. 開發語言
  • 二. 純記憶體訪問
  • 三. 單執行緒
  • 四. 非阻塞多路I/O復用機制

前言

Redis是一種基於鍵值對(Key-Value)的NoSQL資料庫,Redis的Value可以由String,hash,list,set,zset,Bitmaps,HyperLogLog等多種資料結構和演演算法組成。Redis還提供了鍵過期,釋出訂閱,事務,Lua指令碼,哨兵,Cluster等功能。Redis執行命令的速度非常快,根據官方給的效能可以達到10w+qps。那麼本文主要介紹到底Redis快在哪裡,主要有以下幾點:

一. 開發語言

現在我們都用高階語言來程式設計,比如Java、python等。也許你會覺得C語言很古老,但是它真的很有用,畢竟unix系統就是用C實現的,所以C語言是非常貼近作業系統的語言。Redis就是用C語言開發的,所以執行會比較快。

另外多說一句,大學生們好好學C,會讓你更好的理解計算機作業系統。別覺得學了高階語言就可以不用關註底層,欠的債總歸要還的。此處推薦一本比較難啃的書《深入理解計算系統》。

二. 純記憶體訪問

Redis將所有資料放在記憶體中,非資料同步正常工作中,是不需要從磁碟讀取資料的,0次IO。記憶體響應時間大約為100納秒,這是Redis速度快的重要基礎。先看看CPU的速度:

拿我的電腦來說,主頻是3.1G,也就是說每秒可以執行3.1*10^9個指令。所以說CPU看世界是非常非常慢的,記憶體比它慢百倍,磁碟比他慢百萬倍,你說快不快?

借了一張《深入理解計算機系統》的圖,展示了一個典型的儲存器層次結構,在L0層,CPU可以在一個時鐘週期訪問到,基於SRAM的高速快取春續期,可以在幾個CPU時鐘週期訪問到,然後是基於DRAM的主存,可以在幾十到幾百個時鐘週期訪問到他們。

三. 單執行緒

第一,單執行緒簡化演演算法的實現,併發的資料結構實現不但困難且測試也麻煩。第二,單執行緒避免了執行緒切換以及加鎖釋放鎖帶來的消耗,對於服務端開發來說,鎖和執行緒切換通常是效能殺手。當然了,單執行緒也會有它的缺點,也是Redis的噩夢:阻塞。如果執行一個命令過長,那麼會造成其他命令的阻塞,對於Redis是十分致命的,所以Redis是面向快速執行場景的資料庫。

除了Redis之外,Node.js也是單執行緒,Nginx也是單執行緒,但他們都是伺服器高效能的典範。

四. 非阻塞多路I/O復用機制

在這之前先要說一下傳統的阻塞I/O是如何工作的:當使用read或者write對某一檔案描述符(File Descriptor FD)進行讀寫的時候,如果資料沒有收到,那麼該執行緒會被掛起,直到收到資料。阻塞模型雖然易於理解,但是在需要處理多個客戶端任務的時候,不會使用阻塞模型。

I/O多路復用實際上是指多個連線的**管理可以在同一行程。**多路是指網路連線,復用只是同一個執行緒。在網路服務中,I/O多路復用起的作用是一次性把多個連線的事件通知業務程式碼處理,處理的方式由業務程式碼來決定。在I/O多路復用模型中,最重要的函式呼叫就是I/O 多路復用函式,該方法能同時監控多個檔案描述符(fd)的讀寫情況,當其中的某些fd可讀/寫時,該方法就會傳回可讀/寫的fd個數。

Redis使用epoll作為I/O多路復用技術的實現,再加上Redis自身的事件處理模型將epoll的read、write、close等都轉換成事件,不在網路I/O上浪費過多的時間。實現對多個FD讀寫的監控,提高效能。

舉個形象的例子吧。比如一個tcp伺服器處理20個客戶端socket。A方案:順序處理,如果第一個socket因為網絡卡讀資料處理慢了,一阻塞後面都玩蛋去。B方案:每個socket請求都建立一個分身子行程來處理,不說每個行程消耗大量系統資源,光是行程切換就夠作業系統累的了。C方案**(I/O復用模型,epoll):將使用者socket對應的fd註冊進epoll(實際上伺服器和作業系統之間傳遞的不是socket的fd而是fd_set的資料結構),然後epoll只告訴哪些需要讀/寫的socket,只需要處理那些活躍的、有變化的socket fd的就好了。這樣,整個過程只在呼叫epoll的時候才會阻塞,收發客戶訊息是不會阻塞的。

已同步到看一看
贊(1)

分享創造快樂