微服务实践01--微服务管理11--缓存00--概述

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
MSE Nacos/ZooKeeper 企业版试用,1600元额度,限量50份
云原生网关 MSE Higress,422元/月
简介: 微服务实践01--微服务管理11--缓存00--概述

微服务实践目录,可以参见连接。

缓存系列包括:
1.微服务管理-11.缓存概述
1.微服务管理-11.缓存-0.技术
1.微服务管理-11.缓存-1.多级缓存设计
1.微服务管理-11.缓存-2.典型缓存架构设计
1.微服务管理-11.缓存-3.实践
[1.微服务管理-11.缓存-4.总结]()

背景

从冯诺依曼体系结构开始计算机就开始考虑处理速度与存储之间的关系。对于缓存来说在CPU中加入缓存的时候是为了解决速度与存储的不协调问题。通过将常用的数据、下一条CPU指令加载到CPU的Cache中而加快因为数据总线读取数据造成的时延。以这种方式减少因为数据读取对处理时间的延时的情况,提高CPU计算时间片使用率。从而提高CPU的处理速度。从这里可以看到缓存的出现就是为了充分体现CPU的处理速度而设计的。

而我们现在经常提到对的缓存是在业务系统层面。基本上已经不考虑CPU的寻址、读取数据的时间了。业务系统中的缓存是随着计算机系统在人们生活中不断的发挥作用。业务系统不断的需要快速的反馈,而业务的处理消耗的时间慢慢的不能被使用者所接受。所以人们开始考虑怎样加快系统的返回时间,人们开始将CPU上的Cache的概念引入到业务系统中。

前人分析计算机系统其实可以分为计算密集型系统和IO密集型系统。对于这两种系统的缓存要求也是不一样的。对于计算密集型系统就像上面所说的缓存需要解决的问题是加快数据读取的速度。对于IO密集型来说系统系统是需要快速检索,并快速聚合。

那么对于现在的大型互联网系统来说应该是计算密集型系统还是IO密集型系统呢?针对这个问题,我的定义是IO密集型系统。具体原因是:对于互联网系统来说最多要操作的是CURD。所以说互联网系统是IO密集型系统。而IO密集型系统又可以分为读密集型和写密集型。而我再把互联网系统定义为IO读密集型系统。

  • IO读密集型系统

对于作者认为互联网系统是IO读密集型系统来说,可能大家不认同。作者在这里举两个例子。

报表系统对于业务系统来说是一个比较常见的部分。报表系统最直观的看法是他是一套计算密集型系统。简单的报表系统对于程序员来说就是查询并且根据计算条件计算出结果并输出。而对于架构师来说这个不可能让程序每次都读取并且占用数据库连接的情况下进行报表操作。对于报表系统来说比较简单的处理方式是报表数据库和业务数据库分离。如果是比较完善体系可以引入OLAP的概念做WD完成报表的内容。如果使用简单的方式的话,分析报表建立维度表,然后以预处理的方式将数据存储在预处理表中。在需要展示时可以直接从维度表或维度表的聚合中获取数据。

工作流管理系统对于业务系统来说系统中查看工作流中数据的地方比产生、修改这部分数据的地方多的多。而且一个工作流管理系统的计算量明显会更小。

个性化推荐系统对于业务系统来说,简单来说就是一个数据源。对于业务系统来说不关心个性推荐系统中的算法,模型等内容。而个性化推荐系统只需要将计算后的数据交付给业务系统即可。

针对这几个例子我们可以简单的认为大部分互联网系统都是IO读密集型系统。

  • 概述

对于IO读密集型的互联网系统来说,缓存需要处理那些问题?这里列出要处理的问题,并会在说明这些问题处理方式时说明为什么这些问题需要处理。

  • 缓存位置
  • 缓存数据规则
  • 缓存失效策略
  • 缓存序列化与容量
  • 缓存类型

下面会以重要性的顺序进行说明。

缓存数据规则

对于系统中会怎样认为那些数据?应该像CPU那样缓存程序代码段的指令还是缓存代码指令所要使用的数据?这个部分可以分为:过程数据规则、数据特征规则。过程数据规则说明应该缓存那些数据。

  • 缓存过程数据规则

过程数据是在处理过程中的数据。对于过程中的数据是从原始的数据源中读取开始到真正的从接口返回的数据。这里可以分为:

  • 缓存原始数据
    从数据源(一般是数据库)中读取过来的数据。
  • 缓存半成品数据
    从数据源读取之后,进行了部分聚合的情况下的半成品数据。(对于微服务架构模式来说前台服务就是作为数据、服务能力聚合而做的。所以经常性的数据聚合会在前台中完成。)
  • 缓存成品数据
    半成品再次聚合成为成品数据。使数据可以直接返回。

