為什么Redis是單線程的
1.官方答案
因為Redis是基於內存的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機器內存的大小或者網絡帶寬。既然單線程容易實現，而且CPU不會成為瓶頸，那就順理成章地采用單線程的方案了。
IO多路復用技術
redis 采用網絡IO多路復用技術來保證在多連接的時候， 系統的高吞吐量。
多路-指的是多個socket連接，復用-指的是復用一個線程。多路復用主要有三種技術：select，poll，epoll。epoll是最新的也是目前最好的多路復用技術。
這里“多路”指的是多個網絡連接，“復用”指的是復用同一個線程。采用多路
I/O
復用技術可以讓單個線程高效的處理多個連接請求（盡量減少網絡IO的時間消耗），且Redis在內存中操作數據的速度非常快（內存內的操作不會成為這里的性能瓶頸），主要以上兩點造就了Redis具有很高的吞吐量。
epoll有諸多優點：
1. epoll 沒有最大並發連接的限制，上限是最大可以打開文件的數目，這個數字一般遠大於 2048, 一般來說這個數目和系統內存關系很大 ，具體數目可以 cat /proc/sys/fs/file-max 察看。
2. 效率提升， Epoll 最大的優點就在於它只管你“活躍”的連接 ，而跟連接總數無關，因此在實際的網絡環境中， Epoll 的效率就會遠遠高於 select 和 poll 。
3. 內存拷貝， Epoll 在這點上使用了“共享內存 ”，這個內存拷貝也省略了。
epoll IO多路復用模型實現機制
由於epoll的實現機制與select/poll機制完全不同，上面所說的 select的缺點在epoll上不復存在。
epoll沒有這個限制，它所支持的FD上限是最大可以打開文件的數目，這個數字一般遠大於2048,舉個例子,在1GB內存的機器上大約是10萬左右
設想一下如下場景：有100萬個客戶端同時與一個服務器進程保持着TCP連接。而每一時刻，通常只有幾百上千個TCP連接是活躍的(事實上大部分場景都是這種情況)。如何實現這樣的高並發？
在select/poll時代，服務器進程每次都把這100萬個連接告訴操作系統(從用戶態復制句柄數據結構到內核態)，讓操作系統內核去查詢這些套接字上是否有事件發生，輪詢完后，再將句柄數據復制到用戶態，讓服務器應用程序輪詢處理已發生的網絡事件，這一過程資源消耗較大，因此，select/poll一般只能處理幾千的並發連接。
如果沒有I/O事件產生，我們的程序就會阻塞在select處。但是依然有個問題，我們從select那里僅僅知道了，有I/O事件發生了，但卻並不知道是那幾個流（可能有一個，多個，甚至全部），我們只能無差別輪詢所有流，找出能讀出數據，或者寫入數據的流，對他們進行操作。
但是使用select，我們有O(n)的無差別輪詢復雜度，同時處理的流越多，每一次無差別輪詢時間就越長
epoll的設計和實現與select完全不同。epoll通過在Linux內核中申請一個簡易的文件系統(文件系統一般用什么數據結構實現？B+樹)。把原先的select/poll調用分成了3個部分：
1）調用epoll_create()建立一個epoll對象(在epoll文件系統中為這個句柄對象分配資源)
2）調用epoll_ctl向epoll對象中添加這100萬個連接的套接字
3）調用epoll_wait收集發生的事件的連接
如此一來，要實現上面說是的場景，只需要在進程啟動時建立一個epoll對象，然后在需要的時候向這個epoll對象中添加或者刪除連接。同時，epoll_wait的效率也非常高，因為調用epoll_wait時，並沒有一股腦的向操作系統復制這100萬個連接的句柄數據，內核也不需要去遍歷全部的連接。
epoll與select/poll的區別
select，poll，epoll都是IO多路復用的機制。I/O多路復用就通過一種機制，可以監視多個描述符，一旦某個描述符就緒，能夠通知程序進行相應的操作。
select的本質是采用32個整數的32位，即32*32= 1024來標識，fd值為1-1024。當fd的值超過1024限制時，就必須修改FD_SETSIZE的大小。這個時候就可以標識32*max值范圍的fd。
poll與select不同，通過一個pollfd數組向內核傳遞需要關注的事件，故沒有描述符個數的限制，pollfd中的events字段和revents分別用於標示關注的事件和發生的事件，故pollfd數組只需要被初始化一次。
epoll還是poll的一種優化，返回后不需要對所有的fd進行遍歷，在內核中維持了fd的列表。select和poll是將這個內核列表維持在用戶態，然后傳遞到內核中。與poll/select不同，epoll不再是一個單獨的系統調用，而是由epoll_create/epoll_ctl/epoll_wait三個系統調用組成，后面將會看到這樣做的好處。epoll在2.6以后的內核才支持。
select/poll的幾大缺點：
1、每次調用select/poll，都需要把fd集合從用戶態拷貝到內核態，這個開銷在fd很多時會很大
2、同時每次調用select/poll都需要在內核遍歷傳遞進來的所有fd，這個開銷在fd很多時也很大
3、針對select支持的文件描述符數量太小了，默認是1024
4.select返回的是含有整個句柄的數組，應用程序需要遍歷整個數組才能發現哪些句柄發生了事件；
5.select的觸發方式是水平觸發，應用程序如果沒有完成對一個已經就緒的文件描述符進行IO操作，那么之后每次select調用還是會將這些文件描述符通知進程。
相比select模型，poll使用鏈表保存文件描述符，因此沒有了監視文件數量的限制，但其他三個缺點依然存在。
原文：https://blog.csdn.net/wxy941011/article/details/80274233
Redis高並發快總結
1. Redis是純內存數據庫，一般都是簡單的存取操作，線程占用的時間很多，時間的花費主要集中在IO上，所以讀取速度快。
2. 再說一下IO，Redis使用的是非阻塞IO，IO多路復用，使用了單線程來輪詢描述符，將數據庫的開、關、讀、寫都轉換成了事件，減少了線程切換時上下文的切換和競爭。
3. Redis采用了單線程的模型，保證了每個操作的原子性，也減少了線程的上下文切換和競爭。
4. 另外，數據結構也幫了不少忙，Redis全程使用hash結構，讀取速度快，還有一些特殊的數據結構，對數據存儲進行了優化，如壓縮表，對短數據進行壓縮存儲，再如，跳表，使用有序的數據結構加快讀取的速度。
5. 還有一點，Redis采用自己實現的事件分離器，效率比較高，內部采用非阻塞的執行方式，吞吐能力比較大。