高可用架构设计(3) -电商商品详情页缓存背景及框架说明

简介: 高可用架构设计(3) -电商商品详情页缓存背景及框架说明

大背景:电商网站,首页,商品详情页,搜索结果页,广告页,促销活动,购物车,订单系统,库存系统,物流系统

小背景:商品详情页,如何用最快的结果将商品数据填充到一个页面中,然后将页面显示出来

分布式系统:商品详情页,缓存服务,+底层源数据服务,商品信息服务,店铺信息服务,广告信息服务,推荐信息服务,综合起来组成一个分布式的系统

1 电商网站的商品详情页系统架构

1.1 小型商品详情页系统

image.png

1.2 大型商品详情页系统

大型电商网站商品详情页的系统设计中,当商品数据发生变更时,会将变更消息压入消息队列中。

缓存服务从消息队列中消费这条消息时,感知到有数据发生变更,便通过调用数据服务接口,获取变更后的数据,然后将整合好的数据推送至 redis 中。

Nginx 本地缓存的数据是有一定的时间期限的,比如说 10 分钟,当数据过期之后,它就会从 redis 获取到最新的缓存数据,并且缓存到自己本地。


用户浏览网页时,动态将 Nginx 本地数据渲染到本地 html 模板并返回给用户。


虽然没有直接返回 html 页面那么快,但是因为数据在本地缓存,所以也很快,其实耗费的也就是动态渲染一个 html 页面的性能。如果 html 模板发生了变更,不需要将所有的页面重新静态化,也不需要发送请求,没有网络请求的开销,直接将数据渲染进最新的 html 页面模板后响应即可。


在这种架构下,我们需要保证系统的高可用性。


如果系统访问量很高,Nginx 本地缓存过期失效了,redis 中的缓存也被 LRU 算法给清理掉了,那么会有较高的访问量,从缓存服务调用商品服务。但如果此时商品服务的接口发生故障,调用出现了延时,缓存服务全部的线程都被这个调用商品服务接口给耗尽了,每个线程去调用商品服务接口的时候,都会卡住很长时间,后面大量的请求过来都会卡在那儿,此时缓存服务没有足够的线程去调用其它一些服务的接口,从而导致整个大量的商品详情页无法正常显示。


这其实就是一个商品接口服务故障导致缓存服务资源耗尽的现象。


image.pngimage.png

image.png

1.3 页面模板

将数据动态填充/渲染到一个html模板中,是什么意思呢?

<html>
  <title>#{name}的页面</title>
  <body>
    商品的价格是:#{price}
    商品的介绍:#{description}
  </body>
</html>

上面这个就可以认为是一个页面模板,里面的很多内容是不确定的,#{name},#{price},#{description},这都是一些模板脚本,不确定里面的值是什么?


将数据填充/渲染到html模板中,是什么意思呢?

{
  "name": "iphone7 plus(玫瑰金+32G)",
  "price": 5599.50
  "description": "这个手机特别好用。。。。。。"
}
<html>
  <title>iphone7 plus(玫瑰金+32G)的页面</title>
  <body>
    商品的价格是:5599.50
    商品的介绍:这个手机特别好用。。。。。。
  </body>
</html>

上面这个就是一份填充好数据的一个html页面

2 缓存服务

缓存服务,订阅一个MQ的消息变更,如果有消息变更的话,那么就会发送一个网络请求,调用一个底层的对应的源数据服务的接口,去获取变更后的数据


将获取到的变更后的数据填充到分布式的redis缓存中去


高可用这一块儿,最可能出现说可用性不高的情况,是什么呢?

就是说,在接收到消息之后,可能在调用各种底层依赖服务的接口时,会遇到各种不稳定的情况


比如底层服务的接口调用超时,200ms,2s都没有返回; 底层服务的接口调用失败,比如说卡了500ms之后,返回一个报错


在分布式系统中,对于这种大量的底层依赖服务的调用,就可能会出现各种可用性的问题,一旦没有处理好的话


可能就会导致缓存服务自己本身会挂掉,或者故障掉,就会导致什么呢?

不可以对外提供服务,严重情况下,甚至会导致说整个商品详情页显示不出来


缓存服务接收到变更消息后,去调用各个底层依赖服务时的高可用架构的实现。

3 框架结构

围绕着缓存服务去拉取各种底层的源数据服务的数据,调用其接口时,可能出现的系统不可用的问题


从简


spring boot,微服务的非常快速,非常好用的技术框架,脱胎于spring,具体的东西就不讲解,直接带着大家上手搭建一个spring boot的框架


