Redis將所有數(shù)據(jù)放在內(nèi)存中，內(nèi)存的響應時長大約為100納秒，對于小數(shù)據(jù)包，Redis服務器可以處理80,000到100,000 QPS，這也是Redis處理的極限了，對于80%的公司來說，單線程的Redis已經(jīng)足夠使用了。

　　但隨著越來越復雜的業(yè)務場景，有些公司動不動就上億的交易量，因此需要更大的QPS。常見的解決方案是在分布式架構中對數(shù)據(jù)進行分區(qū)并采用多個服務器，但該方案有非常大的缺點，例如要管理的Redis服務器太多，維護代價大;某些適用于單個Redis服務器的命令不適用于數(shù)據(jù)分區(qū);數(shù)據(jù)分區(qū)無法解決熱點讀/寫問題;數(shù)據(jù)偏斜，重新分配和放大/縮小變得更加復雜等等。

　　從Redis自身角度來說，因為讀寫網(wǎng)絡的read/write系統(tǒng)調(diào)用占用了Redis執(zhí)行期間大部分CPU時間，瓶頸主要在于網(wǎng)絡的 IO 消耗, 優(yōu)化主要有兩個方向:

　　提高網(wǎng)絡 IO 性能，典型的實現(xiàn)比如使用 DPDK 來替代內(nèi)核網(wǎng)絡棧的方式

　　使用多線程充分利用多核，典型的實現(xiàn)比如 Memcached

　　協(xié)議棧優(yōu)化的這種方式跟 Redis 關系不大，支持多線程是一種最有效最便捷的操作方式。所以總結(jié)起來，redis支持多線程主要就是兩個原因：

　　可以充分利用服務器 CPU 資源，目前主線程只能利用一個核

　　多線程任務可以分攤 Redis 同步 IO 讀寫負荷