【Redis 神秘大陆】009 案例实践进阶

2024-04-17 16:12

本文主要是介绍【Redis 神秘大陆】009 案例实践进阶,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

九、案例实践&进阶方案

9.1 本地缓存组件选型

使用缓存组件时需要重点关注集群方式、集群、缓存命中率。

  • 需要关注集群组建方式、缓存统计;还需要考虑缓存开发语言对缓存的影响,如对于JAVA开发的缓存需要考虑GC的影响;
  • 最后还要特别关注缓存的命中率,理解影响缓存命中率的因素,及如何提高缓存命中率。
对比维度EhcacheGuava Cache
设计目标与定位专注于提供高性能的分布式缓存定位于提供简单易用的内存缓存库
主要功能支持多级缓存、分布式、复杂策略等提供基础Get/Put/Remove接口
性能特点性能高,支持策略优化性能依赖实现,一般为CHM级别
缓存策略支持LRU、FIFO等多策略简单的基于大小的LRU策略
适用场景大并发、分布式项目小中型项目或简单内存缓存
配置方式XML/注解/代码配置主要通过代码配置
性能监控提供详细监控统计与MXBean仅支持简单的加载与驱逐监听
持久化能力支持磁盘等持久化 [ 冷数据的存储 ]不支持任何持久化
事务支持支持读写事务不支持事务
集成度良好地集成与Spring等框架主要作为Guava的一部分使用
社区支持活跃社区及文档支持也有一定的社区支持
配置难易度配置相对复杂配置简单易上手

9.2 本地缓存和分布式缓存的数据一致性方案

定时轮询

img

缺点:因为每台服务器定时轮询的时间点可能不一样,那么不同服务器 刷新最新缓存的时间可能也不一样,这样就会产生数据不一致的问题,对一致性要求不是很高的时候可以使用。

主动通知

img

  • 这种方案引入了消息队列,使每台应用服务器的Ehcache同步侦听MQ消息,通过MQ推送或者拉取的方式,这样在一定程度上可以达到准同步更新数据。

  • 缺点:因为不同服务器之间的网络速度的原因,所以也不能完全达到强 一致性。基于此原理使用ZooKeeper等分布式协调通知组件也是如此。

  • 先操作数据库还是先操作Redis?

  • 删除Redis还是更新Redis?

9.3 缓存的基础使用模式

  • Cache-Aside: 业务代码中管理维护缓存。缓存中间件不关联缓存和实际存储间的逻辑

    • 当前机制能够利用数据库成熟的高可用机制,数据库写成功,则进行缓存数据更新。
  • Cachs-As-SoR : 把缓存当做记录系统,真实记录的访问在 Cache 组件内部实现。细分如下:

    • Read-Through模式: 当缓存中没有查询到Key对应的Value时,会自动从后端数据源(如数据库)中加载数据放入缓存,然后再返回查询结果。这可以实现数据的预取填充。

读入缓存模式Read-Through
在这里插入图片描述

预先刷新缓存模式Refresh-Ahead

在这里插入图片描述

这是写进入缓存和数据库模式Write-Through

在这里插入图片描述

写进入缓存,后台写入数据库模式Write-Behind

在这里插入图片描述

9.4 热点数据问题

缓存穿透

缓存穿透是指查询一个根本不存在的数据,缓存层和存储层都不会命中

imgimg

  • 内存风险:空值做了缓存意味着缓存层中存了更多的键,需要更多的内存空间。如果是攻击,问题更严重。有效的方法是针对这类数据设置一个较短的过期时间,让其自动剔除。
  • 数据一致性风险:缓存层和存储层的数据会有一段时间窗口的不一致,可能会对业务产生影响。例如,过期时间设置为5分钟,如果此时存储层添加了这个数据,那么在这段时间内就会出现缓存层和存储层数据的不一致。可以利用消息系统或者其他方式清除掉缓存层中的空对象,以保持数据一致性。
  • 防御机制: 使用 IDS | IPS 入侵检测和入侵防御系统来解决

img

使用 布隆过滤器来拦截,不推荐使用 ,推荐使用 布谷过滤器 、

布隆过滤器他的容量有上限且无法扩容

