Redis的性能瓶颈

转载自：https://www.cnblogs.com/qwangxiao/p/8535202.html

1.首先Redis为什么这么快？

1.基于内存，不会受到硬盘IO速度的限制

2.单线程，避免了多线程切换导致的CPU消耗,也不用考虑锁的问题,不存在加锁释放锁的操作，也不存在因死锁而导致的性能消耗

3.使用多路I/O复用模型，非阻塞IO

　多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。

这里的多路指的是多个请求，复用指的是复用同一个线程，采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis 在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈，主要由以上几点造就了 Redis 具有很高的吞吐量

2.Redis为什么是单线程？

因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了（毕竟采用多线程会有很多麻烦）。

也就是说，因为单线程实现及维护的成本低，加上单线程的性能已经非常高，所以就没用多线程。

注意这里的单线程，只是在处理我们的网络请求时只有一个线程来处理，Redis Server在运行时肯定不止一个线程，比如在持久化时会以子线程的方式执行

 

Redis的瓶颈：

1.机器内存大小，因为redis的数据放在内存里，所以存放数据量的多少取决于内存的多少

2.网络带宽

Redis客户端执行一条命令分为如下四个过程：

1）发送命令

2）命令排队

3）命令执行

4）返回结果

其中1）+4）称为Round Trip Time（RTT，往返时间）。

Redis的客户端和服务端可能部署在不同的机器上。例如客户端在北京，Redis服务端在上海，两地直线距离约为1300公里，那么1次RTT时间=1300×2/（300000×2/3）=13毫秒（光在真空中传输速度为每秒30万公里，这里假设光纤为光速的2/3），那么客户端在1秒内大约只能执行80次左右的命令，这个和Redis的高并发高吞吐特性背道而驰

所以要么就在全国各地都有自己的Redis服务器，然后就近访问，要么就使用Pipeline

Pipeline（流水线）机制能改善上面这类问题，它能将一组Redis命令进行组装，通过一次RTT传输给Redis，再将这组Redis命令的执行结果按顺序192返回给客户端，下图为没有使用Pipeline执行了n条命令，整个过程需要n次RTT

没有Pipeline执行n次命令模型

Pipeline并不是什么新的技术或机制，很多技术上都使用过。而且RTT在不同网络环境下会有不同，例如同机房和同机器会比较快，跨机房跨地区会比较慢。Redis命令真正执行的时间通常在微秒级别，所以才会有Redis性能瓶颈是网络这样的说法。

但大部分开发人员更倾向于使用高级语言客户端中的Pipeline，目前大部分Redis客户端都支持Pipeline