详解Redis单线程架构的优势与不足

2024-04-16 0 270
目录
  • 01 Redis中的多线程
  • 02 I/O多线程
  • 03 Redis中的多进程
    • 问题
  • 04 结论

    难道Redis不是单线程?我们启动一个Redis实例,验证一下就知道了。Redis安装部署方式如下所示:

    // 下载
    wget https://download.redis.io/redis-stable.tar.gz
    tar -xzvf redis-stable.tar.gz
    // 编译安装
    cd redis-stable
    make
    // 验证是否安装成功
    ./src/redis-server -v
    Redis server v=7.2.4

    接下来启动Redis实例,使用命令ps查看所有线程,如下所示:

    // 启动Redis实例
    ./src/redis-server ./redis.conf

    // 查看实例进程ID
    ps aux | grep redis
    root 385806 0.0 0.0 245472 11200 pts/2 Sl+ 17:32 0:00 ./src/redis-server 127.0.0.1:6379

    // 查看所有线程
    ps -L -p 385806
    PID LWP TTY TIME CMD
    385806 385806 pts/2 00:00:00 redis-server
    385806 385809 pts/2 00:00:00 bio_close_file
    385806 385810 pts/2 00:00:00 bio_aof
    385806 385811 pts/2 00:00:00 bio_lazy_free
    385806 385812 pts/2 00:00:00 jemalloc_bg_thd
    385806 385813 pts/2 00:00:00 jemalloc_bg_thd

    竟然有6个线程!不是说Redis是单线程吗?怎么会有这么多线程呢?

    这6个线程的含义你可能不太了解,但是通过这个示例至少说明Redis并不是单线程。

    01 Redis中的多线程

    接下来我们逐个介绍上述6个线程的作用:

    redis-server:

    主线程,用于接收并处理客户端请求。

    jemalloc_bg_thd

    jemalloc 是新一代的内存分配器,Redis底层使用他管理内存。

    bio_xxx:

    以bio前缀开始的都是异步线程,用于异步执行一些耗时任务。其中,线程bio_close_file用于异步删除文件,线程bio_aof用于异步将AOF文件刷到磁盘,线程bio_lazy_free用于异步删除数据(懒删除)。

    需要说明的是,主线程是通过队列将任务分发给异步线程的,并且这一操作是需要加锁的。主线程与异步线程的关系如下图所示:

    详解Redis单线程架构的优势与不足

    • 主线程与异步线程这里我们以懒删除为例,讲解为什么要使用异步线程。Redis是一款内存数据库,支持多种数据类型,包括字符串、列表、哈希表、集合等。思考一下,删除(DEL)列表类型数据的流程是怎样的呢?第一步从数据库字典中删除该键值对,第二步遍历并删除列表中的所有元素(释放内存)。想想如果列表中的元素数目非常多呢?这一步将非常耗时。这种删除方式称为同步删除,流程如下图所示:

    详解Redis单线程架构的优势与不足

    • 同步删除流程图针对上述问题,Redis提出了懒删除(异步删除),主线程在收到删除命令(UNLINK)时,首先从数据库字典中删除该键值对,随后再将删除任务分发给异步线程bio_lazy_free,由异步线程执行第二步耗时逻辑。这时候的流程如下图所示:

    详解Redis单线程架构的优势与不足

    • 懒删除流程图

    02 I/O多线程

    难道Redis是多线程?那为什么我们老说Redis是单线程呢?这是因为读取客户端命令请求,执行命令以及向客户端返回结果都是在主线程完成的。不然的话,多线程同时操作内存数据库,并发问题如何解决?如果每次操作之前都加锁,那和单线程又有什么区别呢?

    当然这一流程在Redis6.0版本也发生了改变,Redis官方指出,Redis是基于内存的键值对数据库,执行命令的过程是非常快的,读取客户端命令请求和向客户端返回结果(即网络I/O)通常会成为Redis的性能瓶颈。

    因此,在Redis 6.0版本,作者加入了多线程I/O的能力,即可以开启多个I/O线程,并行读取客户端命令请求,并行向客户端返回结果。I/O多线程能力使得Redis性能提升至少一倍。

    为了开启多线程I/O能力,需要先修改配置文件redis.conf:

    io-threads-do-reads yes
    io-threads 4

    这两个配置含义如下:

    io-threads-do-reads:是否开启多线程I/O能力,默认为"no";

    io-threads:I/O线程数目,默认为1,即只使用主线程执行网络I/O,线程数最大为128;该配置应该根据CPU核数设置,作者建议,4核CPU设置2~3个I/O线程,8核CPU设置6个I/O线程。

    开启多线程I/O能力之后,重新启动Redis实例,查看所有线程,结果如下:

    ps -L -p 104648
    PID LWP TTY TIME CMD
    104648 104648 pts/1 00:00:00 redis-server
    104648 104654 pts/1 00:00:00 io_thd_1
    104648 104655 pts/1 00:00:00 io_thd_2
    104648 104656 pts/1 00:00:00 io_thd_3
    ……

    由于我们设置了io-threads等于4,所以会创建4个线程用于执行I/O操作(包括主线程),上述结果符合预期。

    当然,只有I/O阶段才使用了多线程,处理命令请求还是单线程,毕竟多线程操作内存数据存在并发问题。

    最后,开启了I/O多线程之后,命令的执行流程如下图所示:

    详解Redis单线程架构的优势与不足

    • I/O多线程流程图

    03 Redis中的多进程

    Redis还有多进程?是的。在某些场景下,Redis也会创建多个子进程来执行一些任务。以持久化为例,Redis支持两种类型的持久化:

    • AOF(Append Only File):可以看作是命令的日志文件,Redis会将每一个写命令都追加到AOF文件。
    • RDB(Redis Database):以快照的方式存储Redis内存中的数据。命令SAVE用于手动触发RDB持久化。想想如果Redis中的数据量非常大,持久化操作必然耗时比较长,而Redis是单线程处理命令请求,那么当命令SAVE的执行时间过长时,必然会影响其他命令的执行。

    命令SAVE有可能会阻塞其他请求,为此,Redis又引入了命令BGSAVE,该命令会创建一个子进程来执行持久化操作,这样就不会影响主进程执行其他请求了。

    我们可以手动执行命令BGSAVE验证。首先,使用GDB跟踪Redis进程,添加断点,让子进程阻塞在持久化逻辑。如下所示:

    // 查询Redis进程ID
    ps aux | grep redis
    root 448144 0.1 0.0 270060 11520 pts/1 tl+ 17:00 0:00 ./src/redis-server 127.0.0.1:6379

    // GDB跟踪进程
    gdb -p 448144

    // 跟踪创建的子进程(默认GDB只跟踪主进程,需手动设置)
    (gdb) set follow-fork-mode child
    // 函数rdbSaveDb用于持久化数据快照
    (gdb) b rdbSaveDb
    Breakpoint 1 at 0x541a10: file rdb.c, line 1300.
    (gdb) c
    设置好断点之后,使用Redis客户端发送命令BGSAVE,结果如下:

    // 请求立即返回
    127.0.0.1:6379> bgsave
    Background saving started

    // GDB输出以下信息
    [New process 452541]
    Breakpoint 1, rdbSaveDb (…) at rdb.c:1300
    可以看到,GDB目前跟踪的是子进程,进程ID是452541。也可以通过Linux命令 ps 查看所有进程,结果如下:

    ps aux | grep redis
    root 448144 0.0 0.0 270060 11520 pts/1 Sl+ 17:00 0:00 ./src/redis-server 127.0.0.1:6379
    root 452541 0.0 0.0 270064 11412 pts/1 t+ 17:19 0:00 redis-rdb-bgsave 127.0.0.1:6379

    可以看到子进程的名称是redis-rdb-bgsave,也就是该进程将所有数据的快照持久化在RDB文件。

    问题

    问题1:为什么采用子进程而不是子线程呢?

    因为RDB是将数据快照持久化存储,如果采用子线程,主线程与子线程将会共享内存数据,主线程在持久化的同时还会修改内存数据,这有可能导致数据不一致。而主进程与子进程的内存数据是完全隔离的,不存在此问题。

    问题2:假设Redis内存中存储了10GB的数据,在创建子进程执行持久化操作之后,此时子进程也需要10GB的内存吗?复制10GB的内存数据,也会比较耗时吧?另外如果系统只有15GB的内存,还能执行BGSAVE命令吗?

    这里有一个概念叫写时复制(copy on write),在使用系统调用fork创建子进程之后,主进程与子进程的内存数据暂时还是共享的,但是当主进程需要修改内存数据时,系统会自动将该内存块复制一份,以此实现内存数据的隔离。

    详解Redis单线程架构的优势与不足

    04 结论

    Redis的进程模型/线程模型还是比较复杂的,这里也只是简单介绍了部分场景下的多线程以及多进程,其他场景下的多线程、多进程还有待读者自己研究。

    以上就是详解Redis单线程架构的优势与不足的详细内容,更多关于Redis单线程架构的资料请关注悠久资源其它相关文章!

    收藏 (0) 打赏

    感谢您的支持,我会继续努力的!

    打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
    点赞 (0)

    悠久资源 Redis 详解Redis单线程架构的优势与不足 https://www.u-9.cn/database/redis/186198.html

    常见问题

    相关文章

    发表评论
    暂无评论
    官方客服团队

    为您解决烦忧 - 24小时在线 专业服务