浅谈为什么单线程的redis那么快

目录
  • redis单机QPS
  • 为什么这么快
    • 内存型数据库
    • 简单的数据结构
    • 单线程
    • IO多路复用
  • 总结

redis单机QPS

./redis-benchmark -t set,lpush -n 100000 -q
SET: 82101.80 requests per second
LPUSH: 82440.23 requests per second

在自己的电脑上测试SET和LPUSH10万次,可以发现每秒SET和LPUSH大概在8w多,接近官方说的单机10w qps的写。

为什么这么快

内存型数据库

redis完全是基于内存的,绝大部分请求是纯粹的内存操作,所以非常快速。

简单的数据结构

redis目前支持5种数据类型(string、list、hash、set、zset),数据结构相对简单,操作起来也相对快速。

sds数据结构

对于string来说,redis采用SDS方式来组织数据:

这种数据的核心思想就是空间换时间

空间预分配:当空间扩展时,不仅分配所需空间,还会分配额外的空间

  • 分配后sds长度小于1M,那么也分配同样大小的额外空间,假设一个key修改后 len=13,那么也分配free=13,最后buf=13+13+1=27
  • 如果分配后len大于等于1M,那么额外固定分配1M,假设修改后len=30M,分配free=1M,最后buf=30M+1M+1byte

惰性空间释放

  • 假设有个len=13,free=13的字符串,这时候如果字符变短了len=10,那么额外的3个byte的空间也不会回收,先放在free里面,这时候free=16

通过这种分配方式,某些场景下可以减少内存申请的次数,从而达到一定的快速

跳跃表

redis的有序集合,采用的跳跃表的数据结构,通过层来加快访问其他节点

每个节点会随机一个层高,比如o1节点可以通过L4层直接跳到o3,跨度是2,redis的有序集合就是通过这种方式来加快节点之间的访问的。

单线程

redis采用单线程模型,单线程的好处在于避免了多线程对数据竞争的问题,加锁的问题,上下文切换的问题。
据官方解释,redis的瓶颈不在cpu,而在内存或者网络的带宽,综合考虑然后就采用了单线程。这里说的单线程是指处理网络请求时只是用一个线程,redis本身在持久化的时候还是会用到额外的线程的。

redis4.0的多线程

redis4.0开始也支持了多线程,当然只是针对部分命令采用的是多线程,例如:UNLINK、FLUSHALL 、ASYNC、FLUSHDB。引入这些的目的是:在某些情况下,尽可能的提升效率,假设有一个key大到几十M,这时DEL这个key的时候,可能会短暂的阻塞,这时如果用unlink来删除,刚开始只是删除这个key,真正的value是后台线程去删除的。

IO多路复用

redis采用了非阻塞的IO多路复用技术。redis本身就是一个事件驱动程序,redis把socket抽象成文件事件。这里说的IO多路复用就是文件事件处理器以单线程的方式,来监听相关的套接字(accept、read、write、close)。

由于IO多路复用程序是一个单线程,那么当多个socket到来时,肯定要排队,它们总是以队列的方式顺序地处理。

C10K问题

在没有IO多路复用的时候,假设现在有10000个客户端连接(fd1-10000),但是只有1个客户端有发数据,然而计算机并不知道哪个fd有数据,只能遍历10000次,每次都要陷入内核,开销比较大,而且实际上9999次都是浪费的。

IO多路复用

IO多路复用的意思就是多个网路IO即为多个TCP连接 复用一个进程或者线程,这种模型最大的好处就是不用为每个连接创建一个进程或者线程。比较经典的模型就是 select、poll、epoll。

  • select:select(fds),一次性把fds交给内核,然后内核告诉哪些fd可读可写(内核自己遍历,而不用用户遍历,将多次的系统调用变成1次系统调用)。fds最大是1024,这也决定了select模型最大并发是1024。
  • poll:和select差不多,只不过并发不止1024了,可以更多
  • epoll: select和poll的缺点是内核遍历的时间复杂度是O(n),虽然用户态不用遍历了,减少了陷入内核的次数,但是内核还是要遍历的。epoll的优点就是内核也不需要遍历了,当用户把fds传给内核时,然后依赖硬件中断,比如当网卡有数据到来时,就会中断告诉cpu,cpu就知道哪个fd有数据到达了。

redis默认采用epoll,除非系统不支持。

