Redis將所有數據放在內存中，內存的響應時長大約為100納秒，對于小數據包，Redis服務器可以處理80,000到100,000 QPS，這也是Redis處理的極限了，對于80%的公司來說，單線程的Redis已經足夠使用了。
但隨著越來越復雜的業務場景，有些公司動不動就上億的交易量，因此需要更大的QPS。常見的解決方案是在分布式架構中對數據進行分區并采用多個服務器，但該方案有非常大的缺點，例如要管理的Redis服務器太多，維護代價大;某些適用于單個Redis服務器的命令不適用于數據分區;數據分區無法解決熱點讀/寫問題;數據偏斜，重新分配和放大/縮小變得更加復雜等等。
從Redis自身角度來說，因為讀寫網絡的read/write系統調用占用了Redis執行期間大部分CPU時間，瓶頸主要在于網絡的 IO 消耗, 優化主要有兩個方向:
提高網絡 IO 性能，典型的實現比如使用 DPDK 來替代內核網絡棧的方式
使用多線程充分利用多核，典型的實現比如 Memcached
協議棧優化的這種方式跟 Redis 關系不大，支持多線程是一種最有效最便捷的操作方式。所以總結起來，redis支持多線程主要就是兩個原因：
可以充分利用服務器 CPU 資源，目前主線程只能利用一個核
多線程任務可以分攤 Redis 同步 IO 讀寫負荷
京公網安備 11010802030320號