共计 1839 个字符，预计需要花费 5 分钟才能阅读完成。
这篇文章给大家分享的是有关 Redis 速度为什么快的内容。丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，一起跟随丸趣 TV 小编过来看看吧。
Redis 是一种基于键值对 (Key-Value) 的 NoSQL 数据库，Redis 的 Value 可以由 String，hash，list，set，zset，Bitmaps，HyperLogLog 等多种数据结构和算法组成。Redis 还提供了键过期，发布订阅，事务，Lua 脚本，哨兵，Cluster 等功能。
Redis 执行命令的速度非常快，根据官方给的性能可以达到 10w+qps。那么本文主要介绍到底 Redis 快在哪里，主要有以下几点：
一、开发语言
现在我们都用高级语言来编程，比如 Java、python 等。也许你会觉得 C 语言很古老，但是它真的很有用，毕竟 unix 系统就是用 C 实现的，所以 C 语言是非常贴近操作系统的语言。Redis 就是用 C 语言开发的，所以执行会比较快。
另外多说一句，大学生们好好学 C，会让你更好的理解计算机操作系统。别觉得学了高级语言就可以不用关注底层，欠的债总归要还的。此处推荐一本比较难啃的书《深入理解计算系统》。
二、纯内存访问
Redis 将所有数据放在内存中，非数据同步正常工作中，是不需要从磁盘读取数据的，0 次 IO。内存响应时间大约为 100 纳秒，这是 Redis 速度快的重要基础。先看看 CPU 的速度：
拿我的电脑来说，主频是 3.1G，也就是说每秒可以执行 3.1*10^9 个指令。所以说 CPU 看世界是非常非常慢的，内存比它慢百倍，磁盘比他慢百万倍，你说快不快？
借了一张《深入理解计算机系统》的图，展示了一个典型的存储器层次结构，在 L0 层，CPU 可以在一个时钟周期访问到，基于 SRAM 的高速缓存春续期，可以在几个 CPU 时钟周期访问到，然后是基于 DRAM 的主存，可以在几十到几百个时钟周期访问到他们。
三、单线程
第一，单线程简化算法的实现，并发的数据结构实现不但困难且测试也麻烦。第二，单线程避免了线程切换以及加锁释放锁带来的消耗，对于服务端开发来说，锁和线程切换通常是性能杀手。当然了，单线程也会有它的缺点，也是 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 的时候才会阻塞，收发客户消息是不会阻塞的。
感谢各位的阅读！关于“Redis 速度为什么快”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
