微服务实践01--微服务管理11--缓存04--实践01--缓存使用

本文涉及的产品
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 微服务实践01--微服务管理11--缓存04--实践01--缓存使用

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

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

背景

在前面的几篇文章中讨论了很多关于缓存使用时要注意的事项。但在实际的工作中在哪些地方考虑这些事项其实还是不明确。为了帮助读者在生产中更好的使用缓存,本文主要以例子的方式说明在生产环境中使用缓存的方式。

示例

结合前面几篇文章中的内容,并通过尽量的减少对于(相对)慢速服务/设备的访问来提高业务处理速度。但在业务处理过程中减少对于慢速服务/设备的访问并不一定就可以提升业务处理速度,并还有可能带来其他的问题。所以,这里展示几个例子来解释这些问题,并提供可用的生产环境方案。

大量请求的终极方案

在前几篇文章中出现过大量请求的时候的一个终极方案,如下:
大量请求的终极方案

这个方案参照了之前使用cdn缓存业务接口的方式来设计。通过OpenResty中支持的脚本语言Lua去控制本地返回还是使用Redis中结果返回。还有如果发生miss之后还需要调用后端服务来更新缓存。

这种方式的缓存的特点:适合IO密集型业务中,不适合计算密集型业务。并在业务过程中查看的业务占系统业务的绝大部分。例如:大型线上商城中的商品展示,新闻网站,网站门户,微博/陌生人社交,音视频服务,图片网站等。

缓存更新示例

在实际的缓存更新过程中一般有以下几种方式来更新缓存:
缓存更新实践
这几种方式针对不同的缓存模型来进行。

  • 被动更新

使用领域事件,定时进行缓存的更新动作。在数据源发生变化时通过事件的方式通知各个关心这部分数据的服务去更新自己保存的信息一般情况下在事件驱动模式下可以完成。但很多时候服务/系统之前的数据的同步工作不会这么顺利的解决,所以还可以使用定时轮询数据源的方式检查服务缓存数据是否和数据源数据一致。

  • 主动更新

在用户访问的时候检查并更新缓存。在用户对业务进行访问时对缓存的数据进行检查和更新,这样可以保证只有用户用才对缓存进行操作,用户不用这部分业务的时候就不对缓存进行操作。这样可以减少对于计算资源的消耗很有帮助,还可以减少缓存中空间的占用。

被动更新的特点在于有一个系统中的触发源去触发数据的更新动作。主动更新的特点在于只有用户在使用系统的特定功能时才会触发更新的动作。被动更新可以保证缓存和数据源之间的数据永远是一致的,并且不需要过多的补偿机制来保证数据一致性。主动更新的方式就会发生缓存和数据源中数据不一致的问题。所以,在后面会讨论在主动更新模式下尽量保证数据一致性的方式。

定时更新的方式在很多地方都有使用,例如CDN的定时溯源的机制就是以这种方式运行的。

被动更新

事件更新

事件更新中最核心的概念是事件,这里的事件最好是在领域驱动设计中的事件风暴阶段中这里出来的事件。因为这种事件代表着业务发生的动作,也代表着业务价值的流动。
事件更新
一般情况下领域驱动设计中的事件是从限界上下文中发送出来的由另一个限界上下文接收和处理。但在一些情况下也可以是同一个限界上下文中的不通过聚合发送和接收。
基于现在的系统架构模式几乎都使用微服务模式,所以最好使用消息组播的方式来处理消息。这样可以防止一个逻辑服务的不同实例都在处理同一个缓存key。

定时更新

在微服务架构模式下,任务、定时器都会由一个任务调度中心来完成。所以,在使用定时触发缓存更新时还是使用分布式任务调度中心来完成任务的调度工作。这样可以保证同一时间只有一个实例在处理。以这种方式简单的进行排他工作,防止同时操作缓存的问题。
定时更新

被动更新

用户触发更新也可以称为非固定周期更新,因为用户的触发时间是不确定的、任何时候都可能。有一种随机数的产生方式就是使用类似的机制:操作系统使用内核接受到中断的时间点作为随机数使用。所以,用户触发更新的方式就是一种随机发生的缓存更新。
非固定周期更新

下面一一说明图中内容的含义:

  • 深蓝色的矩形块:缓存更新间隔

缓存更新间隔代表缓存最小更新周期,只有缓存在超过这个周期还没有更新的情况下才会进行触发更新。更新间隔中多次使用缓存则不进行更新。
缓存更新间隔的作用是防止用户在很短的时间段内多次使用这部分数据,而产生的每次都要更新缓存的问题。如果每次都要更新缓存中的数据,那么和未使用缓存的系统行为就是一致的,那就相当于没有使用缓存。

  • 绿色箭头:触发事件

触发事件是系统接收到的请求。在请求处理中要判断是否超过了一个更新间隔,如果缓存的存在时间已经超过一个更新间隔则需要对缓存进行更新。
这里隐藏着一个点,在非固定周期中更新了缓存是需要重新设置缓存的过期时间的。因为这样就会造成同一块业务的缓存失效时间点不一致。而缓存失效时间点就可以避免缓存雪崩的产生。

  • 绿色双向箭头:过期时间

过期时间是为了保证缓存中的数据可以正常的过期被提出缓存,这样来提高缓存的使用率。
另外在过期时间中还隐藏了一个重要的问题:缓存存在是否就可以直接返回给业务?在缓存存在的情况下,更新缓存的动作是异步的执行了,让现有的数据直接返回给业务。还是更新缓存的动作同步执行,等更新完缓存之后再返回。这里在下一节中详细讨论。

  • 公式:更新率

更新率跟下面所要讨论的缓存更新方式有很重要的关联。这里先讨论一下更新率代表着什么?更新率代表着数据不一致的情况最大可接受的范围。因为数据源在更新间隔内更新了数据,在缓存使用服务中更新缓存的频率。所以,在后面讨论的同步和异步方式中,同步时推荐更新率月趋近于1越好,而异步方式越小越好。
因为同步方式更新率趋近于1,因为如果在触发事件超过更新间隔时永远都会更新缓存,所以这两个值相等比较好。在异步更新时为了保证缓存和数据源的一致性,保持比较小的一个更新率可以保证数据的一致性,并能保证缓存空间被充分的利用。

同步、异步更新

缓存更新同步异步方式

如上图中箭头所指向位置,在这里使用同步方式还是使用异步方式。从这两种方式产生的问题角度入手分析他们的优缺点:

  • 同步

同步的方式会造成接口响应时间偏差较大,因为有些不调用溯源接口,有些调用。这导致接口在不同时间的行为不一致造成接口响应时间偏差较大。

  • 异步

异步方式当前返回的值都是缓存中的值,在特定的时间点上返回的数据是不一致的。可能对幂等性有干扰。

不管同步还是异步都有可能造成缓存击穿问题,所以更新缓存的过程中最好进行一些排他动作以防止洪泛的发生。

总结

主动更新、被动更新这些技术适应于不同的场景。它们各自有各自的优缺点,在技术设计阶段需要考虑实际的业务场景来决策到底使用那种方式合适。这个很多时候是需要设计人员的经验来进行决策。所以,任何一种软件设计过程都是一个决策和权衡的过程。

使用缓存的目标就是:通过减少对慢速服务的访问,来提速。所以在实际的缓存环境中,最主要的目标是减少访问慢速来达到使用缓存提速的目标。而在这个过程中可以使用的整体方案很多,可以通过不同事项的调整来完成自己的方案。

参考

浅谈 Cache

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