这些数据经常会在我们服务中发现。这里先说规则缓存的数据应该是最接近成品数据的数据。根据我们在背景中说明的互联网系统中最主要的是IO读密集型系统。所以,需要进行数据已最快的速度进行返回。让系统可以以最快的速度进行返回。

不过在缓存数据过程中可能会放因为缓存的问题造成接口响应时间抖动的情况。在这个过程中应尽量的减小影响响应时间方差的处理。

  • 缓存粒度规则

缓存一般情况下是Key-Value型数据库,Key的个数其实也影响缓存性能。也影响需要聚合的数据服务过程。通常情况下,缓存的粒度越小,命中率会越高;但是也需要考虑我们在用户QPS放大到缓存QPS的问题。一般情况下缓存放大倍数不应该超过2倍,这个会影响系统的稳定性。

  • 缓存数据特性规则

现在大家对于缓存数据的主要考虑点就是根据数据特性进行缓存。主要考虑的内容是使用频繁度+数据大小。

/ 频繁 不频繁
大量
少量

缓存最大的特点是需要加快访问速度。也就是需要对于热点数据进行加速,所以,不管是大量的还是少量的都需要进行缓存。

缓存技术

缓存技术在下一篇缓存技术中进行详细介绍。这里主要说明一些在记性技术选择时,需要考虑到的内容。

  • 分布式
  • 堆内、堆外
  • 持久化
  • 换出策略
  • 分级支持
  • 缓存大小
  • 命中率
  • 缓存过期策略
  • 并发支持
  • 性能

缓存失效

先说结论:最终目标设计缓存永不失效的缓存系统。可以通过CQRS模式,事件驱动模式,命令控制环路模式等架构模式设计成一个永不失效的系统。这样可以设计出的系统绝对不会遇到缓存雪崩,缓存批量加载问题。

缓存换出策略:

FIFO、LFU、LRU、ARC、MRU等策略。换出策略时常跟分布式缓存数据再均衡策略有关。在设计与使用缓存技术时需要考虑。

缓存序列化与容量

序列化技术与容量是有关的。Serializable、Json、Hessian、Protobuf、Thrift等。缓存的序列化技术考虑版本化反序列化能力,序列化后大小,序列化性能等。之后的技术选型文章中说明。

缓存相关内容

编号 工作 说明
1 缓存初始化 缓存初始化触发时间是需要考虑的。通过事件制,还是启动加载?
2 缓存过期 过期策略。我坚实的相信不能绝对不要。
3 缓存更新 通过事件更新,以补偿机制保证一致性。
4 缓存过期时间更新 这里主要是负责在不更新缓存内容的情况下更新缓存过期时间。在IoT设备上经常会用到看门狗,其实更新缓存过期时间也有类似的作用

缓存位置:

缓存的位置包括很多。从整个互联网系统通用架构的最前端到最后端的方式进行技术缓存位置说明:

  • 搜索服务
  • 浏览器
  • CDN
  • WEB服务器
  • 中间件(消息中间件,数据库中间件等)
  • 服务的高速缓存
  • 数据库查询缓存
  • CPU的cache

总结

前几天总结了一句话:同样的Dubbo、同样的Spring Cloud有些公司能实现到几万QPS,几十万QPS,而有些公司只能实现几十的QPS。映射到缓存上有些系统即使用了缓存也就是那么几十的QPS怎么解决?

本文中更多的是解决高性能的问题。而不是简单的解决该怎么用缓存。下一篇文章会专门的介绍缓存技术。

参考:

聊聊MyBatis缓存机制
如何优雅的设计和使用缓存?
缓存技术原理浅析
java序列化框架对比