img

缓存雪崩

缓存崩了导致流量都达到了 DB 层。

img

  1. 保证缓存服务的高可用
  2. 依赖隔离组件为后端限流和降级【sentinel】
  3. 提前演练

热点 Key

img

Big Key

  • 内存空间不均匀(平衡):例如在Redis Cluster中,bigkey会造成节点 的内存空间使用不均匀。
  • 超时阻塞:由于Redis单线程的特性,操作bigkey比较耗时,也就意味 着阻塞Redis可能性增大。
  • 网络阻塞: 每次获取bigkey产生的网络流量较大,假设一个bigkey为 1MB,每秒访问量为1000,那么每秒产生1000MB的流量,带宽被占满。

发现:

  • 被动发现: 客户端当抛出异常时打印出所操作的key
  • 主动监测: scan+debug object:如果怀疑存在bigkey,可以使用scan命 令渐进的扫描出所有的key,分别计算每个key的serializedlength,找到对应 bigkey进行相应的处理和报警,这种方式是比较推荐的方式。

解决:

  • 拆分复杂数据结构:如果当前key的类型是一个二级数据结构,例如 哈希类型。如果该哈希元素个数较多,可以考虑将当前hash进行拆分,这样 该热点key可以拆分为若干个新的key分布到不同Redis节点上,从而减轻压 力。
  • 迁移热点key:以Redis Cluster为例,可以将热点key所在的slot单独 迁移到一个新的Redis节点上,但此操作会增加运维成本。
  • 本地缓存加通知机制:可以将热点key放在业务端的本地缓存中,因 为是在业务端的本地内存中,处理能力要高出Redis数十倍,但当数据更新 时,此种模式会造成各个业务端和Redis数据不一致,通常会使用发布订阅 机制来解决类似问题。

批量热点数据过过期

使用延迟消息分批失效

9.5 不过期缓存和过期缓存的选择

不过期缓存场景:

  • 适用场景:数据访问频率高、数据一致性要求较低、数据量不是很大的场景。

  • 思路:采用Cache-Aside模式,即先写数据库,成功后再写入缓存。如果对缓存数据一致性要求不高,可以考虑定期全量同步缓存。

  • 注意事项

  • 不要将写缓存放在事务中,尤其是写入分布式缓存,以免由于网络抖动导致数据库事务阻塞。

  • 对于频繁查询的业务(如商品查询),不适合先删缓存再执行数据库事务的方式,因为可能存在事务未提交而另一个系统已经读取缓存的情况。

  • 可以考虑使用订阅数据库日志的架构(如使用canal订阅MySQL的binlog)来实现缓存同步,以解决多个事务并发问题。

  • 应用场景示例:用户、分类、商品、价格、订单等数据,当缓存空间充足时可以考虑不过期缓存,使用LRU机制驱逐老的缓存数据。

过期缓存机制:

  • 适用场景:缓存其他系统的数据、缓存空间有限、低频热点缓存等场景。

  • 思路:采用懒加载方式,即首先读取缓存,若不命中则查询数据,然后异步写入缓存并设置过期时间,下次读取将命中缓存。

  • 注意事项

  • 针对热点数据,可在应用系统上设置较短的缓存时间。

  • 数据可能存在一段时间的不一致情况,需要根据场景来决定如何设置过期时间。

  • 应用场景示例:库存数据

多级缓存架构

在这里插入图片描述

9.6 Redis 常用运维方式

大集群 | 多集群部署

