redis是單線程，線程安全

redis可以能夠快速執行的原因：

(1) 絕大部分請求是純粹的內存操作（非常快速）
(2) 采用單線程,避免了不必要的上下文切換和競爭條件
(3) 非阻塞IO - IO多路復用

IO多路復用中有三種方式：select,poll,epoll。需要註意的是，select,poll是線程不安全的，epoll是線程安全的

redis內部實現采用epoll，采用了epoll+自己實現的簡單的事件框架。epoll中的讀、寫、關閉、連接都轉化成了事件，然後利用epoll的多路復用特性，絕不在io上浪費一點時間 這3個條件不是相互獨立的，特別是第一條，如果請求都是耗時的，采用單線程吞吐量及性能可想而知了。應該說redis為特殊的場景選擇了合適的技術方案。

IO多路復用（epoll）：

由於進程的執行過程是線性的(也就是順序執行),當我們調用低速系統I/O(read,write,accept等等),進程可能阻塞,此時進程就阻塞在這個調用上,不能執行其他操作.阻塞很正常.

接下來考慮這麽一個問題:一個服務器進程和一個客戶端進程通信,服務器端read(sockfd1,bud,bufsize),此時客戶端進程沒有發送數據,那麽read(阻塞調用)將阻塞，直到客戶端調用
write(sockfd,but,size)發來數據.在一個客戶和服務器通信時這沒什麽問題。

當多個客戶與服務器通信時當多個客戶與服務器通信時,若服務器阻塞於其中一個客戶sockfd1,當另一個客戶的數據到達套接字sockfd2時,服務器不能處理,仍然阻塞在read(sockfd1,...)上
;此時問題就出現了,不能及時處理另一個客戶的服務,咋麽辦
 
?

epoll詳解：

首先我們來定義流的概念，一個流可以是文件，socket，pipe等等可以進行I/O操作的內核對象。

不管是文件，還是套接字，還是管道，我們都可以把他們看作流。

之後我們來討論I/O的操作，通過read，我們可以從流中讀入數據；通過write，我們可以往流寫入數據。現在假定一個情形，我們需要從流中讀數據，但是流中還沒有數據，（典型的例子為，
客戶端要從socket讀如數據，但是服務器還沒有把數據傳回來），這時候該怎麽辦？

阻塞：阻塞是個什麽概念呢？比如某個時候你在等快遞，但是你不知道快遞什麽時候過來，而且你沒有別的事可以幹（或者說接下來的事要等快遞來了才能做）；那麽你可以去睡覺了，因為你知
道快遞把貨送來時一定會給你打個電話（假定一定能叫醒你）。

非阻塞忙輪詢：接著上面等快遞的例子，如果用忙輪詢的方法，那麽你需要知道快遞員的手機號，然後每分鐘給他掛個電話：“你到了沒？”

很明顯一般人不會用第二種做法，不僅顯很無腦，浪費話費不說，還占用了快遞員大量的時間。
大部分程序也不會用第二種做法，因為第一種方法經濟而簡單，經濟是指消耗很少的CPU時間，如果線程睡眠了，就掉出了系統的調度隊列，暫時不會去瓜分CPU寶貴的時間片了。

為了了解阻塞是如何進行的，我們來討論緩沖區，以及內核緩沖區，最終把I
 
/O事件解釋清楚。緩沖區的引入是為了減少頻繁I/O操作而引起頻繁的系統調用（你知道它很慢的），當你操作一個流時
，更多的是以緩沖區為單位進行操作，這是相對於用戶空間而言。對於內核來說，也需要緩沖區。

假設有一個管道，進程A為管道的寫入方，Ｂ為管道的讀出方。

假設一開始內核緩沖區是空的，B作為讀出方，被阻塞著。然後首先A往管道寫入，這時候內核緩沖區由空的狀態變到非空狀態，內核就會產生一個事件告訴Ｂ該醒來了，這個事件姑且稱之為“緩沖區
非空”。

但是“緩沖區非空”事件通知B後，B卻還沒有讀出數據；且內核許諾了不能把寫入管道中的數據丟掉這個時候，Ａ寫入的數據會滯留在內核緩沖區中，如果內核也緩沖區滿了，B仍未開始讀數據，最終
內核緩沖區會被填滿，這個時候會產生一個I/O事件，告訴進程A，你該等等（阻塞）了，我們把這個事件定義為“緩沖區滿”。

