Redis到底快在哪裏

Redis是一種基於鍵值對(Key-Value)的NoSQL數據庫,Redis的Value能夠由String,hash,list,set,zset,Bitmaps,HyperLogLog等多種數據結構和算法組成。Redis還提供了鍵過時,發佈訂閱,事務,Lua腳本,哨兵,Cluster等功能。Redis執行命令的速度很是快,根據官方給的性能能夠達到10w+qps。那麼本文主要介紹到底Redis快在哪裏,主要有如下幾點:python

一.開發語言算法

如今咱們都用高級語言來編程,好比Java、python等。也許你會以爲C語言很古老,可是它真的頗有用,畢竟unix系統就是用C實現的,因此C語言是很是貼近操做系統的語言。Redis就是用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複用機制socket

在這以前先要說一下傳統的阻塞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的時候纔會阻塞,收發客戶消息是不會阻塞的。

note:想要擡頭,先學會低頭;

相關文章
相關標籤/搜索