Redis第一关之常规用法

这篇具有很好参考价值的文章主要介绍了Redis第一关之常规用法。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

简介

Redis不用多说,已经火了很多年了,也用了很多年了。现在做一些归纳总结。
这篇文章主要介绍Redis的常规知识及用法,包括数据结构、使用场景、特性、过期机制、持久化机制。

Redis与Mysql

Mysql是一款基于磁盘的关系型SQL数据库。
Redis是一款基于内存的、非关系型、Nosql数据库,

Mysql的基本构成结构是二维表,由行和列组成。
Redis的数据存储形式是Key-Value结构,由键和值组成。

相较于传统的RDBMS数据库,NOSQL数据库更满足Web2.0时代数据爆炸式需求。不需要固定的格式,严格的关系,提供高并发性能等等。单NOSQL并不能完全取代传统数据库,因此,RDBMS+NOSQL是最好的方式。

下面具体来分析Redis的数据结构

Redis数据结构

Redis是Key-Value结构,Key值都是单字符串,Value也是字符串,但却有9种数据类型,分别如下:

  1. String(字符串)
  2. List(链表)
  3. Set(无序集合)
  4. ZSet(有序集合)
  5. Hash(哈希)
  6. Geo 地理位置
  7. Bitmaps 位图
  8. HyperLogLog 基数统计

除了最后三种特殊数据结构外,常用的5种数据结构可以按类型分类。

1. 按单、多个字符串分类:
String为单个字符串结构
List、Set、Zset、Hash为多字符串结构

2. 在多字符串结构中,再按有序、无序分类
List、ZSet为有序数据结构,其中List底层为链表结构,以插入顺序排序。ZSet通过分数Score来排序。
Set、Hash为无序数据结构,其中Set为无序唯一性集合,会自动去重。

Hash数据结构是以field-value形式,非常适合存储对象结构。同时支持对对象属性的增删。
Redis第一关之常规用法,redis,数据库,缓存

Redis应用场景

Redis作为Web2.0时代受欢迎的产物,其基于内存的高性能、过期机制、特殊的数据结构都分别决定了它的用途广泛。

Redis第一关之常规用法,redis,数据库,缓存

缓存应用的三大问题

缓存击穿

概念: 缓存将某个或小面积热Key击穿,
造成原因:误操作、缓存过期
解决办法:暂时设置永不过期、增加热点监控

缓存穿透

概念: 请求穿过了缓存,直达缓存后的数据库层,大并发下容易造成数据库宕机,从而影响全局。
造成原因:大并发请求,缓存层未命中,黑客攻击等
解决办法:增加数据有效性校验,对不存在的数据进行Null值缓存,使用布隆过滤器。

缓存雪崩

概念:大面积缓存的key值在同一时间段都未命中
造成原因:key值过期时间过于集中,或者Redis宕机。
解决办法:分散key值得过期时间,通过随机数加权计算。增加Redis高可用性。 

过期时间

在Redis中,很多场景可以通过过期机制来实现。比如短信验证码、七天免登录等。
但是Redis中允许key不设置过期时间,这会让key值永不过期,占用内存。如果不是特殊设计不建议这样使用。

关于Redis的设计缺陷及补丁措施思考

Redis是一款基于内存的数据库,其目的是为了满足快速处理的高并发特性。
但是内存是有物理局限的,它无法像硬盘一样容量可以扩充到很大,也容易受到断电丢失数据影响。
Redis第一关之常规用法,redis,数据库,缓存

因此,Redis作者又做了几个补丁。

补丁一:过期机制

如果Redis没有过期机制?

那么意味着,所有存入到内存的数据都是永不过期的,使用完了就得删除,这像是 C++语言开发,而过期机制相当于Java的内存回收机制,操作起来更柔性。

过期机制的底层原理?

Redis内部采用的是定期删除+惰性删除,两种机制相配合保证了最终一定被删除。

定期删除
设置了定时器,每次会取出一部分过期的key进行删除。

为什么不是轮询全部过期的key值?

因为如果内存较大,过期的key值较多,轮询比较耗时,会消耗大量的CPU在轮询上。

那么,未被取出的过期key值如何删除?

惰性删除
惰性删除,类似于java中的类的懒加载,Spring IOC对象的懒加载。
未被定期删除策略命中的过期key,只有当这个key再次被访问时来判断是否要删除。