假設後來Ｂ終於開始讀數據了，於是內核的緩沖區空了出來，這時候內核會告訴A，內核緩沖區有空位了，你可以從長眠中醒來了，繼續寫數據了，我們把這個事件叫做“緩沖區非滿”

也許事件Y1已經通知了A，但是A也沒有數據寫入了，而Ｂ繼續讀出數據，知道內核緩沖區空了。這個時候內核就告訴B，你需要阻塞了！，我們把這個時間定為“緩沖區空”。

這四個情形涵蓋了四個I/O事件，緩沖區滿，緩沖區空，緩沖區非空，緩沖區非滿（註都是說的內核緩沖區，且這四個術語都是我生造的，僅為解釋其原理而造）。這四個I/O事件是進行阻塞同步的
根本。（如果不能理解“同步”是什麽概念，請學習操作系統的鎖，信號量，條件變量等任務同步方面的相關知識）。

然後我們來說說阻塞I/O的缺點。但是阻塞I/O模式下，一個線程只能處理一個流的I/O事件。如果想要同時處理多個流，要麽多進程(fork)，要麽多線程(pthread_create)，很不幸這兩種方法
效率都不高。

於是再來考慮非阻塞忙輪詢的I/O方式，我們發現我們可以同時處理多個流了（把一個流從阻塞模式切換到非阻塞模式再此不予討論）：
while true {
for i in stream[]; {
if i has data
read until unavailable
}
}
    
我們只要不停的把所有流從頭到尾問一遍，又從頭開始。這樣就可以處理多個流了，但這樣的做法顯然不好，因為如果所有的流都沒有數據，那麽只會白白浪費CPU。這裏要補充一點，阻塞模式下，
內核對於I/O事件的處理是阻塞或者喚醒，而非阻塞模式下則把I/O事件交給其他對象（後文介紹的select以及epoll）處理甚至直接忽略。

為了避免CPU空轉，可以引進了一個代理（一開始有一位叫做select的代理，後來又有一位叫做poll的代理，不過兩者的本質是一樣的）。這個代理比較厲害，可以同時觀察許多流的I/O事件，
在空閑的時候，會把當前線程阻塞掉，當有一個或多個流有I/O事件時，就從阻塞態中醒來，於是我們的程序就會輪詢一遍所有的流（於是我們可以把“忙”字去掉了）。代碼長這樣:
while true {
select(streams[])
for i in streams[] {
if i has data
read until unavailable
}
}
   
於是，如果沒有I/O事件產生，我們的程序就會阻塞在select處。但是依然有個問題，我們從select那裏僅僅知道了，有I/O事件發生了，但卻並不知道是那幾個流（可能有一個，多個，甚至全部
），我們只能無差別輪詢所有流，找出能讀出數據，或者寫入數據的流，對他們進行操作。

但是使用select，我們有O(n)的無差別輪詢復雜度，同時處理的流越多，沒一次無差別輪詢時間就越長。

epoll可以理解為event poll，不同於忙輪詢和無差別輪詢，epoll之會把哪個流發生了怎樣的I/O事件通知我們。此時我們對這些流的操作都是有意義的。（復雜度降低到了O(1)）

在討論epoll的實現細節之前，先把epoll的相關操作列出：

epoll_create 創建一個epoll對象，一般epollfd = epoll_create()

epoll_ctl （epoll_add/epoll_del的合體），往epoll對象中增加/刪除某一個流的某一個事件
比如
epoll_ctl(epollfd, EPOLL_CTL_ADD, socket, EPOLLIN);//註冊緩沖區非空事件，即有數據流入
epoll_ctl(epollfd, EPOLL_CTL_DEL, socket, EPOLLOUT);//註冊緩沖區非滿事件，即流可以被寫入
epoll_wait(epollfd,...)等待直到註冊的事件發生
（註：當對一個非阻塞流的讀寫發生緩沖區滿或緩沖區空，write/read會返回-1，並設置errno=EAGAIN。而epoll只關心緩沖區非滿和緩沖區非空事件）。

一個epoll模式的代碼大概的樣子是：
while true {
active_stream[] = epoll_wait(epollfd)
for i in active_stream[] {
read or write till
}
}

Redis關於線程安全問題：

redis實際上是采用了線程封閉的觀念，把任務封閉在一個線程，自然避免了線程安全問題，不過對於需要依賴多個redis操作的復合操作來說，依然需要鎖，而且有可能是分布式鎖。

Redis到底是多線程還是單線程？線程安全嗎