Redis6.0多线程设计分析

在6.0版本发布之前，只要有人问我们Redis是单线程还是多线程的？我们都可以理直气壮的说Redis是单线程的，但是直到6.0发布后，关于Redis单线程与多线程这一话题就变的更为复杂了。

在我上篇文章说介绍过Redis为什么要设计成单线程？并且阐明了多线程的弊端，那么为什么实际上从4.0开始Redis设计团队就已经使Redis更加多线程化了呢？

为什么要设计多线程？

上篇文章中已经介绍过了，Redis为什么要设计成单线程的，已经为什么不设计多线程，那么本文再来看看为什么Redis6.0又设计成多线程了呢？

首先说明尽管我们知道Redis6.0发布多线程版本，但要明确一点，这里多线程指的是IO多线程，Redis主线程也就是执行命令的线程实际上依然是单线程的。

Redis是纯内存操作，在单线程下其QPS最高可以达到10W左右，虽然这对于绝大多数用户而言已经绰绰有余，但是随着互联网的快速发展，对于那些动不动就上亿级流量的大厂，10W的QPS就显得捉襟见肘，往往需要借助多态Redis服务器搭建集群才能满足其业务需求，但是服务器太多，维护成本就会变高，并且集群也很难解决热点key、数据偏移、单机Redis命令（比如MGET/MSET）的一些操作等问题。

另外对于一些读写IO较慢的情况下，使用IO多线程可以轻松实现较为可观的改善，而不需要用例如pipelining，多实例等方式。

如何开启多线程？

Redis6.0默认是多线程可是关闭的，如需开启需要修改redis.conf配置文件。

使用多线程注意事项

我们从配置中的说明就可以看出大概有以下几种情况使用建议：

• 如果读写IO不是性能瓶颈，那么不建议你开启多线程。
• 建议服务器至少要有4核以上才有意义，并且至少留下一个备用核。
• 建议线程数要比核心数少一点，比如4核，建议开启2、3个线程，8核，建议开启6个线程。
• 千万不要认为线程数设置的越多越好，官方说明超过8个线程不可能会获得太大的帮助。

Redis多线程处理流程

由原来的6个时间单位，优化到了4个时间单位。

基本思想就是把多个读请求分配给多个IO线程去解析，主线程不停的轮询检查所有IO线程解析是否完成，如果完成那么按照串行的方式执行命令，命令执行完之后再把所有回写的请求交给IO线程去处理。

由于执行命令的过程依然是串行的，所以不会造成线程不安全的问题。