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

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 微服务实践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序列化框架对比

目录
相关文章
|
17天前
|
API 持续交付 开发者
后端开发中的微服务架构实践与挑战
在数字化时代,后端服务的构建和管理变得日益复杂。本文将深入探讨微服务架构在后端开发中的应用,分析其在提高系统可扩展性、灵活性和可维护性方面的优势,同时讨论实施微服务时面临的挑战,如服务拆分、数据一致性和部署复杂性等。通过实际案例分析,本文旨在为开发者提供微服务架构的实用见解和解决策略。
|
18天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
7天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
29 5
|
10天前
|
监控 Go API
Go语言在微服务架构中的应用实践
在微服务架构的浪潮中,Go语言以其简洁、高效和并发处理能力脱颖而出,成为构建微服务的理想选择。本文将探讨Go语言在微服务架构中的应用实践,包括Go语言的特性如何适应微服务架构的需求,以及在实际开发中如何利用Go语言的特性来提高服务的性能和可维护性。我们将通过一个具体的案例分析,展示Go语言在微服务开发中的优势,并讨论在实际应用中可能遇到的挑战和解决方案。
|
8天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
|
10天前
|
Kubernetes Cloud Native Docker
云原生技术探索:容器化与微服务的实践之道
【10月更文挑战第36天】在云计算的浪潮中,云原生技术以其高效、灵活和可靠的特性成为企业数字化转型的重要推手。本文将深入探讨云原生的两大核心概念——容器化与微服务架构,并通过实际代码示例,揭示如何通过Docker和Kubernetes实现服务的快速部署和管理。我们将从基础概念入手,逐步引导读者理解并实践云原生技术,最终掌握如何构建和维护一个高效、可扩展的云原生应用。
|
11天前
|
监控 API 持续交付
后端开发中的微服务架构实践与挑战####
本文深入探讨了微服务架构在后端开发中的应用,分析了其优势、面临的挑战以及最佳实践策略。不同于传统的单体应用,微服务通过细粒度的服务划分促进了系统的可维护性、可扩展性和敏捷性。文章首先概述了微服务的核心概念及其与传统架构的区别,随后详细阐述了构建微服务时需考虑的关键技术要素,如服务发现、API网关、容器化部署及持续集成/持续部署(CI/CD)流程。此外,还讨论了微服务实施过程中常见的问题,如服务间通信复杂度增加、数据一致性保障等,并提供了相应的解决方案和优化建议。总之,本文旨在为开发者提供一份关于如何在现代后端系统中有效采用和优化微服务架构的实用指南。 ####
|
13天前
|
消息中间件 设计模式 运维
后端开发中的微服务架构实践与挑战####
本文深入探讨了微服务架构在现代后端开发中的应用,通过实际案例分析,揭示了其在提升系统灵活性、可扩展性及促进技术创新方面的显著优势。同时,文章也未回避微服务实施过程中面临的挑战,如服务间通信复杂性、数据一致性保障及部署运维难度增加等问题,并基于实践经验提出了一系列应对策略,为开发者在构建高效、稳定的微服务平台时提供有价值的参考。 ####
|
14天前
|
消息中间件 监控 数据管理
后端开发中的微服务架构实践与挑战####
【10月更文挑战第29天】 在当今快速发展的软件开发领域,微服务架构已成为构建高效、可扩展和易于维护应用程序的首选方案。本文探讨了微服务架构的核心概念、实施策略以及面临的主要挑战,旨在为开发者提供一份实用的指南,帮助他们在项目中成功应用微服务架构。通过具体案例分析,我们将深入了解如何克服服务划分、数据管理、通信机制等关键问题,以实现系统的高可用性和高性能。 --- ###
37 2
|
15天前
|
监控 安全 应用服务中间件
微服务架构下的API网关设计策略与实践####
本文深入探讨了在微服务架构下,API网关作为系统统一入口点的设计策略、实现细节及其在实际应用中的最佳实践。不同于传统的摘要概述,本部分将直接以一段精简的代码示例作为引子,展示一个基于NGINX的简单API网关配置片段,随后引出文章的核心内容,旨在通过具体实例激发读者兴趣,快速理解API网关在微服务架构中的关键作用及实现方式。 ```nginx server { listen 80; server_name api.example.com; location / { proxy_pass http://backend_service:5000;