Skip to main content

内存数据库

内存数据库(Redis)

内存:游戏和广告技术应用程序具有排行榜、会话存储和实时分析等使用案例,它们需要微秒响应时间并且可能随时出现大规模的流量高峰。

Redis 使用简单的键值方法来存储数据。键值数据库将数据存储为键值对集合,其中键作为唯一标识符。键和值都可以是从简单对象到复杂复合对象的任何内容。键值数据库是高度可分区的,并且允许以其他类型的数据库无法实现的规模进行水平扩展。

redis 有哪些常用的数据类型?

key-String(String 类型是 Redis 最基本的数据类型,一个 Redis 中字符串 value 最多可以是 512M)

list 是一个双向可读写的管道,其头部是左侧,尾部是右侧,一个列表最多可以包含 2^32-1 (4294967295)个元素,下标 0 表示列表的第一个元素,可以使用负数下标,元素值可以重复

Set 是 String 类型的无序集合,集合中的成员是唯一的,这就意味着集合中不能出现重复的数据,可以 在两个不同的集合中对数据进行对比并取值,常用于取值判断,统计,交集等场景

sorted set 有序集合,和集合一样也是 string 类型元素的集合,且不允许重复的成员,不同的是每个元素都会关 联一个 double(双精度浮点型)类型的分数, redis 正是通过该分数来为集合中的成员进行从小到大的排 序,有序集合的成员是唯一的,但分数(score)却可以重复,集合是通过哈希表实现的,所以添加,删 除,查找的复杂度都是 O(1), 集合中最大的成员数为 2^32 - 1 (4294967295, 每个集合可存储 40 多亿个 成员),经常用于排行榜的场景。每个元素是由 score 和 value 组成:score 可以重复,value 不可以重复

hash 是一个 string 类型的字段(field)和值(value)的映射表, Redis 中每个 hash 可以存储 2^32 -1 键值对,类似于字典,存放了多个 k/v 对, hash 特别适合用于存储对象场景

  • 哈希表,获取该表的全部数据和表中指定 key 的数据,分别对应的命令
# 获取所有哈希表中的字段
hkeys key
#获取在哈希表中指定 key 的所有字段和值
hgetall key

说几个你在项目中的应用场景

使用爬虫进行分任务爬取,对爬取到的文本、快照(截图)进行分任务保存。

  • 为什么要用 redis 来做?

redis 是基于内存存储计算,性能速读远超 mysql 等数据库,计算速度很快,所以在使用的时候数据响应很快。

持久化的存储方式有哪些?

AOF(append only file) 持久化,采用日志的形式来记录每个写操作,追加到 AOF 文件的末尾。 RDB 持久化,是指在指定的时间间隔内,执行指定次数的写操作,将内存中的数据集快照写入磁盘中,它是 Redis 默认的持久化方式。执行完操作后,在指定目录下会生成一个 dump.rdb 文件,Redis 重启的时候,通过加载 dump.rdb 文件来恢复数据。

过期键的删除策略是怎样的?

目前来说有三种删除策略:

  • 定时删除:在设置键的过期时间时,创建一个定时器,当到达键过期时间时通过定时器去删除键。 优点是:对内存友好。因为通过定时器,当一个键到达过期时间时就会立马被删除,直接就释放了内存。 缺点是:对 CPU 不友好。因为如果过期键比较多,那么删除这些过期键会占用相当一部分 CPU 时间,如果 CPU 时间非常紧张的话,还将 CPU 时间用在删除和当前任务无关的过期键上,会对服务器的响应时间以及吞吐量造成影响。

惰性删除:惰性删除并不是当到达过期时间时去删除,而是每次获取键时,会判断是否过期,如果过期则删除,并返回空;没过期,就返回键值。 优点:对 CPU 时间友好。程序只会在取出键时才会判断是否删除,并且只作用到当前键上,其他过期键不会花费 CPU 时间去处理。 缺点:对内存不友好。因为只有键被使用时才会去检查是否删除,如果有大量的键一直不被使用,那么这些键就算过期了也不会被删除,会一直占用着内存。这种可以理解为是一种内存泄漏——大量无用的数据一直占用着内存,并且不会被删除。

定期删除:每隔一段时间,就对数据库中的键进行检查,如果过期则删除。至于要删除多少什么时候删除,则是通过具体程序决定。 定期删除策略每隔一段时间执行一次删除过期键操作,并通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。 并且,通过定期删除过期键,有效的减少了过期键带来的内存浪费。 但删除的时长和频率比较难定义,因为:如果频率太高或者时长太长,那么会占用大量的 CPU 时长。如果过短又会出现内存浪费的情况。 因此。如果采用定期删除策略的话需要通过具体的业务场景来定义时长和频率。