Performance Test | understand why Redis single-threaded so fast?

Introduction
  Redis NoSQL is a database based on a key (Key-Value) of, Redis may be made of Value String, hash, list, set, zset, Bitmaps, HyperLogLog data structures and algorithms, and other components. Redis also provides key expired, publish-subscribe, transaction, Lua script, Sentinel, Cluster and other functions. Redis command execution speed is very fast, according to the official performance can be achieved 10w + qps. In this paper, in the end so fast Redis where the following main points:

First, the development of language
  and now we have a high-level programming language, such as Java, python and so on. You may find the C language is very old, but it is really useful, after all unix system is implemented in C, so C language is very close to the operating system language. Redis is using C language development, so the implementation will be faster.

  Also say one more thing, college students a good learning C, will make you a better understanding of computer operating systems. Do not think learning a high-level language you can not focus on the bottom, always owe a debt to repay. Here recommend a book more difficult nut to "in-depth understanding of computing systems."

Second, pure memory access
  Redis all data in memory, non-data synchronization to work in, is not required to read data from the disk, 0 times IO. Memory response time of about 100 nanoseconds, which is an important foundation of Redis fast speed. Take a look at CPU speed:

Face questions: single-threaded Redis why so fast?
  Take my computers, clocked at 3.1G, which means you can perform 3.1 * 10 ^ 9 instructions per second. So the CPU to see the world is very, very slow, a hundred times slower than its memory, disk million times slower than him, you say fast unhappy?

  Borrowed an "in-depth understanding of computer systems," the diagram shows a typical memory hierarchy, in the L0 layer, CPU can be accessed in a single clock cycle, based on the renewal of spring SRAM cache, you can in a few CPU clock cycle access to, and are based on DRAM main memory, you can have access to them in tens to hundreds of clock cycles.

三、单线程
  第一,单线程简化算法的实现,并发的数据结构实现不但困难且测试也麻烦。第二,单线程避免了线程切换以及加锁释放锁带来的消耗,对于服务端开发来说,锁和线程切换通常是性能杀手。当然了,单线程也会有它的缺点,也是Redis的噩梦:阻塞。如果执行一个命令过长,那么会造成其他命令的阻塞,对于Redis是十分致命的,所以Redis是面向快速执行场景的数据库。

  除了Redis之外,Node.js也是单线程,Nginx也是单线程,但他们都是服务器高性能的典范。

四、非阻塞多路I/O复用机制
  在这之前先要说一下传统的阻塞I/O是如何工作的:当使用read或者write对某一文件描述符(File Descriptor FD)进行读写的时候,如果数据没有收到,那么该线程会被挂起,直到收到数据。阻塞模型虽然易于理解,但是在需要处理多个客户端任务的时候,不会使用阻塞模型。

  I/O多路复用实际上是指多个连接的管理可以在同一进程。多路是指网络连接,复用只是同一个线程。在网络服务中,I/O多路复用起的作用是一次性把多个连接的事件通知业务代码处理,处理的方式由业务代码来决定。在I/O多路复用模型中,最重要的函数调用就是I/O 多路复用函数,该方法能同时监控多个文件描述符(fd)的读写情况,当其中的某些fd可读/写时,该方法就会返回可读/写的fd个数。

  Redis使用epoll作为I/O多路复用技术的实现,再加上Redis自身的事件处理模型将epoll的read、write、close等都转换成事件,不在网络I/O上浪费过多的时间。实现对多个FD读写的监控,提高性能。

  举个形象的例子吧。比如一个tcp服务器处理20个客户端socket。A方案:顺序处理,如果第一个socket因为网卡读数据处理慢了,一阻塞后面都玩蛋去。B方案:每个socket请求都创建一个分身子进程来处理,不说每个进程消耗大量系统资源,光是进程切换就够操作系统累的了。C方案(I/O复用模型,epoll):将用户socket对应的fd注册进epoll(实际上服务器和操作系统之间传递的不是socket的fd而是fd_set的数据结构),然后epoll只告诉哪些需要读/写的socket,只需要处理那些活跃的、有变化的socket fd的就好了。这样,整个过程只在调用epoll的时候才会阻塞,收发客户消息是不会阻塞的。

Guess you like

Origin www.cnblogs.com/wyf0518/p/11304259.html