Redis核心技术总结

Redis核心技术总结

文章目录

  • Redis核心技术总结
    • 导论
    • 1. redis的数据结构
      • 键-值的结构组织
        • 全局哈希表
      • 哈希表的rehash
      • redis数据结构的时间复杂度
      • 不同操作的复杂度
    • 2. 单线程的Redis为何这么快
      • Redis是单线程的吗?
      • Redis为什么要用单线程?
      • 单线程Redis为什么那么快?
      • 基于多路复用的高性能I/O模型
    • 3.Redis持久化
      • AOF(Append Only File)
        • 写回策略
        • 重写(rewrite)
        • 何时重写ROF文件
      • RDB
        • 两个命令
        • 执行快照时数据能否修改
        • 混合使用 AOF 日志和内存快照
      • AOF 和 RDB 的选择

导论

在平时的工作项目中,使用redis很长时间了,但一直没有系统的学习总结过,现在看到极客时间蒋德钧老师开设的《Redis核心技术与实战》,干货满满,特地跟随课程小小总结一下,以供日后复习之用。

Redis 知识全景----两大维度,三大主线

Redis核心技术总结_第1张图片

应用维度学习路线:

  1. 应用场景驱动

  2. 典型案例驱动

    Redis核心技术总结_第2张图片

1. redis的数据结构

数据类型(5种):String(字符串)、List(列表)、Hash(哈希)、Set(集合)和 Sorted Set(有序集合)

数据结构(6种):简单动态字符串(Simple Dynamic String)、双向链表、压缩列表(ziplist)、哈希表、跳跃表(skiplist)和整数集合(intset)

数据类型与数据结构对应关系:

一种:String–>SDS

二种:集合类型(一个键对应了一个集合的数据) List、Hash、Set 和 Sorted Set

Redis核心技术总结_第3张图片

键-值的结构组织

全局哈希表

无论String,还是集合类型,哈希桶中的元素都是指向它们的指针。

Redis核心技术总结_第4张图片

哈希表的rehash

哈希冲突解决方式:链式哈希

渐近式哈希:把一次性大量拷贝的开销,分摊到了多次处理请求的过程中,避免了耗时操作,保证了数据的快速访问。

redis数据结构的时间复杂度

Redis核心技术总结_第5张图片

不同操作的复杂度

单元素操作是基础

一种集合类型对单个数据实现的增删改查操

范围操作非常耗时

集合类型中的遍历操作,可以返回集合中的所有数据

统计操作通常高效

集合类型对集合中所有元素个数的记录

例外情况只有几个

压缩列表和双向链表都会记录表头和表尾的偏移量

2. 单线程的Redis为何这么快

Redis是单线程的吗?

Redis对外提供键值存储服务的主要流程,即网络IO和键值对读写是由一个线程完成的,但其它功能,比如持久化、异步删除、集群数据同步等,是由额外的线程执行的。

Redis为什么要用单线程?

多线程编程模式面临的共享资源的并发访问控制问题,会造成系统吞吐率并没有随线程的增加而线性增长

单线程Redis为什么那么快?

  1. Redis 的大部分操作在内存上完成,再加上它采用了高效的数据结构,例如哈希表和跳表

  2. Redis 采用了多路复用机制,使其在网络 IO 操作中能并发处理大量的客户端请求,实现高吞吐率

基于多路复用的高性能I/O模型

Linux中的select/epoll多路复用机制,指一个线程处理多个IO流。Redis 单线程运行时,该机制允许内核中,同时存在多个监听套接字和已连接套接字。内核会一直监听这些套接字上的连接请求或数据请求。一旦有请求到达,就会交给 Redis 线程处理,这就实现了一个 Redis 线程处理多个 IO 流的效果。

3.Redis持久化

AOF(Append Only File)

AOF是写后日志,将数据写入内存,然后再记录日志。

写后日志好处:1.避免出现记录错误命令的情况;2.不会阻塞当前的写操作

写回策略

Redis核心技术总结_第6张图片

重写(rewrite)

一个拷贝,两处日志

“一个拷贝” - 每次执行重写时,主线程 fork 出后台的 bgrewriteaof 子进程,子进程拷贝一份含有 数据库最新数据的内存

“两处日志”

  1. 正在使用的AOF日志。
  2. 新的AOF重写日志。
    Redis核心技术总结_第7张图片

何时重写ROF文件

  1. 手动执行 bgrewriteaof 触发 AOF 重写
  2. 在 redis.conf 文件中配置重写的条件,如:
    auto-aof-rewrite-min-size 64MB // 当文件小于64M时不进行重写
    auto-aof-rewrite-min-percenrage 100 // 当文件比上次重写后的文件大100%时进行重写

RDB

执行的是全量快照

两个命令

  • save 主线程执行,导致阻塞

  • bgsave fork一个子进程,避免阻塞,默认配置

执行快照时数据能否修改

采用写时复制技术(Copy-On-Write, COW),在执行快照的同时,正常处理写操作。

如果主线程要修改一块数据(例如图中的键值对 C),则被修改据被复制一份,生成该数据的副本。然后,bgsave 子进程将副本数据写入 RDB 文件,而在这个过程中,主线程仍然可以直接修改原来的数据.

Redis核心技术总结_第8张图片

混合使用 AOF 日志和内存快照

内存快照以一定的频率执行,在两次快照之间,使用 AOF 日志记录这期间的所有命令操作,当执行第二次全量快照时清空AOF日志。

Redis 4.0 开始支持 rdb 和 aof 的混合持久化(默认关闭,aof-use-rdb-preamble配置)。如果把混合持久化打开,aof rewrite 的时候就直接把 rdb 的内容写到 aof 文件开头

AOF 和 RDB 的选择

  • 数据不能丢失时,内存快照和 AOF 的混合使用是一个很好的选择
  • 如果允许分钟级别的数据丢失,可以只使用 RDB
  • 如果只用 AOF,优先使用 everysec 的配置选项,因为它在可靠性和性能之间取了一个平衡。

你可能感兴趣的:(redis)