影响网站排名重要因素,ps制作网站首页教程,网站优化查询代码,wordpress hierarchical1.Redis6.0之前的版本真的是单线程吗#xff1f;
Redis在处理客户端的请求是#xff0c;包括获取(socket读)、解析、执行、内容返回(socket 写)等都有一个 顺序串行的主线程处理#xff0c;这就是所谓的单线程。但如果严格来讲并不是单线程#xff0c;除了主线…1.Redis6.0之前的版本真的是单线程吗
Redis在处理客户端的请求是包括获取(socket读)、解析、执行、内容返回(socket 写)等都有一个 顺序串行的主线程处理这就是所谓的单线程。但如果严格来讲并不是单线程除了主线程外它 也有后台线程在处理一些较为缓慢的操作例如清理脏数据、无用连接的释放、大key的删除等等
2.Redis6.0之前为什么一直不使用多线程?
官方曾做过类似问题的回复:使用Redis时几乎不存在CPU成为瓶颈的情况Redis主要受限于内存和网络。例如在一个普通的Linux系统上Redis通过使用pipelining每秒可以处理100w个请求所以如果 应用程序主要使用O(N)或O(log(N))的命令它几乎不会占用太多CPU. 使用了单线程后可维护性高。多线程模型虽然在某些方面表现优异但是它却引入了程序执行顺序的不确定性带来了并发读写的一系列问题增加了系统复杂度、同事还可能存在线程切换、甚至加锁解锁、 死锁造成的性能损耗。Redis通过AE事件模型以及IO多路复用等技术处理性能非常高因此没有必要使用多线程。单线程机制使得Redis内部实现的复杂度大大降低Hash的惰性、Rehash、Lpush等等线程不安全 的命令都可以无锁进行
3.Redis6.0为什么要引入多线程呢?
Redis将所有数据放在内存中内存的响应时长大约为100纳秒对于小数据包Redis服务器可以处理8w~10w QPS这也是Redis处理的极限了对于80%的公司来说单线程的Redis已经足够使用了。但随着越来越复杂的业务场景有些公司动不动就上亿的交易量因此需要更大的QPS。常见的解决方案是在分布式架构中对数据进行分区并采用多个服务器 但该方案有非常大的缺点例如要管理的Redis服务器太多维护代价大某些适用于单个Redis服务器的命令不适用于数据 分区数据分区无法解决热点读/写问题数据倾斜重新分配和放大/缩小变得更加复杂等等。
从Redis自身角度来说因为读/写网络的read/write系统调用占用了Redis执行期间大部分CPU时间瓶颈主要在于网络的IO消耗优化主要有两个方向:
1.提高网络IO性能,典型的实现比如使用DPDK来替代内核网络栈的方式2.使用多线程充分利用多核典型的实现比如Memcached协议栈优化的这种方式跟Redis关系不大支持多线程是一种最有效最便捷的操作方式所以总结起来Redis支持多线程就是两个原因:1.可以充分利用服务器的CPU资源目前主线程只能利用一个核2.多线程任务可以分摊Redis同步IO读写负荷
4.Redis6.0默认是否开启了多线程?
Redis6.0的多线程默认是禁用的只使用主线程。如需开启需要修改redis.conf配置文件
io-threads 4io-threads-do-reads no开启多线程后还需要设置线程数否则是不生效的。关于线程数的设置官方有一个建议: 4核的机器建议设置为2或3个线程 8核的建议设置6个线程线程数一定要小于机器核数因为Redis还有预留出其他线程做后台任务 比如备份、删除过期键等操作还需要注意的是线程数并不是越大越好官方认为超过了8个基本就没什么意义了因为主线程命令执行会存在一个瓶颈点如果达到瓶颈即便IO线程设置得再多也是空转
5.Redis6.0采用多线程后性能的提升效果如何?
Redis作者antirez在RedisConf2019分享时曾提到:Redis6引入的多线程IO特性对性能提升 至少是一倍以上。国内也有大牛曾使用unstable版本在阿里云ESC进行过测试GET/SET命令 在4线程IO时性能相比单线程是几乎翻倍了。如果开启多线程至少要4核的机器且Redis实例 已经占用相当大的CPU的耗时的时候才建议使用否则使用多线程没有意义
6.Redis60多线程的实现机制? 流程简述:
1.主线程负责接收建立连接请求获取socket放入全局等待读处理队列2.主线程处理完读事件之后通过RR(Round Robin)将这些连接分配给这些IO线程3.主线程阻塞等待IO线程读取socket完毕4.主线程通过单线程的方式执行请求命令请求数据读取并解析完成但并不执行回写socket5.主线程阻塞等待IO线程将数据回写socket完毕6.解除绑定清空等待队列
该设计有如下特定:
1.IO线程要么同时在读socket要么同时在写不会同时读或写2.IO线程只负责读写socket解析命令不负责命令处理
7.开启多线程后是否会存在线程并发安全问题?
Redis的多线程部分只是用来处理网络数据的读写和协议解析执行命令仍然是单线程顺序执行。 所以我们不需要去考虑控制key、lua、事务LPUSH/LPOP等等的并发及线程安全问题
8.Redis6.0的多线程和Memcached多线程模型进行对比
Memcached服务器采用master-worker模式进行工作。服务端采用socket与客户端通讯。主线程、工作线程采用pipe管道进行通讯。主线程采用libevent监听listen、accept的读事件事件响应后将连接信息的数据结构封装起来根据算法选择合适的工作线程将连接任务携带 连接信息分发出去响应的线程利用连接描述符建立与客户端的socket连接并进行后续的存取数据操作
相同点:都采用了master线程-worket线程的模型不同点:Memcached执行主逻辑也是在worker线程里模型更加简单实现了真正的线程隔离符合我们对线程隔离的常规理解。而Redis吧处理逻辑交还给master线程虽然一定程度上增加了模型复杂度但也解决了线程并发安全等问题