2个服务,缓存服务,商品服务,缓存服务依赖于商品服务


模拟各种商品服务可能接口调用时出现的各种问题,导致系统不可用的场景,然后用hystrix完整的各种技术点全部贯穿在里面


解决了一大堆设计业务背景下的系统不可用问题,hystrix整个技术体系,知识体系,也就讲解完了


消息队列,redis,咱们都不搞了


spring boot + http client + hystrix


参考

  • 《Java工程师面试突击第1季-中华石杉老师》
目录
相关文章
|
7月前
|
存储 缓存 安全
某鱼电商接口架构深度剖析:从稳定性到高性能的技术密码
某鱼电商接口架构揭秘:分层解耦、安全加固、性能优化三维设计,实现200ms内响应、故障率低于0.1%。详解三层架构、多引擎存储、异步发布、WebSocket通信与全链路防护,助力开发者突破电商接口“三难”困境。
|
8月前
|
SQL 监控 关系型数据库
MySQL主从复制:构建高可用架构
本文深入解析MySQL主从复制原理与实战配置,涵盖复制架构、监控管理、高可用设计及性能优化,助你构建企业级数据库高可用方案。
|
9月前
|
运维 监控 搜索推荐
MSE ZooKeeper:Flink 高可用架构的企业级选择
本文深入解析了 Apache Flink 架构中 ZooKeeper 的核心作用,包括 Leader 选举、Checkpoint 管理、作业协调及配置管理等关键功能,并结合金融风控与电商推荐等典型场景,分析了 ZooKeeper 在实际应用中的技术实现。
|
11月前
|
安全 测试技术 API
电商API接口开发:基础架构搭建全攻略
本文详细解析了电商API接口从零搭建基础架构的全流程。首先通过需求分析明确业务功能与接口规范,选定数据格式(如JSON)及通信方式(如RESTful)。接着在架构设计阶段选择合适的技术栈、数据库方案,并引入API网关实现统一管理。开发实现部分涵盖认证授权、数据访问、日志记录与异常处理等核心功能。安全防护则强调数据加密、传输安全及速率限制策略。测试优化阶段包括单元测试、集成测试、性能与安全测试,确保接口稳定性。最后通过工具生成清晰的API文档并实施版本控制,为开发者提供便利。整体流程系统化、模块化,助力打造高效、安全的电商API接口。
|
7月前
|
运维 监控 安全
公链开发中的高可用架构设计要点
本指南提供公链高可用架构的可复用流程与模板,涵盖目标拆解、先决条件、分步执行、故障排查及验收标准,结合跨链DApp与量化机器人案例,提升落地效率与系统稳定性。
|
11月前
|
缓存 负载均衡 监控
微服务架构下的电商API接口设计:策略、方法与实战案例
本文探讨了微服务架构下的电商API接口设计,旨在打造高效、灵活与可扩展的电商系统。通过服务拆分(如商品、订单、支付等模块)和标准化设计(RESTful或GraphQL风格),确保接口一致性与易用性。同时,采用缓存策略、负载均衡及限流技术优化性能,并借助Prometheus等工具实现监控与日志管理。微服务架构的优势在于支持敏捷开发、高并发处理和独立部署,满足电商业务快速迭代需求。未来,电商API设计将向智能化与安全化方向发展。
559 102
|
7月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
7月前
|
人工智能 JavaScript 前端开发
GenSX (不一样的AI应用框架)架构学习指南
GenSX 是一个基于 TypeScript 的函数式 AI 工作流框架,以“函数组合替代图编排”为核心理念。它通过纯函数组件、自动追踪与断点恢复等特性,让开发者用自然代码构建可追溯、易测试的 LLM 应用。支持多模型集成与插件化扩展,兼具灵活性与工程化优势。
609 6
|
7月前
|
缓存 运维 监控
Redis 7.0 高性能缓存架构设计与优化
🌟蒋星熠Jaxonic,技术宇宙中的星际旅人。深耕Redis 7.0高性能缓存架构,探索函数化编程、多层缓存、集群优化与分片消息系统,用代码在二进制星河中谱写极客诗篇。
1354 3
|
8月前
|
存储 监控 NoSQL
Redis高可用架构全解析:从主从复制到集群方案
Redis高可用确保服务持续稳定,避免单点故障导致数据丢失或业务中断。通过主从复制实现数据冗余,哨兵模式支持自动故障转移,Cluster集群则提供分布式数据分片与水平扩展,三者层层递进,保障读写分离、容灾切换与大规模数据存储,构建高性能、高可靠的Redis架构体系。