因此,定期删除+惰性删除策略,一定会删除所有过期的key,但是有一个时间差问题。

某个key值过期了,它的最快删除时间是定期任务第一次扫描就被取出来并删除。它的最慢删除时间是…很久,这取决于定期删除是怎么取出数据的了。

Redis第一关之常规用法,redis,数据库,缓存

虽然这些过期的key最终会被删除,但Redis内存容量总是动态变化的,不断的有增量Key,也有不断的删除Key。

Redis第一关之常规用法,redis,数据库,缓存
如果:

增量速度 > 删除速度,删除速度>=0(等于0时所有的key都未过期)

Redis内存就会膨胀,逐渐趋于饱和。这时候,那些未被及时删除的过期Key就亟需被找到并删除掉了,作者怎么做的呢?

内存淘汰策略

当出现上述情况时,作者设计了一种内存淘汰机制,使用者可以不同的策略来清理内存,保证Redis能否正常使用。

1. volatile-lru(least recently used) 从设置了过期时间的数据中(server.db[i].expires) 淘汰最近最少被使用的数据。
2. volatile-random 从设置了过期时间的数据中 随机淘汰数据。
3. volatile-lfu 从设置了过期时间的数据中 淘汰最不频繁被使用的数据。

4. allkeys-lru 从所有的数据中(server.db[i].dict) 淘汰最近最少被使用的数据。- 常用
5. allkeys-random 从所有的数据中(server.db[i].dict)随机淘汰数据。
6. allkeys-lfu 从所有的数据中(server.db[i].dict)淘汰最不频繁被使用的数据。

7. volatile-ttl 从设置了过期时间的数据中(server.db[i].expires)淘汰将要过期的数据。
8. no-eviction 禁止淘汰数据。

补丁二: 持久化机制

Redis毕竟是基于内存的数据库,如果断电了肯定会导致数据丢失。所以设计持久化机制是必然的。

作者设计了两种持久化机制:AOF、RDB

AOF持久化

AOF是一种以记录实时日志的方式,将Redis的每个操作命令持久化,其优点是实时性比较强,可以每秒钟记录一次,其缺点是产生的日志量较大,重启恢复时的耗时较长。

RDB持久化

RDB是一种全量备份模式,将Redis中的所有数据全部备份下来,可以实现备份和迁移。
其优点是产生的数据量较小,重启时可以快速的恢复,其缺点是实时性较弱,容易产生数据丢失。

RDB持久化时,如果发生在Redis运行中,由于数据是动态变化的,因此常见的备份方式是将Redis其他操作阻塞,直到全量备份完成在放行,另一种方式是Redis作者提供的异步备份。

1. 同步备份 save
2. 异步备份 bgsave

异步备份是bgsave命令,其原理是在主进程中fork一个子进程异步执行,不会阻塞主进程操作。

Redis高可用设计

Redis提供了高可用设计,分别是主从模式、哨兵模式、集群模式。

主从模式
Redis数据库的主从模式和Mysql数据库的主从模式类似,都是以容灾备份为目的设计的,因此当Redis主结点发生故障时,可手动切换为从结点提供服务。
主从模式需要两个Redis结点。

哨兵模式

虽然主从模式可以提供容灾备份的功能,但是当发生故障时,需要手动切换,并不智能。 于是,哨兵模式解决了这个问题。

哨兵模式通过哨兵集群监控所有Redis结点,让主结点发生故障时,自动将主节点踢出,然后重新选择一个从节点作为主节点提供服务,保证了高可用性。
哨兵模式最大的优点是故障自动转移,但至少需要3个Redis结点。

群集模式

群集模式提供了Redis分布式数据存储功能,由于单机内存上限的限制,群集模式解决了这个问题,通过数据分片的形式将Redis数据分散到多个结点,实现容量的横向扩展,每个主结点都需要配置一个从结点作为数据容灾备份,以便故障自动转移。
Redis群集模式一般需要3主3从,共6个Redis结点。文章来源地址https://www.toymoban.com/news/detail-831124.html

