共計(jì) 1839 個(gè)字符，預(yù)計(jì)需要花費(fèi) 5 分鐘才能閱讀完成。
這篇文章給大家分享的是有關(guān) Redis 速度為什么快的內(nèi)容。丸趣 TV 小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨丸趣 TV 小編過來看看吧。
Redis 是一種基于鍵值對(duì) (Key-Value) 的 NoSQL 數(shù)據(jù)庫(kù)，Redis 的 Value 可以由 String，hash，list，set，zset，Bitmaps，HyperLogLog 等多種數(shù)據(jù)結(jié)構(gòu)和算法組成。Redis 還提供了鍵過期，發(fā)布訂閱，事務(wù)，Lua 腳本，哨兵，Cluster 等功能。
Redis 執(zhí)行命令的速度非常快，根據(jù)官方給的性能可以達(dá)到 10w+qps。那么本文主要介紹到底 Redis 快在哪里，主要有以下幾點(diǎn)：
一、開發(fā)語言
現(xiàn)在我們都用高級(jí)語言來編程，比如 Java、python 等。也許你會(huì)覺得 C 語言很古老，但是它真的很有用，畢竟 unix 系統(tǒng)就是用 C 實(shí)現(xiàn)的，所以 C 語言是非常貼近操作系統(tǒng)的語言。Redis 就是用 C 語言開發(fā)的，所以執(zhí)行會(huì)比較快。
另外多說一句，大學(xué)生們好好學(xué) C，會(huì)讓你更好的理解計(jì)算機(jī)操作系統(tǒng)。別覺得學(xué)了高級(jí)語言就可以不用關(guān)注底層，欠的債總歸要還的。此處推薦一本比較難啃的書《深入理解計(jì)算系統(tǒng)》。
二、純內(nèi)存訪問
Redis 將所有數(shù)據(jù)放在內(nèi)存中，非數(shù)據(jù)同步正常工作中，是不需要從磁盤讀取數(shù)據(jù)的，0 次 IO。內(nèi)存響應(yīng)時(shí)間大約為 100 納秒，這是 Redis 速度快的重要基礎(chǔ)。先看看 CPU 的速度：
拿我的電腦來說，主頻是 3.1G，也就是說每秒可以執(zhí)行 3.1*10^9 個(gè)指令。所以說 CPU 看世界是非常非常慢的，內(nèi)存比它慢百倍，磁盤比他慢百萬倍，你說快不快？
借了一張《深入理解計(jì)算機(jī)系統(tǒng)》的圖，展示了一個(gè)典型的存儲(chǔ)器層次結(jié)構(gòu)，在 L0 層，CPU 可以在一個(gè)時(shí)鐘周期訪問到，基于 SRAM 的高速緩存春續(xù)期，可以在幾個(gè) CPU 時(shí)鐘周期訪問到，然后是基于 DRAM 的主存，可以在幾十到幾百個(gè)時(shí)鐘周期訪問到他們。
三、單線程
第一，單線程簡(jiǎn)化算法的實(shí)現(xiàn)，并發(fā)的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)不但困難且測(cè)試也麻煩。第二，單線程避免了線程切換以及加鎖釋放鎖帶來的消耗，對(duì)于服務(wù)端開發(fā)來說，鎖和線程切換通常是性能殺手。當(dāng)然了，單線程也會(huì)有它的缺點(diǎn)，也是 Redis 的噩夢(mèng)：阻塞。如果執(zhí)行一個(gè)命令過長(zhǎng)，那么會(huì)造成其他命令的阻塞，對(duì)于 Redis 是十分致命的，所以 Redis 是面向快速執(zhí)行場(chǎng)景的數(shù)據(jù)庫(kù)。
除了 Redis 之外，Node.js 也是單線程，Nginx 也是單線程，但他們都是服務(wù)器高性能的典范。
四、非阻塞多路 I / O 復(fù)用機(jī)制
在這之前先要說一下傳統(tǒng)的阻塞 I / O 是如何工作的：當(dāng)使用 read 或者 write 對(duì)某一文件描述符（File Descriptor FD）進(jìn)行讀寫的時(shí)候，如果數(shù)據(jù)沒有收到，那么該線程會(huì)被掛起，直到收到數(shù)據(jù)。
阻塞模型雖然易于理解，但是在需要處理多個(gè)客戶端任務(wù)的時(shí)候，不會(huì)使用阻塞模型。
I/ O 多路復(fù)用實(shí)際上是指多個(gè)連接的管理可以在同一進(jìn)程。多路是指網(wǎng)絡(luò)連接，復(fù)用只是同一個(gè)線程。在網(wǎng)絡(luò)服務(wù)中，I/ O 多路復(fù)用起的作用是一次性把多個(gè)連接的事件通知業(yè)務(wù)代碼處理，處理的方式由業(yè)務(wù)代碼來決定。
在 I / O 多路復(fù)用模型中，最重要的函數(shù)調(diào)用就是 I /O 多路復(fù)用函數(shù)，該方法能同時(shí)監(jiān)控多個(gè)文件描述符（fd）的讀寫情況，當(dāng)其中的某些 fd 可讀 / 寫時(shí)，該方法就會(huì)返回可讀 / 寫的 fd 個(gè)數(shù)。
Redis 使用 epoll 作為 I / O 多路復(fù)用技術(shù)的實(shí)現(xiàn)，再加上 Redis 自身的事件處理模型將 epoll 的 read、write、close 等都轉(zhuǎn)換成事件，不在網(wǎng)絡(luò) I / O 上浪費(fèi)過多的時(shí)間。實(shí)現(xiàn)對(duì)多個(gè) FD 讀寫的監(jiān)控，提高性能。
舉個(gè)形象的例子吧。比如一個(gè) tcp 服務(wù)器處理 20 個(gè)客戶端 socket。
A 方案：順序處理，如果第一個(gè) socket 因?yàn)榫W(wǎng)卡讀數(shù)據(jù)處理慢了，一阻塞后面都玩蛋去。
B 方案：每個(gè) socket 請(qǐng)求都創(chuàng)建一個(gè)分身子進(jìn)程來處理，不說每個(gè)進(jìn)程消耗大量系統(tǒng)資源，光是進(jìn)程切換就夠操作系統(tǒng)累的了。
C 方案（I/ O 復(fù)用模型，epoll）：將用戶 socket 對(duì)應(yīng)的 fd 注冊(cè)進(jìn) epoll（實(shí)際上服務(wù)器和操作系統(tǒng)之間傳遞的不是 socket 的 fd 而是 fd_set 的數(shù)據(jù)結(jié)構(gòu)），然后 epoll 只告訴哪些需要讀 / 寫的 socket，只需要處理那些活躍的、有變化的 socket fd 的就好了。
這樣，整個(gè)過程只在調(diào)用 epoll 的時(shí)候才會(huì)阻塞，收發(fā)客戶消息是不會(huì)阻塞的。
感謝各位的閱讀！關(guān)于“Redis 速度為什么快”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！
