Redis效能解析 Redis為什麼那麼快？

redis的實際被應用都是因為它的效能，在眾多快取中redis也是乙個比較快的中介軟體，而且它是單執行緒操作，沒有過的記憶體開銷，給程式帶來了更多的擴充套件空間。

在保證網路通暢的情況下，相同的cpu和相同的redis版本，處理不同大小的資料，redis的吞吐量如下圖所示，該圖來自redis的官方**。我們可以在**中看到。redis在處理1000位元組的資料的時候，都是穩定位置吞吐量在10w，當處理的資料不斷增大的時候，吞吐量才慢慢開始下降。

來自redis官網

下圖是提供的qps測試圖，官方提供的資料是可以達到100000+的qps（每秒內查詢次數）。

來自redis官網

我們從上面的介紹裡面我們看到了redis是乙個純kv的操作。並且redis絕大部分請求是純粹的記憶體操作，所以速度非常快。資料存在記憶體中，型別與存在hashmap中，那麼為什麼那麼快呢？我們可以一起來看一下幾種常用資料結構的對比，和他們的優勢。

資料結構

操作時間複雜度

list

insert

o(n)

list

select

o(1)

setinsert

o(1)

setselect

o(1)

hashmap

insert

o(1)

hashmap

select

o(1)

從上圖我們可以看出，hashmap的優勢就是查詢和操作的時間複雜度都是o（1）,所以redis內部採用這種結構能夠從根本上獲得足夠的優勢，當讓，redis的快速不僅僅是資料結構成就的，還有單程成和非同步i/o

redis使用單執行緒就夠了！我們可以看到下圖中官網的描述，redis的使用瓶頸並不是cpu，它主要受到記憶體和網路的限制。例如，使用在一般linux系統上執行的流水線redis每秒可以傳送一百萬個請求，因此，如果您的應用程式主要使用o（n）或o（log（n））命令，則幾乎不會使用過多的cpu 。

從描述中我們可以看到，redis在使用的時候，使用單執行緒就已經能夠獲取redis足夠使用的cpu資源，主要的瓶頸在於記憶體。但是單執行緒為什麼能夠做到這麼快的速度的呢？

競爭資源

鎖的消耗

對於i/o阻塞可能有很多人不知道，i/o操作的阻塞到底是怎麼引起的，redis又是怎麼解決的呢？

做乙個有底線的部落格主