redis6.0多线程源码剖析

1、概述

redis6.0 新增了 多线程机制。一直存在两个疑问：

 

1)、 为什么要加入多线程

2)、多线程机制，为什么不设计成跟memcache 一样

 

2、解析

 

首先第一个问题，redis 区别于memcache 的一点是，redis是单线程。但是性能也很好，主要得益于他的 IO多路复用，还有单线程省了多线程切换上下文的开销。线程上下文切换，可能会造成CPU CACHE MISS， CPU的一级缓存和三级缓存的 速度不是一个量级的。这次redis6.0 开启了IO多线程的机制，主要是考虑，redis的读写网络的read/write系统调用，在redis执行期间占用了大量的CPU时间。如果把网络IO做成多线程会提升很大性能。另一方面，如果是比较耗时的操作（比如lrange，del 大key），避免阻塞主线程太多时间，开线线程异步处理 不失为一个好的选择。

 

第二个问题，redis选择多线程模型的时候，为什么不选择跟memcache一样的？redis的作者Antirez 曾经说过：

 

Redis 支持多线程有 2 种可行的方式：

第一种就是像“Memcached”那样，一个 Redis 实例开启多个线程，从而提升GET/SET等简单命令中每秒可以执行的操作。这涉及到 I/O、命令解析等多线程处理，因此，我们将其称之为“I/O threading”。

另一种就是允许在不同的线程中执行较耗时较慢的命令，以确保其它客户端不被阻塞，我们将这种线程模型称为“Slow commands threading”。

经过深思熟虑，Redis 不会采用“I/O threading”，Redis 在运行时主要受制于网络和内存，所以提升 Redis 性能主要是通过在多个 Redis 实例，特别是 Redis 集群。

接下来我们主要会考虑改进两个方面：

• Redis 集群的多个实例通过编排能够合理地使用本地实例的磁盘，避免同时重写 AOF。

• 提供一个 Redis 集群代理，便于用户在没有较好的集群协议客户端时抽象出一个集群。

补充说明一下，Redis 和 Memcached 一样是一个内存系统，但不同于 Memcached。

多线程是复杂的，必须考虑使用简单的数据模型，执行 LPUSH 的线程需要服务其他执行 LPOP 的线程。

我真正期望的实际是“slow operations threading”，在 Redis 6 或 Redis 7 中，将提供“key-level locking”，使得线程可以完全获得对键的控制以处理缓慢的操作

 

简单的说就是，redis目前性能还是受限于网络和内存。所以采用多线程来处理网络IO读写和解析，执行命令依然是交给主线程来做。多线程的并发控制又是复杂的（比如事