Redis是单线程为什么还那么快？

Redis为什么还那么快

1. 基于内存
     Redis完全基于内存，绝大部分请求是纯粹的内存操作，Redis将数据存储在内存中，读写数据的时候不会受到硬盘I/O速度的限制（内存速度为什么比硬盘快？），类似于HashMap（HashMap的优势就是查找和操作的时间复杂度都是O（1））。

2. 单线程
     Redis采用单线程的模型，确保每个操作的原子性，避免不必要的上下文切换和竞争条件，自然也就不存在多进程或者多线程导致的切换而消耗CPU，也不用去考虑各种锁的问题，不存在加解锁的操作，所以没有可能出现死锁导致的性能消耗

3. 使用多路复用
     Redis采用网络IO多路复用技术来保证多链接的时候系统的高吞吐量。可以让单个线程高效的处理多个链接请求，减少网络IO时间消耗。主要是利用了select、poll、epoll可以同时监察多了IO时间的能力，一次顺序的处理就绪的IO事件避免了大量的无用的操作，从而提高效率。

4. 自己的事件分离器

     redis使用自己实现的事件分离器，效率比较高，内部采用非阻塞的执行方式，吞吐量能力比较大

5. 灵活多变的数据结构
     redis内部使用一个redisObject对象来表示所有的key和calue。redisObject主要的信息包括数据类型、编码方式、数据指针、虚拟内存等。主要包含string、Hash、List、Set、Sorted Set物种数据类型，针对不同的场景使用对应的数据类型，减少内存使用的同时，节省网络流量的传输

Redis为什么是单线程?为什么不用多线程？

  首先需要明确的一点就是单线程指的是网络请求模块使用了一个线程，所以不需要考虑并发安全性，其他科模块也会用到多线程，在使用redis的过程中充分的发挥其优势，避免一些不当操作导致性能的下降。说redis是单线程只是在4.0版本之前，在4.0之后的版本中就加入了多线程的支持。Redis从一开始就使用单线程模型处理来自客户端的网络请求，其实原因是多方面的，重要的有三个：高可维护性、单线程也可以处理并发请求、性能瓶颈不是CPU

1. 可维护性
   多线程模型虽然在某些方面变现优异，但是他的执行顺序是不确定的，代码的执行过程不再是串行的，并且多个线程同时访问的变量如果没有谨慎处理可能最后的结果会是不正确的
2. 并发处理
   使用单线程并不代表不能并发处理任务，Redis虽然使用的是单线程模型处理用户的请求，但他确实用I/O多路复用机制并发处理客户端的多个链接。使用I/O多路复用技术能够极大的减少系统的开销，系统不在需要额外创建和维护进程和线程来监听客户端的大量链接，减少了服务器开发和维护的成本。
3. 性能瓶颈
   性能瓶颈是Redis选择单线程模型的决定性原因。多线程技术确实能够帮助我们充分的利用CPU的计算资源来并发的执行任务，但是CPU资源并不是Redis服务器的性能瓶颈。即使实在一个普通的linux中启动Redis服务，也可以达到百万QPS。

总结

  Redis并不是CPU密集型的服务，如果不持久化，所有的Redis数据都只会在内存中完成，并不会涉及到任何的I/O操作，所以处理速度是非常快的。Redis的瓶颈是在于网络传输带来的延迟和等待客户端的数据传输（网络I/O），所以使用多线程模型来处理全部的外部请求并不是一个很好的选择。

  多线程虽然可以充分的利用CPU资源，但是在操作系统上的切换也会带来额外的开销，比如所加载和执行线程的上下文，频繁的对线程上下文进行切换还会导致性能的急剧下降，可能会导致我们的优化进行倒退，这也是为什么Redis对于使用多线程技术的非常谨慎的原因。

  Redis在4.0后的版本中引入了多线程，加入了一些可以被其他线程异步处理的删除操作（UNLINK、FLUSHALL ASYNC 和 FLUSHDB ASYNC）。在Redis中使用DEL命令删除键对应的值，如果键占用的空间比较小，同步删除并不会太耗时，但是针对一些超大的键值对，比如几十或者几百MB的数据并不能很快的处理完，就会消耗较多的时间，会影响到Redis服务处理请求的速度和可用性。其实这个释放内存的工作可以交给后台的多线程进行异步的处理，这就是UNLINK命令，他只是将键从元数据中删除，其真正的删除是在后台异步进行。

  说了这么多，Redis选择使用单线程模型处理客户端的请求还是因为CPU不是Redis服务器的瓶颈，所以使用多线程模型可能会起到相反的效果，其主要的瓶颈是在网络I/O上。Redis引入多线程主要是针对一些大的键值对的删除操作，在后台异步进行空间的释放，减少对Redis主线程的阻塞，提高执行效率。