點擊上方☝Java編程技術樂園，輕鬆關注！及時獲取有趣有料的技術文章
做一個積極的人
編碼、改bug、提升自己
我有一個樂園，面向編程，春暖花開！
知乎：redis為什麼是單線程？在多核處理器下對主存的訪問真的比多線程更有效率？未來有可能改用多線程嗎？
原文地址: https://www.zhihu.com/question/23162208/answer/142424042
單純的網絡IO來說，量大到一定程度之後，多線程的確有優勢——但並不是單純的多線程，而是每個線程自己有自己的epoll這樣的模型，也就是多線程和multiplexing混合。
一般這個開頭我們都會跟一個“但是”。但是。還要考慮Redis操作的對象。它操作的對象是內存中的數據結構。如果在多線程中操作，那就需要為這些對象加鎖。最終來說，多線程性能有提高，但是每個線程的效率嚴重下降了。而且程序的邏輯嚴重複雜化。要知道Redis的數據結構並不全是簡單的Key-Value，還有列表，hash，map等等複雜的結構，這些結構有可能會進行很細粒度的操作，比如在很長的列表後面添加一個元素，在hash當中添加或者刪除一個對象，等等。這些操作還可以合成MULTI/EXEC的組。這樣一個操作中可能就需要加非常多的鎖，導致的結果是同步開銷大大增加。這還帶來一個惡果就是吞吐量雖然增大，但是響應延遲可能會增加。
Redis在權衡之後的選擇是用單線程，突出自己功能的靈活性。在單線程基礎上任何原子操作都可以幾乎無代價地實現，多麼複雜的數據結構都可以輕鬆運用，甚至可以使用Lua腳本這樣的功能。
對於多線程來說這需要高得多的代價。並不是所有的KV數據庫或者內存數據庫都應該用單線程，比如ZooKeeper就是多線程的，最終還是看作者自己的意願和取捨。單線程的威力實際上非常強大，每核心效率也非常高，在今天的虛擬化環境當中可以充分利用雲化環境來提高資源利用率。
多線程自然是可以比單線程有更高的性能上限，但是在今天的計算環境中，即使是單機多線程的上限也往往不能滿足需要了，需要進一步摸索的是多服務器集群化的方案，這些方案中多線程的技術照樣是用不上的，所以單線程、多進程的集群不失為一個時髦的解決方案。——作者：靈劍
提這樣的問題，因為你有一些固化的思維，比如：
1. 認為高性能服務器=多線程
2. 覺得網絡服務器都是 http模型的。
3. 寫多了 HTTP，用多了 erlang 或者 go，以為世界上只有這一種模型。
你的問題在於沒有理清楚：http/go/erlang 這些網絡模型都是 “無狀態” 或者 “弱狀態” 的，每兩個鏈接之間沒有頻繁交互，或者頻繁訪問的中間資源。
比如兩個 HTTP請求，沒有任何聯繫，要有聯繫也是放到 redis/mysql之類的地方去。強狀態強交互的網絡服務，設計本身就不一樣。——作者：韋易笑
Redis 每秒可以跑兩百萬個請求，已經很強大了，網絡一般先成為瓶頸。但這並不代表我們所有的網絡服務器都像它一樣採用單線程。就像韋大神所說，得看應用場景，採用多線程得話是否容易編寫/維護（這也取決於看開發者能力）（像協程，Actor什麼的，並不能減少複雜度，如果彼此之間交互/通信多了，一樣的很複雜，而且效率可能還更低）——作者：Irons Du
持續推送Redis相關技術，歡迎關注~
閱讀更多 Java武學祕籍 的文章
