标签：主线 Redis redis 如何 高性能 线程 内存 CPU 客户端

Redis到底有多快？

redis到底有多快，可以通过 redis-benchmark 脚本进行基准测试。redis官方的性能基准测试报告 

Redis为什么这么快？

redis之所以这么快，其实是一个综合性的结果。而能够支持其高性能的主要有以下几个点：

• 基于内存

  redis的数据都保存在内存中，在接收到命令之后可以在微秒的时间单位内获取到数据，并返回给客户端。实际上在说微秒时间内获取到数据指的是请求已经到达服务端，仅仅是指命令的解析与处理可以在微秒的时间范围内完成，所以这里并不包括网络传输时间。因此，实际上在业务使用redis获取数据时，自己打日志发现redis的命令耗时更多的是毫秒范围时间，这主要是因为建立连接以及数据在网络传输占用了大部分时间。

• 多路复用的IO模型

　　redis在网络层使用了基于epoll的NIO模型解决了高并发的问题。IO模型的基本理论知识

• 丰富的数据结构

　　redis为了快速的根据key找到value，所以提供了一个全局的hash表来哭诉的获取到对应的value。

　　redis中的value其实有8种数据类型，但是比较常用的其实是5种（string、list、hash、set、sorted set | int、bit、[]int）。

对应每一种数据类型，redis的底层实现会根据当前的数据来选择不用的数据结构来进行优化，保证一些常用的操作可以在O(1)的时间内完成，但是实际上一些范围操作只能保证在O(N)以内。

• 单线程执行

　　redis中在获取到所有客户端发来的命令请求后，都是由一个线程来完成网络IO(协议解析)和键值对的读写，避免了在多线程下并发访问共享资源所带来的的一系列开销。

Redis的性能瓶颈常发生于哪些地方？

　　既然redis执行命令是单线程执行，那么很容易想到如果当执行命令的线程(主线程)，被阻塞了或是执行耗时，那么在该命令之后的所有命令都必须等待当前的命令执行完成之后才会被执行。所以通常来说，redis的性能瓶颈会发生在以下几个地方：

　　1.大key的操作：无论是读或写，涉及到大key就必然意味着内存和性能的消耗都是较大的；

　　2.使用了复杂度较高的命令：只要是非O(1)，其他如O(N)甚至O(logN)的操作[SORT/SUNION/ZUNIONSTORE]只要N足够大，依然会耗费大量的CPU计算时间，尤其是当宿主机有其他服务在抢资源的时候，延时更为严重；

　　3.大量的key集中过期：key的过期处理也是由主线程执行，所以大量的key过期时，必然导致主线程在执行过期处理完成之前，无法响应客户端的命令；

　　4.内存淘汰机制：内存淘汰也是由主线程自己处理的，当redis的内存被耗尽之后，会根据配置的算法【一般是lru或lfu】进行淘汰一定的key。这种情况下自然也会导致主线程无法快速响应客户端；

　　5.AOF的always刷盘机制：always的刷盘机制，也是有主线程完成的，由于是对磁盘的写操作，必然会对主线程产生一定的影响；

　　6.fork操作：fork操作是操作系统提供的一个内核API，redis在执行RDB或AOF重写时，会fork一个子线程去完成，并且使用CopyOnWrite的机制节约内存。但是fork出一个子线程的时候需要拷贝一个线程所必要的数据结构以及页表（虚拟内存与物理内存的映射）这个操作主线程必然是阻塞的。相对来说线程的数据结构是相对固定的，但是页表是和实例的大小相关的，实例内存越大，拷贝的页表的耗时也自然更大，延时自然更长；

　　7.redis所在实例cpu负载过高：负载过高必然导致cpu的争用，当redis的主线程抢占不到cpu执行权时，就只能自我阻塞；此外有一点需要注意的是，如果将redis的主线程与CPU进行核绑时，在fork操作时，fork出的子线程会继承父线程的核绑特性，子线程会与父线程争用同一个CPU；

　　8.redis的并发过高：虽然redis采用的是epoll的非阻塞IO，但本质上仍然是同步IO，读写客户端的数据只能采用单线程的机制，无法利用CPU的多核；此外，当并发过高，网卡的带宽被占光时，在客户端看来主线程也是被阻塞住了，这种场景通常发生在实例所在的服务器有其他服务消耗了大量的带宽，这种情况下只能将某些服务放到其他地方。另一种极端的情况是redis单机的实例的并发就将网卡打爆了，这种情况一般发生在机器硬件的差距上【CPU和内存都强悍，就是网卡差(可能是老机器遗留)】,这种情况可以选择换硬件、亦或是对redis进行水平拓展，如：哨兵、集群分片。

　　总的来说其实无非就是三个点：1.主线程等待CPU的执行、2.主线程执行单个命令耗时或是等待某个资源耗时，导致后续的命令被阻塞、3.主线程能处理，但是数据传输拉胯，导致客户端的请求进来慢或响应客户端的数据出去慢。但是CPU不够的情况下是相对少见【因为也就一个主线程可能在不间断的执行，而其他线程都是间歇性执行】，更多的是内存和网络IO上的瓶颈。

标签：主线,Redis,redis,如何,高性能,线程,内存,CPU,客户端
来源： https://www.cnblogs.com/zhenjungan/p/16492437.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。