echo編輯整理,歡迎轉載,轉載請聲明文章來源。歡迎添加echo微信(微信號:t2421499075)交流學習。 百戰不敗,依不自稱常勝,百敗不頹,依能奮力前行。——這纔是真正的堪稱強大!!!html
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) |
Set | insert | O(1) |
Set | select | 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資源,主要的瓶頸在於內存。可是單線程爲何可以作到這麼快的速度的呢?併發
從上面官網的介紹咱們看到了,Redis的瓶頸不在線程,不在獲取CPU的資源,因此若是使用多線程就會帶來多餘的資源佔用。好比上下文切換、資源競爭、鎖的操做。異步
對於I/O阻塞可能有不少人不知道,I/O操做的阻塞究竟是怎麼引發的,Redis又是怎麼解決的呢?函數
作一個有底線的博客主
原文出處:https://www.cnblogs.com/xlecho/p/11832118.html