redis线程模型:
网络模块+命令处理
redis的性能:
一个取决于物理内存,另一个是对于socket请求的处理速度。
4.0以前
单线程模式
请求流程:对于一个请求,线程会根据操作产生相应的事件(读,写事件),此时我们的程序对事件进行监听,监听到程序,交给文件事件分派器选择不同的处理器去处理,最后返回给socket
单线程能保证高性能
- 内存存储:Redis使用内存作为数据存储介质,避免了磁盘I/O操作的瓶颈,这使得数据访问速度非常快。
- 单线程模型:Redis通过单线程模型简化了内部逻辑,避免了多线程中频繁的上下文切换开销。
- 事件驱动机制:由“事件”驱动运行的,事件状态对象、事件源、事件监听器。
产生问题:
- 在当时redis单线程模型的处理速度很快,完全可以应对上亿的请求,但是redis在处理del bigkey时出现处理时间过长问题,这导致出现redis出现阻塞情况,性能变差,所以在4.0版本redis进行了部分改动。
4.0版本(伪多线程模式)
主线程(1个)+后台线程(3个)
解决策略:
后台线程(3)个:
close_file:关闭AOF,RDB过程中产生的大文件
aof_fsync:将追加至AOF的文件数据刷盘
lazy_free:惰性释放大对象(bigkey)
此时redis的思想是将专门的事交给专业的线程去做,对于耗时较长的操作都分别开启了对应的线程去进行处理。
惰性删除(lazy_free):只有当我们访问到该key时发现过期,才会对他进行删除
AOF:redis持久化存储,将所有的写操作存储到AOF文件当中,可以在关闭服务器之后还原之前的状态
RDB:对任意时刻的redis中所有的数据生成快照保存的硬盘中,可手动和自动,适合灾难性恢复。
6.0版本
在4.0版本处理了命令操作的问题,但是网络传输的发展,业务的扩展,请求数不断增长,但是对于redis来说,处理socket请求的线程只有一个(aeMain),想要提升处理速度,就需要开启多线程模式了。
多线程+后台线程
开启语句:io-thread-do-read yes
实现:采用epoll 机制实现 IO 多路复用
当客户端有数据发送至服务端时,Select 会监听到可读事件,数据读取完毕后提交到业务线程池中并发处理。
一般的请求中,耗时最长的一般是业务处理,所以用一个线程池(worker 线程池)来处理业务操作,在性能上的提升也是非常可观的。
在Reactor多线程模型中,业务逻辑通常指的是接受和处理客户端请求之后的操作,比如数据的查询、加工以及持久化等。
接收到socket请求后,我们采用eaMain()主线程对已经就绪的事件进行轮询,对于这一步,采用的是epoll机制,记录 「要监听的文件描述符」 和 「已经就绪的文件描述符」,「已就绪的文件描述符」是由内核主动添加至就绪文件描述符集合中,我们从用户态调用 epoll_wait 就直接查询该集合是否有就绪 I/O 事件,这样下来,就减少了全遍历所有文件描述符的操作。
网络I/O多线程处理:Redis 6.0版本中,网络数据的读写这类耗时操作采用多线程执行,这样可以充分利用服务器的多核CPU资源。
命令执行仍为单线程:尽管网络I/O是多线程处理的,但Redis中执行用户命令的核心环节仍然是单线程的,这样避免了多线程环境下可能出现的数据竞态问题。
对于已经就绪的事件,通过io多路复用程序将任务分发给不同的事件处理器进行处理,如果是读写请求,就将读写的响应通过 socket 响应给客户端。
总结:6.0版本,redis采用的是多线程+后台线程的方式,对于socket请求,我们采用eaMain主线程轮询socket操作产生的事件,事件产生被io多路复用处理后交给分别交给不同线程进行后续操作,比如查询等,除此之外还开启线程对处理速度较慢的事件单独开启后台线程。
使用:
- 通常情况下,redis多线程是关闭的,4核以上推荐开启
- 4核——2,3线程
- 8核——6线程
- 线程数不是越多越好,通常建议线程数小于核数