大家好，我是大明哥，一个专注「死磕 Java」系列创作的硬核程序员。
回答
Redis 的性能瓶颈从来都不是 CPU，是网络I/O 和内存。
内存好解决，加机器内存和优化数据结构。
网路 I/O 的优化才是大头，因为读写网络的 read/write 系统调用占用了Redis执行期间大部分CPU时间，如果能够将这部分多线程化，则会大大提高 Redis 的性能。
故而，Redis 6.0 引入 I/O 多线程模型，但是它只对网络的部分采用了多线程，数据的读写依然是单线程。
总结就是：将主线程 IO 读写任务拆分出来给一组独立的线程处理，使得多个 socket 读写可以并行化，但是 Redis 命令还是主线程串行执行。
扩展
根据测算，Redis 将所有数据放在内存中，内存的响应时长大约为 100 纳秒，对于小数据包，Redis 服务器可以处理 80,000 到 100,000 QPS，这么高的对于 80% 的公司来说，单线程的 Redis 已经足够使用了。
但是，随着越来越复杂的业务场景，有些公司动不动就上亿的交易量，因此需要更大的 QPS。经过分析 Redis 的性能瓶颈主要体现在网络 IO 的处理上。所以 Redis 引入多线程来优化网络 I/O 的处理。
客户端发送一条请求给 Redis 后，Redis 的处理过程分为四个步骤：读取请求、解析请求、数据读写、响应写回，在 Redis 6.0 之前这个过程统一由主线程处理，Redis 6.0 多线程后，处理过程如下：
所以，Redis 6.0 引入的多线程只⽤来处理处理网络数据的读写和协议解析，而数据读写依然采用由主线程来处理，主要原因大明哥认为有如下几个：
- 数据读写为纯内存操作，速度极快，不是性能瓶颈所在。
- 如果使用多线程来处理数据读写，则需要多线程的数据安全机制，使得模型变得更加复杂，难以维护。
- 多线程带来的资源竞争和上下文切换的消耗会得不偿失。
本文已收录到我的技术网站：https://www.skjava.com。有全网最优质的系列文章、Java 全栈技术文档以及大厂完整面经
