背景

例如，使用在一般Linux系統上執行的流水線Redis可以每秒傳送甚至一百萬個請求。

Redis已知是快速的，並且使用單執行緒。為什麼Redis並非旨在從多執行緒中受益？給出一個流行的答案：

易於程式設計

併發幫助（也稱為併發不是並行性）

CPU不是瓶頸

具有成本效益的部署

Redis是* kinda *單執行緒的，因為有些執行緒是為了在磁碟上執行某些慢速操作。到目前為止，執行緒操作非常關注I / O，以至於我們在另一個執行緒上執行非同步任務的小型庫稱為bio.c：基本上是後臺I / O。

Redis DEL操作通常處於阻塞狀態，因此，如果您傳送Redis“ DEL mykey”，並且您的金鑰恰好有5000萬個物件，則伺服器將阻塞數秒，而同時沒有任何服務。

Redis 4.0的第一個候選版本已經發布

非阻塞DEL和FLUSHALL / FLUSHDB

UNLINK不是DEL的預設行為。

Redis AFAIK中不會發生I / O執行緒化。

必須使用多執行緒磁碟儲存。多執行緒複雜的記憶體系統位於中間，使事情變得醜陋

相反，我真正想要的是*慢速操作執行緒，而使用Redis模組系統，我們已經朝著正確的方向發展。

雖然Redis被設計為“單”執行緒，並認為多執行緒可能沒有太大幫助。有些人建立了redis的一個分支（例如“ KeyDB”）並添加了多執行緒功能，以說服人們“ Redis應該是多執行緒的 ”。

redis的一個特點是讀寫速度快，這就很容易讓人誤以為redis是多執行緒的。因為大家想當然的會認為多執行緒的效率要比單執行緒高，其實不然。

BAT的一個對redis有很深瞭解的高階工程師曾經說過，redis就是如果所有資料都在記憶體裡，那麼單執行緒是效率最高的。為什麼這麼說呢，多執行緒的本質是CPU模擬出多個執行緒去操作，但是模擬是有代價的，學過作業系統的朋友應該知道，多執行緒之間切換是要切換上下文的，這也是對時間的一種消耗。所以，對於單處理器來說，當然是單執行緒，無切換才是最高效率的。redis就是用一塊CPU綁定了一塊記憶體，然後對資料的操作都是在這塊記憶體上進行的，基於此，單執行緒的redis已經達到了效率最大化。

我們用實際資料來說明。

一次CPU記憶體的切換大約需要1500ns，從記憶體中讀取1MB的資料，大概需要250us，就算我一次只讀1MB的資料，讀1000次之後，消耗在記憶體切換上這種非功能性過程上的消耗就達到了1500us，這個時間開銷任誰看都是不值。

此外，基於redis的單執行緒，我們還可以利用它提供的set key field value加nx引數的方式，來實現分散式鎖。眾所周知，redis並不適合做資料持久層，更多的是取代memcache做快取，做分散式架構的支撐。分散式架構勢必就要面臨如何實現分散式鎖的問題，透過上面的介面，無論多少個分散式節點，都可以準確的獲取分散式鎖。

具體使用方式如下：通常來說，set函式是不管field欄位是否存在，只要寫入成功就會返回1，但是如果增加了NX引數，那麼如果field值在redis中已經存在，就會返回空，否則才返回1。因此用這個函式來執行獲取分散式鎖操作，如果返回值不為空，則加鎖成功，否則代表有其他執行緒在操作資料，當前請求需要等待。

此外，還有PX，XX引數，具體含義見如下文件。