redis缓存知识点

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/zy1994hyq/article/details/99302718

redis的特点

  1. 单线程异步IO,采用非阻塞异步事件处理机制,缓存数据都是内存操作,IO操作时间不会太长,单线程可以避免线程上下文切换产生的代价
  2. 支持持久化,所以redis不仅可以做缓存,也能做nosql数据库
  3. 多数据结构:String、Hash、List、Set、ZSet、HyperLogLog、Geo
  4. 提供主从模式以及cluser集群部署机制

redis的常见的5种数据结构:

类型 简介 特性 场景
String 二进制安全 可以包含任何数据,比如jpg图片或者序列化的对象,一个键最大能存储512M 普通的k,v存储都可以,也可以利用setnx命令实现分布式锁
Hash 键值对集合,即编程语言中的Map类型 适合存储对象,并且可以像数据库中update一个属性一样只修改某一项属性值(Memcached中需要取出整个字符串反序列化成对象修改完再序列化存回去) 存储、读取、修改用户属性
List 链表(双向链表) 增删快,提供了操作某一段元素的API 1,最新消息排行等功能(比如朋友圈的时间线) 2,消息队列
Set 哈希表实现,元素不重复 1、添加、删除,查找的复杂度都是O(1) 2、为集合提供了求交集、并集、差集等操作

1、共同好友

2、利用唯一性,统计访问网站的所有独立ip(HyperLogLog更适合)

3、好友推荐时,根据tag求交集,大于某个阈值就可以推荐

ZSet 将Set中的元素增加一个权重参数score,元素按score有序排列 数据插入集合时,已经进行天然排序

 1、排行榜 2、带权重的消息队列 3、延时队列使用时间戳做score

另外还有:

bitmap、hyperloglog可以用来做大规模数据的去重统计

geo计算地理位置,位置距离计算,根据半径计算位置,计算范围内的位置有哪些

 redis提供的功能

  1. pub/sub,订阅发布功能,可以用作简单的消息队列
  2. pipeline,可以批量执行一组指令,所有指令执行完成后,一次性返回所有结果。可能会出现某条指令执行失败但大部分都执行成功的情况,适合对可靠性要求不是很高和实时性要求不高的场景,可以避免频繁应答。
  3. lua脚本
  4. 事务,redis提供的不是严格的事务,redis只保证串行执行命令,并且能保证全部执行,但是执行命令失败时不会回滚,而会继续执行下去

redis的持久化

RDB

RDB优点

  1. 把内存中的数据集以快照的方式写入磁盘。保存了 Redis 在某个时间点上的数据集。 比如说,你可以在最近的 24 小时内,每小时备份一次 RDB 文件,并且在每个月的每一天,也备份一个 RDB 文件。 这样的话,即使遇上问题,也可以随时将数据集还原到不同的版本。因此RDB 非常适用于灾难恢复
  2. RDB 可以最大化 Redis 的性能:父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程,然后这个子进程就会处理接下来的所有保存工作,父进程无须执行任何磁盘 I/O 操作。
  3. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB 的缺点

  • 如果在快照保存完成前服务器宕机会造成数据丢失。如果你需要尽量避免在服务器故障时丢失数据,那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点(save point)来控制保存 RDB 文件的频率, 但是, 因为RDB 文件需要保存整个数据集的状态, 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下, 一旦发生故障停机, 你就可能会丢失好几分钟的数据。
  • 保存快照是可能导致服务短时间不可用。每次保存 RDB 的时候,Redis 都要 fork() 出一个子进程,并由子进程来进行实际的持久化工作。 在数据集比较庞大时, fork() 可能会非常耗时,由于redis是单线程,因此在 fork()出一个子进程的过程中,造成服务器在某某毫秒内停止处理客户端; 如果数据集非常巨大,并且 CPU 时间非常紧张的话,那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ,但无论 AOF 重写的执行间隔有多长,数据的耐久性都不会有任何损失。为了避免这种情况,我们可以通过主从部署的方式,让耗时的保存操作如:bgsave操作,在从服务上运行,这样就不会影响主服务的运行。

AOF

