四个大点,搞懂 Redis 到底快在哪里?
前言
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的速度:
![四个大点,搞懂 Redis 到底快在哪里?](https://s5.51cto.com/oss/201907/15/a4504857a493f9d2f0443d4cc3a84b10.jpeg)
拿我的电脑来说,主频是3.1G,也就是说每秒可以执行3.1*10^9个指令。所以说CPU看世界是非常非常慢的,内存比它慢百倍,磁盘比他慢百万倍,你说快不快?
借了一张《深入理解计算机系统》的图,展示了一个典型的存储器层次结构,在L0层,CPU可以在一个时钟周期访问到,基于SRAM的高速缓存春续期,可以在几个CPU时钟周期访问到,然后是基于DRAM的主存,可以在几十到几百个时钟周期访问到他们。
![四个大点,搞懂 Redis 到底快在哪里?](https://s4.51cto.com/oss/201907/15/a6d187d49ac45f1db014b646329eff15.jpeg)
三. 单线程
第一,单线程简化算法的实现,并发的数据结构实现不但困难且测试也麻烦。第二,单线程避免了线程切换以及加锁释放锁带来的消耗,对于服务端开发来说,锁和线程切换通常是性能杀手。当然了,单线程也会有它的缺点,也是Redis的噩梦:阻塞。如果执行一个命令过长,那么会造成其他命令的阻塞,对于Redis是十分致命的,所以Redis是面向快速执行场景的数据库。
除了Redis之外,Node.js也是单线程,Nginx也是单线程,但他们都是服务器高性能的典范。
四. 非阻塞多路I/O复用机制
在这之前先要说一下传统的阻塞I/O是如何工作的:当使用read或者write对某一文件描述符(File Descriptor FD)进行读写的时候,如果数据没有收到,那么该线程会被挂起,直到收到数据。阻塞模型虽然易于理解,但是在需要处理多个客户端任务的时候,不会使用阻塞模型。
![四个大点,搞懂 Redis 到底快在哪里?](https://s2.51cto.com/oss/201907/15/0652469f08556c551940d0d3451de445.jpeg)
I/O多路复用实际上是指多个连接的**管理可以在同一进程。**多路是指网络连接,复用只是同一个线程。在网络服务中,I/O多路复用起的作用是一次性把多个连接的事件通知业务代码处理,处理的方式由业务代码来决定。在I/O多路复用模型中,最重要的函数调用就是I/O 多路复用函数,该方法能同时监控多个文件描述符(fd)的读写情况,当其中的某些fd可读/写时,该方法就会返回可读/写的fd个数。
![四个大点,搞懂 Redis 到底快在哪里?](https://s2.51cto.com/oss/201907/15/ed4c5bd27404db878d50ee9025bff1a1.jpeg)
Redis使用epoll作为I/O多路复用技术的实现,再加上Redis自身的事件处理模型将epoll的read、write、close等都转换成事件,不在网络I/O上浪费过多的时间。实现对多个FD读写的监控,提高性能。
![四个大点,搞懂 Redis 到底快在哪里?](https://s3.51cto.com/oss/201907/15/3a647063a8a3ef68db260b53dfd834db.jpeg)
举个形象的例子吧。比如一个tcp服务器处理20个客户端socket。A方案:顺序处理,如果第一个socket因为网卡读数据处理慢了,一阻塞后面都玩蛋去。B方案:每个socket请求都创建一个分身子进程来处理,不说每个进程消耗大量系统资源,光是进程切换就够操作系统累的了。C方案**(I/O复用模型,epoll):将用户socket对应的fd注册进epoll(实际上服务器和操作系统之间传递的不是socket的fd而是fd_set的数据结构),然后epoll只告诉哪些需要读/写的socket,只需要处理那些活跃的、有变化的socket fd的就好了。这样,整个过程只在调用epoll的时候才会阻塞,收发客户消息是不会阻塞的。
相关文章
- Data-centric AI之数据集质量
- 从 Oracle 迁移到 PostgreSQL 时空字符串的处理
- 优化 Amazon ElastiCache for Redis 和 Amazon MemoryDB for Redis 上的应用程序内存使用情况
- 利用Amazon SCT评估报告为 Babelfish 迁移做好准备
- 使用 ElastiCache 和 MemoryDB 解锁 JSON 工作负载
- 使用 Amazon Redshift 构建用于批量和实时分析的大数据 Lambda 架构
- 利用 Amazon Glue、Amazon Kinesis Data Streams、Amazon DynamoDB 和 Amazon QuickSight 的零售无服务器运营数据湖
- Amazon Redshift UDF实现对比
- Gartner® 在新报告中认可 Amazon RDS
- Debezium 特性深入介绍
- 道琼斯如何一次性迁移其业务关键型数据库并实现现代化以改善效率和成本效益
- Amazon Glue集成Delta Lake构建事务型数据湖上的流式处理
- java IO
- AWS DataSync 的新增功能 — 在 AWS 和 Google Cloud Storage 或 AWS 和 Microsoft Azure 文件之间移动数据
- 基于AWS和西门子工业边缘的云边协同方案
- java01
- 动如脱兔 静若磐石 新一代云原生无服务数据库Aurora Serverless V2重装上阵
- 新一代国产 NewSQL 昆仑数据库的云上探索和压测表现
- Amazon Aurora Serverless v2正式发布:瞬时扩展应对高要求的工作负载
- 将数据仓库迁移到 Amazon Redshift 时的考虑事项