这篇文章主要介绍复述,6.0版本新特性有哪些,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!
6.0 <强>复述,稳定版本
0复述,稳定版本提供了很多新特性及功能改进,例如新网络协议RESP3,新的集群代理,ACL等。我想大家最关注的可能还是“多线”程,下面我们就来看看复述,6.0版本有哪些新特性吧。
<强> 1。Redis6.0之前的版本真的是单线程吗?
复述,在处理客户端的请求时,包括获取(套接字读),解析,执行,内容返回(套接字写)等都由一个顺序串行的主线程处理,这就是所谓的“单线程”。但如果严格来讲从Redis4.0之后并不是单线程,除了主线程外,它也有后台线程在处理一些较为缓慢的操作,例如清理脏数据,无用连接的释放,大关键的删除等等。
<强> 2。Redis6.0之前为什么一直不使用多线程?
官方曾做过类似问题的回复:使用复述时,几乎不存在CPU成为瓶颈的情况,复述,主要受限于内存和网络,例如在一个普通的Linux系统上,复述,通过使用流水线每秒可以处理100年万个请求,所以如果应用程序主要使用O (N)或O (log (N))的命,令它几乎不会占用太多CPU。
使用了单线程后,可维护性高。多线程模型虽然在某些方面表现优异,但是它却引入了程序执行顺序的不确定性,带来了并发读写的一系列问题,增加了系统复杂度,同时可能存在线程切换,甚至加锁解锁、死锁造成的性能损耗.Redis通过AE事件模型以及输入输出多路复用等技术,处理性能非常高,因此没有必要使用多线程。单线程机制使得复述,内部实现的复杂度大大降低,散列的惰性改变,Lpush等等“线程不安全”的命令都可以无锁进行。
<强> 3. Redis6.0为什么要引入多线程呢?
复述,将所有数据放在内存中,内存的响应时长大约为100纳秒,对于小数据包,复述,服务器可以处理80000到100000每秒,这也是复述,处理的极限了,对于80%的公司来说,单线程的复述,已经足够使用了。
但随着越来越复杂的业务场景,有些公司动不动就上亿的交易量,因此需要更大的每秒。常见的解决方案是在分布式架构中对数据进行分区并采用多个服务器,但该方案有非常大的缺点,例如要管理的复述,服务器太多,维护代价大;某些适用于单个复述,服务器的命令不适用于数据分区;数据分区无法解决热点读/写问题;数据偏斜,重新分配和放大/缩小变得更加复杂等等。
从复述,自身角度来说,因为读写网络的读/写系统调用占用了复述,执行期间大部分CPU时间,瓶颈主要在于网络的IO消耗,优化主要有两个方向:
?提高网络IO性能,典型的实现比如使用DPDK来替代内核网络栈的方式
?使用多线程充分利用多核,典型的实现比如Memcached。
协议栈优化的这种方式跟复述,关系不大,支持多线程是一种最有效最便捷的操作方式,所以总结起来,复述,支持多线程主要就是两个原因:
?可以充分利用服务器CPU资源,目前主线程只能利用一个核
?多线程任务可以分摊复述,同步IO读写负荷
<强> 4. Redis6.0默认是否开启了多线程?
Redis6.0的多线程默认是禁用的,只使用主线程。如需开启需要修改复述。参看配置文件:io-threads-do-reads是的
<强> 5. redis6.0多线程开启时,线程数如何设置?
开启多线程后,还需要设置线程数,否则是不生效的。同样修改复述。conf配置文件
关于线程数的设置，官方有一个建议：4核的机器建议设置为2或3个线程，8核的建议设置为6个线程，线程数一定要小于机器核数。还需要注意的是，线程数并不是越大越好，官方认为超过了8个基本就没什么意义了。
6.Redis6.0采用多线程后，性能的提升效果如何？
Redis 作者 antirez 在 RedisConf 2019分享时曾提到：Redis 6 引入的多线程 IO 特性对性能提升至少是一倍以上。国内也有大牛曾使用unstable版本在阿里云esc进行过测试，GET/SET 命令在4线程 IO时性能相比单线程是几乎是翻倍了。
测试环境：
Redis Server: 阿里云 Ubuntu 18.04，8 CPU 2.5 GHZ, 8G 内存，主机型号 ecs.ic5.2xlarge
Redis Benchmark Client: 阿里云 Ubuntu 18.04，8 2.5 GHZ CPU, 8G 内存，主机型号 ecs.ic5.2xlarge复述,6.0版本新特性有哪些