目录
相关文章
|
1月前
|
弹性计算 关系型数据库 微服务
基于 Docker 与 Kubernetes(K3s)的微服务:阿里云生产环境扩容实践
在微服务架构中,如何实现“稳定扩容”与“成本可控”是企业面临的核心挑战。本文结合 Python FastAPI 微服务实战,详解如何基于阿里云基础设施,利用 Docker 封装服务、K3s 实现容器编排,构建生产级微服务架构。内容涵盖容器构建、集群部署、自动扩缩容、可观测性等关键环节,适配阿里云资源特性与服务生态,助力企业打造低成本、高可靠、易扩展的微服务解决方案。
1418 9
|
5月前
|
缓存 NoSQL Java
Redis:现代服务端开发的缓存基石与电商实践-优雅草卓伊凡
Redis:现代服务端开发的缓存基石与电商实践-优雅草卓伊凡
122 5
Redis:现代服务端开发的缓存基石与电商实践-优雅草卓伊凡
|
4月前
|
存储 缓存
.NET 6中Startup.cs文件注入本地缓存策略与服务生命周期管理实践:AddTransient, AddScoped, AddSingleton。
记住,选择正确的服务生命周期并妥善管理它们是至关重要的,因为它们直接影响你的应用程序的性能和行为。就像一个成功的建筑工地,工具箱如果整理得当,工具选择和使用得当,工地的整体效率将会大大提高。
169 0
|
6月前
|
Cloud Native Serverless 流计算
云原生时代的应用架构演进:从微服务到 Serverless 的阿里云实践
云原生技术正重塑企业数字化转型路径。阿里云作为亚太领先云服务商,提供完整云原生产品矩阵:容器服务ACK优化启动速度与镜像分发效率;MSE微服务引擎保障高可用性;ASM服务网格降低资源消耗;函数计算FC突破冷启动瓶颈;SAE重新定义PaaS边界;PolarDB数据库实现存储计算分离;DataWorks简化数据湖构建;Flink实时计算助力风控系统。这些技术已在多行业落地,推动效率提升与商业模式创新,助力企业在数字化浪潮中占据先机。
368 12
|
8月前
|
监控 Kubernetes Cloud Native
基于阿里云容器服务Kubernetes版(ACK)的微服务架构设计与实践
本文介绍了如何基于阿里云容器服务Kubernetes版(ACK)设计和实现微服务架构。首先概述了微服务架构的优势与挑战,如模块化、可扩展性及技术多样性。接着详细描述了ACK的核心功能,包括集群管理、应用管理、网络与安全、监控与日志等。在设计基于ACK的微服务架构时,需考虑服务拆分、通信、发现与负载均衡、配置管理、监控与日志以及CI/CD等方面。通过一个电商应用案例,展示了用户服务、商品服务、订单服务和支付服务的具体部署步骤。最后总结了ACK为微服务架构提供的强大支持,帮助应对各种挑战,构建高效可靠的云原生应用。
|
9月前
|
搜索推荐 NoSQL Java
微服务架构设计与实践:用Spring Cloud实现抖音的推荐系统
本文基于Spring Cloud实现了一个简化的抖音推荐系统,涵盖用户行为管理、视频资源管理、个性化推荐和实时数据处理四大核心功能。通过Eureka进行服务注册与发现,使用Feign实现服务间调用,并借助Redis缓存用户画像,Kafka传递用户行为数据。文章详细介绍了项目搭建、服务创建及配置过程,包括用户服务、视频服务、推荐服务和数据处理服务的开发步骤。最后,通过业务测试验证了系统的功能,并引入Resilience4j实现服务降级,确保系统在部分服务故障时仍能正常运行。此示例旨在帮助读者理解微服务架构的设计思路与实践方法。
460 17
|
8月前
|
监控 Cloud Native Java
基于阿里云容器服务(ACK)的微服务架构设计与实践
本文介绍如何利用阿里云容器服务Kubernetes版(ACK)构建高可用、可扩展的微服务架构。通过电商平台案例,展示基于Java(Spring Boot)、Docker、Nacos等技术的开发、容器化、部署流程,涵盖服务注册、API网关、监控日志及性能优化实践,帮助企业实现云原生转型。
|
10月前
|
消息中间件 运维 安全
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的灵活性和可扩展性,成为众多企业重构后端系统的首选方案。本文将深入探讨微服务的核心概念、设计原则、关键技术选型及在实际项目实施过程中面临的挑战与解决方案,旨在为开发者提供一套实用的微服务架构落地指南。我们将从理论框架出发,逐步深入至技术细节,最终通过案例分析,揭示如何在复杂业务场景下有效应用微服务,提升系统的整体性能与稳定性。 ####
194 32
|
10月前
|
消息中间件 运维 API
后端开发中的微服务架构实践####
本文深入探讨了微服务架构在后端开发中的应用,从其定义、优势到实际案例分析,全面解析了如何有效实施微服务以提升系统的可维护性、扩展性和灵活性。不同于传统摘要的概述性质,本摘要旨在激发读者对微服务架构深度探索的兴趣,通过提出问题而非直接给出答案的方式,引导读者深入
175 1
|
10月前
|
Cloud Native API 持续交付
云原生架构下的微服务治理策略与实践####
本文旨在探讨云原生环境下微服务架构的治理策略,通过分析当前面临的挑战,提出一系列实用的解决方案。我们将深入讨论如何利用容器化、服务网格(Service Mesh)等先进技术手段,提升微服务系统的可管理性、可扩展性和容错能力。此外,还将分享一些来自一线项目的经验教训,帮助读者更好地理解和应用这些理论到实际工作中去。 ####
183 0

热门文章

最新文章