为什么单线程Redis性能也很出色

高性能的服务器,不一定是多线程实现的,也就是说多线程不一定比单线程效率高,这得分具体的情况。以redis为例,核心处理请求的线程只有一个,所以我们常常理解其仅仅只有一个线程,但准确来说其实并不是单线程的,比如日志的备份需要单独的fork一个进程或者线程去做备份等,那么redis何来单线程还能达到如此10万+的qps呢?其实这取决于具体的实现,redis采用了基于高性能Reactor的IO多路复用的模式+内存数据结构+单线程处理网络请求这几块,决定了其性能高的原因。

我们知道操作系统的主要资源有CPU,内存,磁盘,带宽,而对存储介质访问速度肯定是CPU缓存>内存>磁盘。

引用阿里大神沈询说的一段话:

redis 核心就是 如果我的数据全都在内存里,我单线程的去操作 就是效率最高的,为什么呢,因为多线程的本质就是 CPU 模拟出来多个线程的情况,这种模拟出来的情况就有一个代价,就是上下文的切换,对于一个内存的系统来说,它没有上下文的切换就是效率最高的。redis 用 单个进程或者线程 绑定一块CPU,从而最大化提升该进程访问特定CPU缓存的速度,然后针对这块Cache内存的数据进行多次读写的时候,都是在一个CPU上完成的,所以它是单线程处理这个事。在内存的情况下,这个方案就是最佳方案 。

那么什么时候事务需要用到多线程呢?这个问题的本质取决于下层所使用的存储,如果是内存操作,则可以动态地申请和销毁内存块;而磁盘的IOPS很低,但吞吐量很高。如果一个场景涉及多次读写操作,单线程可以很高的效率对于内存进行读写操作;但是,由于磁盘的IOPS仅为内存的几千分之一,如果依旧用操作内存的方式操作磁盘,那系统的整体性能将会很低,这意味着必须将大量的读写操作聚合成一个Batch后再提交时才能达到较好的性能。而将大量请求攒到一起的方式一是异步,也就是请求本身和线程不绑定,线程可以不Block(本质来说还是一种多线程的方式),处理完一个线程后再处理其他线程。这种做法的核心是将大量不同的请求提交到一个Buffer中,再由该Buffer统一读取或者写入磁盘,从而提高效率。在慢速设备中,多线程或异步非常常见,在设计系统时,面对磁盘、网络、SSD等慢速设备必须考虑使用多线程。

方法就是用异步:将请求和处理的线程不绑定,请求的线程将请求放在一个buff里,然后等buff快满了,处理的线程再去处理这个buff。然后由这个buff 统一的去写入磁盘,或者读磁盘,这样效率就是最高。 java里的NIO, 大名鼎鼎的netty 就是这么干的,对于慢速存储设备磁盘,网络,SSD,这种处理方式异步+多线程+写缓冲区buffer就是最佳的。

其实原理的东西就这么些,本身其实都是操作系统相关的东西,并不复杂

为何单线程绑定一个cpu效率最高,CPU 是一个重要的影响因素,由于是单线程模型,Redis 更喜欢大缓存快速 CPU(主频高), 而不是多核,在多核 CPU 服务器上面,Redis 的性能还依赖 NUMA 配置和 处理器绑定位置。 最明显的影响是 redis-benchmark 会随机使用 CPU 内核。为了获得精准的结果,需要使用固定处理器工具(在 Linux 上可以使用 taskset)。 最有效的办法是将客户端和服务端分离到两个不同的 CPU 来高校使用三级缓存。

(1)redis作为单进程模型的程序,为了充分利用多核CPU,常常在一台server上会启动多个实例。而为了减少切换的开销,有必要为每个实例指定其所运行的CPU。

(2) Linux 上 taskset 可以将某个进程绑定到一个特定的CPU。你比操作系统更了解自己的程序,为了避免调度器愚蠢的调度你的程序,或是为了在多线程程序中避免缓存失效造成的开销。

总结一下,redis单线程性能出色的必要条件:

(1)以内存为主要存储结构,这是快的前提

(2)高性能的基于epoll的IO多路复用模式

(3)单进程/单线程直接绑定CPU,避免OS无用调度和上下文切换

原文发布于微信公众号 - 我是攻城师(woshigcs)

原文发表时间:2019-01-18

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券