AOF 的优点

  • AOF可以设置不同的 fsync 策略。三个选项:
    1).appendfsync always 每次有新命令追加到 AOF 文件时就执行一次 fsync :非常慢,也非常安全。
    2).appendfsync everysec 每秒 fsync 一次:足够快(和使用 RDB 持久化差不多),并且在故障时只会丢失 1 秒钟的数据。
    3).appendfsync no 从不 fsync :将数据交给操作系统来处理。更快,也更不安全的选择。
  • AOF 的运作方式是不断地将命令追加到文件的末尾。因此对 AOF 文件的写入不需要进行 seek 而是直接追加在最后。
  • AOP文件出错,日志因为某些原因而包含了未写入完整的命令(比如写入时磁盘已满,写入中途停机,等等), redis-check-aof 工具也可以轻易地修复这种问题。
  • Redis 可以在 AOF 文件体积变得过大时,自动地在后台对 AOF 进行重写: 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。新 AOF 文件创建完毕后,Redis 才会从旧 AOF 文件切换到新 AOF 文件,并开始对新 AOF 文件进行追加操作。
    如:

    如果你对一个计数器调用了 100 次 INCR key , 那么仅仅是为了保存这个计数器的当前值, AOF 文件就需要使用 100 条记录(entry)。然而在实际上, 只使用一条SET key value [EX seconds] [PX milliseconds] [NX|XX]命令已经足以保存计数器的当前值了, 其余 99 条记录实际上都是多余的。

  • AOF 文件有序地保存了对数据库执行的所有写入操作, 这些写入操作以 Redis 协议的格式保存, 因此 AOF 文件的内容非常容易被人读懂, 对文件进行分析(parse)也很轻松。 导出(export) AOF 文件也非常简单: 举个例子, 如果你不小心执行了 FLUSHALL 命令, 但只要 AOF 文件未被重写, 那么只要停止服务器, 移除 AOF 文件末尾的 FLUSHALL 命令, 并重启 Redis , 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 的缺点

  • 对于相同的数据集来说,AOF 文件的体积通常要大于 RDB 文件的体积。
  • 根据所使用的 fsync 策略,AOF 的速度可能会慢于 RDB 。 在一般情况下, 每秒 fsync 的性能依然非常高, 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快, 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时,RDB 可以提供更有保证的最大延迟时间(latency)。
  • AOF 在过去曾经发生过这样的 bug : 因为个别命令的原因,导致 AOF 文件在重新载入时,无法将数据集恢复成保存时的原样。

默认情况下,redis打开RDB功能,如果想使用AOF,可以通过 CONFIG SET appendonly yes 命令设置,但这种方式在服务器重启之后, 就会被遗忘,还可以在redis.conf文件中配置 appendonly yes,这样服务器重启后,程序会按配置文件来启动服务器。RDB和AOF功能可以同时使用。

redis高可用集群

特点

支持主从同步,提供cluster集群部署模式,保证集群的高并发。通过sentinel哨兵监控Redis主服务器的状态,当主节点挂掉时,在从节点中根据一定的选举策略选出新的主节点,并调整其他从节点的新主节点为选出的新主节点。如此保证服务的高可用。

主节点选举策略主要遵循以下规则:

  1. 选择健康状态从节点(排除主观下线、断线),排除5秒钟没有心跳的、排除主节点失联超过10*down-after-millisecends
  2. 选择slave-priority高的从节点优先级列表,优先级高的最容易被选中
  3. 复制偏移量越大越容易选中,即复制的数据最多的slave最容易被选中
  4. redis节点都有一个runid,类似于身份标识,选择runid小的最容易被选中

redis-cluster采用分片机制,键空间被分割为 16384 个槽(slot),分布在所有的mater节点上,每个master节点负责一部分slot,数据操作是按照HASH_SLOT = CRC16(key) mod 16384 算法计算具体key在哪个slot上,由哪个master处理。

key的过期失效机制

key的删除分为主动删除和删除命令。

而关于过期key主动删除策略有三种:

(1)、定时删除:在设置键的过期时间的同时,创建一个定时器(timer). 让定时器在键的过期时间来临时,立即执行对键的删除操作。

(2)、惰性删除:放任键过期不管,但是每次从键空间中获取键时,都检查取得的键是否过期,如果过期的话,就删除该键;如果没有过期,就返回该键。

(3)、定期删除:每隔一段时间程序就对数据库进行一次检查,删除里面的过期键。至于要删除多少过期键,以及要检查多少个数据库,则由算法决定。

Redis实际上采用了惰性删除和定期删除两种策略配合使用。

在Redis还有一种方式会删除key,就是当达到MaxMemory触发的淘汰策略

缓存达到最大容量时,redis提供的8种淘汰策略

volatile-lru -> 从已设置过期时间的数据集中选择最久没有使用的数据淘汰
allkeys-lru -> 从数据集中选择最久没有使用的数据淘汰
volatile-lfu -> 从已设置过期时间的数据集中选择最少使用的数据淘汰
allkeys-lfu -> 从数据集中选择最少使用的数据淘汰
volatile-random -> 从已设置过期时间的数据集中随机选择数据淘汰
allkeys-random -> 从数据集中随机选择数据淘汰
volatile-ttl -> 从已设置过期时间的数据集中选择马上就要过期的数据淘汰
noeviction -> 当内存使用超过配置的时候会返回错误,不会驱逐任何键
# LRU 最近最少使用
# LFU 最近最多使用

 

展开阅读全文

没有更多推荐了,返回首页