缓存部署方式部署方式优点缺点
统一大集群方式部署将所有Redis集中在一起,形成一个超大的Redis集群,通过代理统一对外提供连接。扩容方便,对使用者无感知;利用率高,运维简单;客户端使用方便,透明。(可以简单地认为链接上了一个内 存无限大的Redis)无法实时计算项目配额,导致资源浪费;热点数据可能导致某个节点不可用。
多集群分散式部署各个Redis相互独立部署,各项目独占一个Redis,隔离性好。隔离性好,项目之间互不影响;灵活性高,可根据项目定制部署。部署麻烦,需单独针对项目部署;(各个项目的定制又各有 不同)客户端使用复杂,需要处理不同Redis的连接。(停机维护需要客户端感知)
问题描述基本解决思路详细解决方案
部署问题: 部署Redis集群通常需要耗费大量时间和精力,手动操作容易出错,而且随着集群规模的增大,管理难度也会增加实现自动化部署方式,一键部署Redis。使用配置管理工具(如Ansible、Chef、Puppet)编写部署脚本,实现自动化部署Redis的功能。设计部署流程,包括配置管理、监控等方面,确保部署的稳定性和可靠性。
监控问题: 管理大量的Redis实例和主机需要一个有效的监控系统,以便及时发现和解决性能问题、异常情况等。建立对大量Redis及所在主机的监控体系,提供状态查询和监控。部署监控系统(如Zabbix、Nagios、Prometheus)实时监测Redis集群和主机的状态、性能、负载等情况。设置警报机制,通过邮件、短信等方式及时发现和处理异常情况。
客户端使用问题: 不同项目使用不同的Redis实例,客户端需要手动配置和管理连接信息,容易出错且不便于维护。简化客户端使用,避免修改配置和重新上传。提供统一的接入层或配置管理服务(如ZooKeeper、Consul),客户端通过统一接口访问,无需手动修改配置。提供详细的接入文档和技术支持,协助客户端快速接入和使用。
运维问题: Redis本身是一个小工具,但在实际应用中需要综合考虑监控、诊断、日志分析、自动化运维等方面的问题,需要相应的工具和技术支持。提供分析和运维工具,简化Redis运维流程。开发或集成运维工具,包括监控、诊断、日志分析、自动化运维等功能(如RedisInsight、Redis Desktop Manager、Redis Commander)。提供培训和技术支持,帮助运维人员更好地管理和维护Redis。

Docker 化部署

img

重点描述
部署方式使用Docker来解决Redis的部署问题。基于Docker的自动化运维平台,通过Docker的RESTful API进行操作,使得新机器配置后可以直接进行自动化部署。
优点部署快捷方便,通过Docker的自动化运维平台可以轻松进行部署操作。Docker提供了API接口,完全够用,避免了使用kubernetes增加的复杂度。
缺点Redis的网卡容易打满,对网络流量的控制需要使用定制的网络插件,如Contiv netplugin,进行限制和监控。Redis的内存问题较为复杂,内存控制需要考虑used_memory和used_memory_rss等参数,并避免碎片问题导致的内存溢出。
解决方案CPU控制:使用Docker隔离分配进行CPU控制。内存控制:通过自己的监控程序进行内存控制,根据策略进行内存扩容,同时采用数据压缩算法减少Redis的内存占用。网卡控制:使用Contiv netplugin限制Redis的网络流量,确保不同项目之间的网络互不干扰。运维自动化:使用自动化运维平台和监控系统,提高部署效率、监控系统稳定性,自动化管理客户端连接信息和运维工作。

9.7 基于 CacheCloud 管理 Redis

https://github.com/sohutv/cachecloud

img

自建基础方案设计:

场景示例

Canel

  • 数据预热: 提前把数据读入到缓存

  • 监控机制: 需要通过监控机制确保预热数据都写成功了

  • 容量评估: 需要评估容量是否允许预热全量数据

  • 数据库性能: 语句是否会影响批量数据库操作或者慢 SQL 引发数据库性能问题

  • 回滚方案: 紧急回滚便于操作,包括降级开关的设计

  • 冷热集群处理: 新建的集群可以先从冷集群中获取 Key,如果获取不到,再从热集群获取,最后回天到冷集群

  • 核心流程:

  • 读取缓存:首先尝试从缓存中读取数据。

  • 缓存命中:如果缓存命中,则直接返回缓存数据。

  • 缓存未命中:如果缓存未命中,则需要查询数据源获取数据。

  • 异步写入缓存:获取数据后,将其异步写入缓存中。这样可以降低读取延迟,并且不会阻塞当前请求的处理。

  • 设置过期时间:在写入缓存时,设置合适的过期时间。过期时间的选择需要根据业务场景和数据特性来决定。

  • 下次读取命中缓存:下次相同的请求再次访问时,如果在过期时间内,则缓存命中,否则继续从数据源获取数据。

  • 注意事项:

  • 数据不一致性:由于缓存数据的过期时间,可能导致一段时间内缓存中的数据与数据源不一致。因此,需要根据业务场景权衡数据一致性和性能要求,合理设置过期时间。

  • 短暂数据一致性问题:对于一些短时间内不一致的数据,可以在业务上忽略或者通过其他手段进行弥补,比如在前端应用上缓存几秒钟的数据,因为这样的短暂不一致是可以被忍受的。

  • 缓存清理策略:需要定期清理过期缓存数据,释放缓存空间。通常可以采用LRU(最近最少使用)等策略来淘汰最近最少使用的缓存数据。


