目录
通常对于一个数据库来说，CPU通常不是瓶颈，因为大多数请求都不是CPU密集型的，而是IO密集型的，具体到Redis的话，如果不考虑RDB/AOF持久化方案，Redis是完全的内存操作，执行速度是非常快的，因此这部分操作通常不会是性能瓶颈，Redis真正的性能瓶颈在于网络IO，也就是就是客户端和服务端之间的网络延迟，而为了减少延迟，Redis选择了单线程的IO多路复用实现它的核心网络模型
具体来说：
1. 避免过多的上下文切换，如果是单线程则规避了进程内频繁的线程切换开销。因为程序始终运行在进程的单个线程内，没有多线程切换场景
2. 避免同步锁的开销 如果说Redis选择多线程模型，因为Redis是一个数据库，势必涉及到底层数据同步的问题，必然会引入某些同步机制。比如锁，而且我们知道 Redis不仅提供了key - value数据结构，而且还有list、set、hash等结构。不同的数据结构对同步访问的加锁粒度是不同的。可能会导致在操作数据的过程中会带来很多加锁解锁上面的开销。增加程序复杂度的同时还会降低性能
3. 简单可维护：如果说Redis使用多线程模式，那么底层所有的数据结构都必须设计为线程安全的，这无疑会使得Redis的实现变得更为复杂
主体核心来说是单线程的 就是执行命令仍然是单线程的
但是有两个节点需要注意是多线程的：
redis4.0：引入多线程处理异步任务
主要就是针对那些非常耗时的命令，将这些命令异步话，防止阻塞
redis6.0：在核心网络模型中引入了多线程IO
但是这个主要是为了处理网络数据的读写和协议的解析，执行命令仍然是单线程
随着互联网的高速发展，互联网业务系统要处理的线上流量越来越大，这样的话Redis的IO瓶颈会越来越大，Redis的单线程模型会导致系统消耗很多的CPU时间在网络IO上面，从而降低了吞吐量
要提升Redis的性能有两个方向：
1. 优化网络模型
2. 提高机器内存读写速度
后者依赖于硬件，暂时无解。只能从前者入手：网络IO的优化可以分为两个方向：
1. 零拷贝或者DPDK技术
2. 利用多核优势
零拷贝技术有其局限性，无法适配Redis这一复杂的网络IO场景。
而DPDK技术通过旁路网卡IO绕过内核协议栈太过于复杂可能还需要内核甚至是硬件的支持
总结来说，Redis支持多线程就两个原因：
1、充分利用CPU资源
2. 分摊Redis 同步IO读写负担
Redis作者说这个性能至少提升一倍
国内也有大牛测试过性能几乎翻倍了