到了这里,关于Redis第一关之常规用法的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • redis的缓存更新策略以及如何保证redis与数据库的数据一致性

    redis的缓存更新策略有这么几种: 1、由应用直接和redis以及数据库相连接:         查询数据时,应用去redis中查询,查不到的话再由应用去数据库中查询,并将查询结果放在redis;         更新数据时,由应用去触发redis数据的删除以及数据库的update。 2、应用只跟redi

    2024年02月13日
    浏览(57)
  • Redis如何保证缓存和数据库一致性?

    现在我们在面向增删改查开发时,数据库数据量大时或者对响应要求较快,我们就需要用到Redis来拿取数据。 Redis:是一种高性能的内存数据库,它将数据以键值对的形式存储在内存中,具有读写速度快、支持多种数据类型、原子性操作、丰富的特性等优势。 优势: 性能极高

    2024年01月16日
    浏览(70)
  • Redis---数据库和缓存如何保证一致性?

    用「读 + 写」请求的并发的场景来分析: 假如某个用户数据在缓存中不存在,请求 A 读取数据时从数据库中查询到年龄为 20,在未写入缓存中时另一个请求 B 更新数据。它更新数据库中的年龄为 21,并且清空缓存。这时请求 A 把从数据库中读到的年龄为 20 的数据写入到缓存

    2024年01月24日
    浏览(57)
  • Redis如何保障缓存与数据库的数据一致性问题?

    目录 一.最经典的数据库加缓存的双写双删模式 二. 高并发场景下的缓存+数据库双写不一致问题分析与解决方案设计 三、上面高并发的场景下,该解决方案要注意的问题 1.1 Cache Aside Pattern概念以及读写逻辑 (1)读的时候,先读缓存,缓存没有的话,那么就读数据库,然后取

    2023年04月21日
    浏览(49)
  • 数据库缓存服务——NoSQL之Redis配置与优化

    目录 一、缓存概念 1.1 系统缓存 1.2 缓存保存位置及分层结构 1.2.1 DNS缓存 1.2.2 应用层缓存 1.2.3 数据层缓存 1.2.4 硬件缓存 二、关系型数据库与非关系型数据库 2.1 关系型数据库 2.2 非关系型数据库 2.3 关系型数据库和非关系型数据库区别: 2.4 非关系型数据库产生背景 2.5 总结

    2024年02月15日
    浏览(50)
  • Redis数据库 | 发布订阅、主从复制、哨兵模式、缓存雪崩

    💗wei_shuo的个人主页 💫wei_shuo的学习社区 🌐Hello World ! Redis 发布订阅 (pub/sub) 是一种消息通信模式:发送者 (pub) 发送消息,订阅者 (sub) 接收消息 Redis 客户端可以订阅任意数量的频道 Redis主从复制是指在Redis中设置一个主节点(Master)和一个或多个从节点(Slave),

    2024年02月15日
    浏览(57)
  • Springboot+Redis:实现缓存 减少对数据库的压力

    🎉🎉欢迎光临,终于等到你啦🎉🎉 🏅我是苏泽,一位对技术充满热情的探索者和分享者。🚀🚀 🌟持续更新的专栏 Redis实战与进阶 本专栏讲解Redis从原理到实践 这是苏泽的个人主页可以看到我其他的内容哦👇👇 努力的苏泽 http://suzee.blog.csdn.net/   目录 缓存如何实现?

    2024年03月24日
    浏览(59)
  • redis面试题目-如何保证数据库与缓存的数据一致性

    原视频:https://www.bilibili.com/video/BV1Km4y1r75f?p=62vd_source=fa75329ae3880aa55609265a0e9f5d34 由于缓存和数据库是分开的,无法做到原子性的同时进行数据修改,可能出现缓存更新失败,或者数据库更新失败的情况,这时候会出现数据不一致,影响前端业务 先更新数据库,再更新缓存。缓

    2024年02月05日
    浏览(64)
  • Redis缓存MySQL数据库存储二者如何保证数据一致性

    在大型互联网应用中,由于数据库读写频繁、压力大等原因,我们通常会使用缓存来减少数据库的访问次数,提高系统的性能。而Redis作为一个高性能的内存数据库,成为了缓存的首选方案之一。但是,缓存和数据库之间存在数据一致性的问题,如何解决这个问题呢?本文将

    2023年04月19日
    浏览(52)
  • 如何保证Redis缓存和数据库的一致性问题

    熟练掌握Redis缓存技术? 那么请问Redis缓存中有几种读写策略,又是如何保证与数据库的一致性问题 今天来聊一聊常用的三种缓存读写策略 首先我们来思考一个问题 写 先更新缓存 再更新数据库 首先如果缓存更新成功但数据库更新失败,会导致数据不一致的问题 其次当请求

    2024年02月14日
    浏览(51)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包