当你发现这些内容对你有帮助时,为了支持我的工作,不妨给一个免费的⭐Star,这将是对我最大的鼓励!感谢你的陪伴与支持!一起在技术的路上共同成长吧!点击链接:GitHub | Gitee

这篇关于【Redis 神秘大陆】009 案例实践进阶的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/912265

相关文章

Spring Security 从入门到进阶系列教程

Spring Security 入门系列 《保护 Web 应用的安全》 《Spring-Security-入门(一):登录与退出》 《Spring-Security-入门(二):基于数据库验证》 《Spring-Security-入门(三):密码加密》 《Spring-Security-入门(四):自定义-Filter》 《Spring-Security-入门(五):在 Sprin

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

Hadoop企业开发案例调优场景

需求 (1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。 (2)需求分析: 1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster 平均每个节点运行10个 / 3台 ≈ 3个任务(4    3    3) HDFS参数调优 (1)修改:hadoop-env.sh export HDFS_NAMENOD

Java进阶13讲__第12讲_1/2

多线程、线程池 1.  线程概念 1.1  什么是线程 1.2  线程的好处 2.   创建线程的三种方式 注意事项 2.1  继承Thread类 2.1.1 认识  2.1.2  编码实现  package cn.hdc.oop10.Thread;import org.slf4j.Logger;import org.slf4j.LoggerFactory

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于

零基础学习Redis(10) -- zset类型命令使用

zset是有序集合,内部除了存储元素外,还会存储一个score,存储在zset中的元素会按照score的大小升序排列,不同元素的score可以重复,score相同的元素会按照元素的字典序排列。 1. zset常用命令 1.1 zadd  zadd key [NX | XX] [GT | LT]   [CH] [INCR] score member [score member ...]

【区块链 + 人才服务】可信教育区块链治理系统 | FISCO BCOS应用案例

伴随着区块链技术的不断完善,其在教育信息化中的应用也在持续发展。利用区块链数据共识、不可篡改的特性, 将与教育相关的数据要素在区块链上进行存证确权,在确保数据可信的前提下,促进教育的公平、透明、开放,为教育教学质量提升赋能,实现教育数据的安全共享、高等教育体系的智慧治理。 可信教育区块链治理系统的顶层治理架构由教育部、高校、企业、学生等多方角色共同参与建设、维护,支撑教育资源共享、教学质量评估、

客户案例:安全海外中继助力知名家电企业化解海外通邮困境

1、客户背景 广东格兰仕集团有限公司(以下简称“格兰仕”),成立于1978年,是中国家电行业的领军企业之一。作为全球最大的微波炉生产基地,格兰仕拥有多项国际领先的家电制造技术,连续多年位列中国家电出口前列。格兰仕不仅注重业务的全球拓展,更重视业务流程的高效与顺畅,以确保在国际舞台上的竞争力。 2、需求痛点 随着格兰仕全球化战略的深入实施,其海外业务快速增长,电子邮件成为了关键的沟通工具。

[MySQL表的增删改查-进阶]

🌈个人主页:努力学编程’ ⛅个人推荐: c语言从初阶到进阶 JavaEE详解 数据结构 ⚡学好数据结构,刷题刻不容缓:点击一起刷题 🌙心灵鸡汤:总有人要赢,为什么不能是我呢 💻💻💻数据库约束 🔭🔭🔭约束类型 not null: 指示某列不能存储 NULL 值unique: 保证某列的每行必须有唯一的值default: 规定没有给列赋值时的默认值.primary key: