性能测试 | 理解单线程的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为啥那么快?
拿我的电脑来说,主频是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为何那么快?的更多相关文章
- 单线程的REDIS为什么这么快?
REDIS是单线程处理所有请求,和一般经典实际上推荐的方式相反,那么单线程串行处理,为什么依然能够做到很快呢?知乎上的一个答案如下,其中线程切换和锁不是性能主要影响因素的观点和一般的答案都不同: 作者 ...
- Redis 为什么这么快?
1. 纯内存操作,肯定快 数据存储在内存中,读取的时候不需要进行磁盘的 IO 2. 单线程,无锁竞争损耗 单线程保证了系统没有线程的上下文切换 使用单线程,可以避免不必要的上下文切换和竞争条件,没有多 ...
- Redis为什么这么快?
Redis为什么这么快?
- 硬核!15张图解Redis为什么这么快
作为一名服务端工程师,工作中你肯定和 Redis 打过交道.Redis 为什么快,这点想必你也知道,至少为了面试也做过准备.很多人知道 Redis 快仅仅因为它是基于内存实现的,对于其它原因倒是模棱两 ...
- 为什么说Redis是单线程的以及Redis为什么这么快!
参考文章:https://blog.csdn.net/xlgen157387/article/details/79470556 redis简介 Redis是一个开源的内存中的数据结构存储系统,它可以用 ...
- 为什么说Redis是单线程的以及Redis为什么这么快!(转)
文章转自https://blog.csdn.net/chenyao1994/article/details/79491337 一.前言 近乎所有与Java相关的面试都会问到缓存的问题,基础一点的会问到 ...
- 《为什么说Redis是单线程的以及Redis为什么这么快!》
为什么说Redis是单线程的以及Redis为什么这么快! 一.前言 近乎所有与Java相关的面试都会问到缓存的问题,基础一点的会问到什么是“二八定律”.什么是“热数据和冷数据”,复杂一点的会问到缓 ...
- 为什么说Redis是单线程的以及Redis为什么这么快!(转)
一.前言 近乎所有与Java相关的面试都会问到缓存的问题,基础一点的会问到什么是“二八定律”.什么是“热数据和冷数据”,复杂一点的会问到缓存雪崩.缓存穿透.缓存预热.缓存更新.缓存降级等问题,这些看似 ...
- 为什么单线程的Redis这么快?
一. Redis简介 Redis是一个开源的内存中的数据结构存储系统,它可以用作数据库.缓存和消息中间件. 它支持多种类型的数据结构,如 字符串(strings), 散列(hashes), 列表(li ...
随机推荐
- 安卓开发之ArrayAdapter使用
package com.lidaochen.test; import android.support.v7.app.AppCompatActivity; import android.os.Bundl ...
- .net工作流引擎ccflow集成并增加自定义功能
一.为什么需要自定义扩展 1.第三方类库已满足大部分需求,剩下的根据具体业务需求抽象成公共功能进行扩展 2.第三方呈现的web页面与原类库耦合度较高,希望在原页面上扩展而不影响原来的功能 3.在完全不 ...
- bash shell脚本之获取时间日期
shell中的时间日期获取 cat test5: #!/bin/bash # using the backtick character testing=`date` echo "The da ...
- 01.Zabbix监控快速入门
1.监控知识基本概述 1.为什么要使用监控 1.对系统不间断实时监控 2.实时反馈系统当前状态 3.保证服务可靠性安全性 4.保证业务持续稳定运行 2.如何进行监控,比如我们需要监控磁盘的使用率 1. ...
- JS中数组初始化以及赋值
.指定长度,然后初始化 ); ;index < ;index++){ vArray[index] = index; } 2.不指定长度,然后初始化 var vArray = new Array( ...
- Java NIO 学习笔记一
缓冲区操作 进程执行I/O操作,归结起来就是向操作系统发出请求,它要么把缓存区例的数据排干(写),要么用数据把数据区填满(读).进程使用这一机制处理所有数据进出操作. 进程使用read()系统调用,要 ...
- python -m pip install [package] --no-deps
python -m pip install [package] --no-deps 有些 packages 会依赖一些其它的 package,当我们离线安装 whl 的时候,就无法联网下载依赖包,所 ...
- Invalid argument: Key: label. Data types don't match. Data type: int64 but expected type: float
改为
- onpageshow、onpagehide、onload、onunload
onpageshow :在用户浏览网页时触发, 在页面从浏览器缓存中读取时也触发 通过event.persisted 来判断, 如果页面从浏览器的缓存中读取该属性返回 ture,否则返回 false ...
- stm32——modbus例程网址收藏
https://blog.csdn.net/baidu_31437863/article/details/82178708 STM32(五) Modbus https://blog.csdn.net/ ...