2024-05-02
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 本文链接:https://www.skjava.com/mianshi/baodian/detail/1495011036

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 引入的多线程只⽤来处理处理网络数据的读写和协议解析,而数据读写依然采用由主线程来处理,主要原因大明哥认为有如下几个:

  1. 数据读写为纯内存操作,速度极快,不是性能瓶颈所在。
  2. 如果使用多线程来处理数据读写,则需要多线程的数据安全机制,使得模型变得更加复杂,难以维护。
  3. 多线程带来的资源竞争和上下文切换的消耗会得不偿失。
阅读全文