总结

  • redis是内存型数据库
  • redis特殊的数据结构
  • 单线程避免锁的竞争
  • io多路复用

以上4点是单线程redis快的主要原因。

到此这篇关于浅谈为什么单线程的redis那么快的文章就介绍到这了,更多相关redis 单线程快内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 详解Redis单线程的正确理解

    很多同学对Redis的单线程和I/O多路复用技术并不是很了解,所以我用简单易懂的语言让大家了解下Redis单线程和I/O多路复用技术的原理,对学好和运用好Redis打下基础. 一.Redis的单线程理解 Redis客户端对服务端的每次调用都经历了发送命令,执行命令,返回结果三个过程.其中执行命令阶段,由于Redis是单线程来处理命令的,所有到达服务端的命令都不会立刻执行,所有的命令都会进入一个队列中,然后逐个执行,并且多个客户端发送的命令的执行顺序是不确定的,但是可以确定的是不会有两条命令被同时

  • Redis不是一直号称单线程效率也很高吗,为什么又采用多线程了?

    Redis是目前广为人知的一个内存数据库,在各个场景中都有着非常丰富的应用,前段时间Redis推出了6.0的版本,在新版本中采用了多线程模型. 因为我们公司使用的内存数据库是自研的,按理说我对Redis的关注其实并不算多,但是因为Redis用的比较广泛,所以我需要了解一下这样方便我进行面试. 总不能候选人用过Redis,但是我非要问人家阿里的Tair是怎么回事吧. 所以,在Redis 6.0 推出之后,我想去了解下为什么采用多线程,现在采用的多线程和以前版本有什么区别?为什么这么晚才使用多线程?

  • redis单线程快的原因和原理

    Redis之所以执行速度很快,主要依赖于以下几个原因: (一)纯内存操作,避免大量访问数据库,减少直接读取磁盘数据,redis 将数据储存在内存里面,读写数据的时候都不会受到硬盘 I/O 速度的限制,所以速度快: (二)单线程操作,避免了不必要的上下文切换和竞争条件,也不存在多进程或者多线程导致的切换而消耗 CPU,不用去考虑各种锁的问题,不存在加锁释放锁操作,没有因为可能出现死锁而导致的性能消耗: (三)采用了非阻塞I/O多路复用机制 多路复用原理: 用户首先将需要进行IO操作的socket添

  • 浅谈为什么单线程的redis那么快

    目录 redis单机QPS 为什么这么快 内存型数据库 简单的数据结构 单线程 IO多路复用 总结 redis单机QPS ./redis-benchmark -t set,lpush -n 100000 -q SET: 82101.80 requests per second LPUSH: 82440.23 requests per second 在自己的电脑上测试SET和LPUSH10万次,可以发现每秒SET和LPUSH大概在8w多,接近官方说的单机10w qps的写. 为什么这么快 内存型数

  • 浅谈我是如何用redis做实时订阅推送的

    前阵子开发了公司领劵中心的项目,这个项目是以redis作为关键技术落地的. 先说一下领劵中心的项目吧,这个项目就类似京东app的领劵中心,当然图是截取京东的,公司的就不截了... 其中有一个功能叫做领劵的订阅推送.什么是领劵的订阅推送?就是用户订阅了该劵的推送,在可领取前的一分钟就要把提醒信息推送到用户的app中.本来这个订阅功能应该是消息中心那边做的,但他们说这个短时间内做不了.所以让我这个负责优惠劵的做了-.-!.具体方案就是到具体的推送时间点了,coupon系统调用消息中心的推送接口,把信

  • 浅谈一下如何保证Redis缓存与数据库的一致性

    目录 1.四种同步策略: 2.更新缓存还是删除缓存 2.1 更新缓存 2.2 删除缓存 3.先操作数据库还是缓存 3.1 先删除缓存再更新数据库 3.2 先更新数据库再删除缓存 最终结论: 4.延时双删 4.1 采用读写分离的架构怎么办? 5.利用消息队列进行删除的补偿 1.四种同步策略: 想要保证缓存与数据库的双写一致,一共有4种方式,即4种同步策略: 先更新缓存,再更新数据库: 先更新数据库,再更新缓存: 先删除缓存,再更新数据库: 先更新数据库,再删除缓存. 从这4种同步策略中,我们需要作

  • 浅谈java如何实现Redis的LRU缓存机制

    目录 LRU概述 使用LinkedHashMap实现 使用LinkedHashMap简单方法实现 双链表+hashmap LRU概述 最近使用的放在前面,最近没用的放在后面,如果来了一个新的数,此时内存满了,就需要把旧的数淘汰,那为了方便移动数据,肯定就得使用链表类似的数据结构,再加上要判断这条数据是不是最新的或者最旧的那么应该也要使用hashmap等key-value形式的数据结构. 使用LinkedHashMap实现 package thread; import java.util.Link

  • 浅谈内存耗尽后Redis会发生什么

    前言 作为一台服务器来说,内存并不是无限的,所以总会存在内存耗尽的情况,那么当 Redis 服务器的内存耗尽后,如果继续执行请求命令,Redis 会如何处理呢? 内存回收 使用Redis 服务时,很多情况下某些键值对只会在特定的时间内有效,为了防止这种类型的数据一直占有内存,我们可以给键值对设置有效期.Redis 中可以通过 4 个独立的命令来给一个键设置过期时间: expire key ttl:将 key 值的过期时间设置为 ttl 秒. pexpire key ttl:将 key 值的过期时

  • 浅谈Spring Boot中Redis缓存还能这么用

    经过Spring Boot的整合封装与自动化配置,在Spring Boot中整合Redis已经变得非常容易了,开发者只需要引入Spring Data Redis依赖,然后简单配下redis的基本信息,系统就会提供一个RedisTemplate供开发者使用,但是今天松哥想和大伙聊的不是这种用法,而是结合Cache的用法.Spring3.1中开始引入了令人激动的Cache,在Spring Boot中,可以非常方便的使用Redis来作为Cache的实现,进而实现数据的缓存. 工程创建 首先创建一个Sp

  • 浅谈Redis中的RDB快照

    一.概述 所谓的快照,就是记录某一个瞬间东西,比如当我们给风景拍照时,那一个瞬间的画面和信息就记录到了一张照片. 所以,RDB 快照就是记录某一个瞬间的内存数据,记录的是实际数据,而 AOF 文件记录的是命令操作的日志,而不是实际的数据. 因此在 Redis 恢复数据时, RDB 恢复数据的效率会比 AOF 快些,因为直接将 RDB 文件读入内存就可以了,不需要像 AOF 那样还需要额外执行操作命令的步骤才能恢复数据. 接下来,就来具体聊聊 RDB 快照 . 二.快照怎么用? 要熟悉一个东西,先

  • 浅谈Redis缓存有哪些淘汰策略

    目录 Redis过期策略 定时删除 惰性删除 定期删除 Redis的内存淘汰机制 LRU和LFU的区别 LRU LFU Redis重启如何恢复数据呢? 总结 Redis过期策略 我们首先来了解一下Redis的内存淘汰机制. 定时删除 概述     redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key,检查其是否过期,如果过期就删除.注意这里是随机抽取的.为什么要随机呢?你想一想假如 redis 存了几十万个 key ,每隔100ms就遍历所有的设置过期时间的 key 的话,就会

  • 浅谈Redis对于过期键的三种清除策略

    目录 Pre Redis Key的超时设置处理 被动删除 主动删除 当前已用内存超过maxmemory限定时,触发主动清理策略 对于过期键一般有三种删除策略 定时删除:在设置键的过期时间的同时,创建一个定时器(timer),让定时器在键的过期时间来临时,立即执行对键的删除操作: 惰性删除:放任键过期不管,但是每次从键空间中获取键时,都检查取得的键是否过期,如果过期的话,就删除该键:如果没有过期,那就返回该键: 定期删除:每隔一段时间,程序就对数据库进行一次检查,删除里面的过期键.至于删除多少过期

  • 浅谈Redis跟MySQL的双写问题解决方案

    目录 写在前面 三种读写缓存策略 Cache-AsidePattern(旁路缓存模式) Read-Through/Write-Through(读写穿透) WriteBehindPattern(异步缓存写入) 旁路缓存模式解析 CacheAsidePattern的一些疑问 CacheAsidePattern的缺陷 项目中有遇到这个问题,跟MySQL中的数据不一致,研究一番发现这里面细节并不简单,特此记录一下. 写在前面 严格意义上任何非原子操作都不可能保证一致性,除非用阻塞读写实现强一致性,所以缓

随机推荐