二级缓存架构极致提升系统性能

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 Tair(兼容Redis),内存型 2GB
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
简介: 本文详细阐述了如何通过二级缓存架构设计提升高并发下的系统性能。

前言

随着k8s成为用云新界面,容器成为众多用户“弹性”的利器,因此容器的创建天生具备高并发特性。


高并发、大数据量下,为了提供更好的容器弹性体验,笔者通过二级缓存的设计,成功优化了系统性能、资源消耗、系统容量。


但持续压榨性能的道路是曲折的。各种缓存方案需要考虑非常多因素,包括缓存的多级架构、预热、击穿、刷新、运维等。


让我们先看看系统性能、资源消耗、系统容量,到底优化了多少?然后详细介绍带来性能提升的二级缓存架构,以及各种缓存方案的设计、比较、落地。


优化结果

笔者对系统进行多次压测,观察了二级缓存等优化手段上线前后,高QPS下的资源消耗、RT和系统容量。


1、资源消耗大幅下降

可以看到,上线了二级缓存等优化手段后,相同QPS下,CPU使用率大幅下降。

image.png

2、RT和系统容量优化

由于计算资源消耗的下降,同QPS下的平均RT也大幅下降。此外我们发现,优化前,随着QPS不断提升,RT明显变慢、变慢幅度很大,优化后,RT变慢的幅度明显减缓。这意味着,系统容量也更加深不可测了。


系统瓶颈在哪?

持续压榨性能,前提是知道瓶颈在哪。笔者怎么定位瓶颈的呢?-> cpuProfile火焰图。


高QPS下,分析了系统cpu火焰图,发现50%+的CPU瓶颈在大量的业务数据处理,主要两块:


1、从redis取业务pojoList时的fastjson array反序列化背景是和redis交互的数据量特别大笔者对缓存value进行过压缩,在解压缩后的string转为List<Pojo>的过程,本质用时间换了空间。


2、调用redis获取数据后的alibaba.cachejson的POJO解析。


在高并发、大数据量的业务背景下,这些过程的耗时被笛卡尔积地放大。


既然分布式缓存CPU资源消耗是瓶颈,那么引入本地缓存,就能解这个问题。另外,本地缓存还能提供服务容灾能力。


数据属性和缓存选型


数据属性

设计缓存方案前,先分析业务数据属性:

  • 符合key -> value的数据模式
  • 读多写少
  • 变更频率低
  • 数据一致性要求不高

简直就是缓存的绝佳使用场景!那么用本地缓存,还是分布式缓存呢?还是二级缓存?


本地/分布式缓存特性

基于业务属性,我们来match本地/分布式缓存特性:


本地缓存


  • 优点
  • 访问速度快;
  • 减少网络开销:不存在redis流量瓶颈(之前由于数据valueList量过大,导致redis网络流量超过redis实例SLA,还做过一次gzip压缩);
  • 缺点
  • 可用性相对差:如果应用实例宕机/重启, 缓存数据会丢失;
  • 资源限制:受限于单机内存大小,不适合大规模数据缓存(相对内存大小来说,本业务数据量还是较小,也是相对静态数据,在内存还是妥妥可存的核心业务数据);


分布式缓存


  • 优点
  • 高可用:数据共享,不会因为业务机器重启丢失;
  • 大容量:可以水平扩展增加存储容量;
  • 缺点
  • 序列化cpu瓶颈(本系统大数据量+高调用量下尤其突出);
  • 网络开销:存在redis流量瓶颈(本系统大数据量+高调用量下尤其突出);


本地+分布式二级缓存


  • 优点
  • 结合两者优势,层次化加速;
  • 缺点
  • 对本系统代码侵入较大,实现较复杂;
  • 资源消耗:额外的缓存层级会占用更多计算和存储资源;


缓存方案比较

系统现状

image.png

结合业务场景和系统现状,提出以下三种方案。对多级架构、预热、击穿、刷新、运维多个角度分析。

方案1:本地缓存+guava refreshAfterWrite

image.png

1、架构

仅本地缓存。根据业务场景设置失效时间。


2、cache miss处理、刷新

使用Guava cache原生的refreshAfterWrite+异步reLoader机制,进行缓存的刷新,保证时效性。当对应key距离写入时间点存活超过TTL后,guava会自动执行我们在reLoader中写的业务逻辑,从提供实时数据的系统自动拉取最新的<key, value>,更新缓存值。


在本业务场景下,缓存的key&value设计有两种方案。


a. <key, value>。由于guava cache loader只能by key更新,所以,如果在单地域有N台机器,每个机器都查M个key,在缓存刷新时最大有M*N个查询请求打到提供实时数据的系统,无法使用批量查询能力,而M数量非常大,对下游压力会翻倍。


b. <"all_data"(hardCode), Map<key, value>>。这样可以使用到批量查询的能力,但是当某些<key, value>在本地缓存没有时,guava的loader就无法识别cache miss并从下游系统捞数据了。


3、预热

启动时全量预热。


4、运维

暴露dubbo/http服务,by host运维;或者重启机器。


因此:

  • 优点
  • 无redis相关cpu资源、网络资源损耗;
  • 直接使用了Guava cache原生的loader机制;
  • 缺点
  • 对下游压力翻倍;

由于对下游压力太大,放弃此方案。

方案2:二级缓存+刷新job

image.png

1、架构

本地+分布式二级缓存。本地缓存失效时间无穷大。


2、预热

启动时全量预热。


3、cache miss处理

不用guava cache loader。cache miss时业务上调用分布式缓存,再miss则调用下游服务。


4、刷新

使用spring单机job定时全量刷新缓存,保证一定时效性(数据变动频率很低,所以job频率设低即可)。但是由于本系统在间接引入quartz分布式定时任务框架时,没有直接支持单机job(quartz本身是支持的),所以需要额外使用spring单机job框架,会导致系统任务管理框架不统一。


5、运维

本地缓存:暴露dubbo/http服务,by host运维;或者重启机器。

分布式缓存:通过redis服务管理。


因此:

  • 优点
  • 本地缓存命中率很高,基本不会发生redis瓶颈。
  • 缺点
  • 业务自行load+write back。
  • 使用了新的定时任务框架(for单机),系统任务管理框架不统一。


方案3:二级缓存+guava expireAfterAccess

image.png

1、架构

本地+分布式二级缓存。根据业务设定本地缓存失效时间(expireAfterAccess)。


2、预热

启动时全量预热。这会导致应用重启,然后缓存预热后,部分本地缓存TTL可能批量到期失效,后面请求过来后可能直接大量击穿到下游服务,这是典型的缓存雪崩场景!

而且,当本地缓存雪崩,或者miss时,请求即使hit分布式缓存,也会导致redis相关序列化cpu瓶颈,会导致偶发的系统性能长尾。


3、cache miss处理

不用guava cache loader。cache miss时业务上调用分布式缓存,再miss则调用下游服务。


4、刷新

无刷新job。


5、运维

本地缓存:暴露dubbo/http服务,by host运维;或者重启机器。

分布式缓存:通过redis服务管理。


因此:

  • 优点
  • 不需要额外刷新job;
  • 不强依赖运维方案(因为本地和分布式缓存都有失效时间);
  • 缺点
  • 存在缓存雪崩风险;
  • redis相关序列化造成cpu瓶颈发生概率仍然较大;


落地方案

根据上述优缺点、改造量评估, 基本按照方案2来执行。


1、架构

本地+分布式二级缓存,以本地缓存为主,保证本地缓存极高命中率。


2、CacheMiss处理

业务自行处理,和现有链路保持一致,localCache -> redis -> dubbo,这样能够快速上线。


3、预热

应用启动,提供服务前预热。


4、刷新

基于SpringCronJob。


5、运维

per host运维,提供dubbo/http服务。

除此之外,对guava cache还进行了包装,各个业务场景的各种local cache,统一存储在一个Map容器Map<${prefix}, Cache<${key}, ${value}>>里,对现有的本地缓存也进行了重构,通过缓存包装层统一交互统一管理,增加可复用性和代码简洁度。


写在最后

本文对多种缓存方案的架构、预热、击穿、刷新、运维等进行了比较分析,最终进行工程落地,完成了容器场景高并发、大数据量下的系统性能极致提升。后续的优化点有:


1、其他系统瓶颈:压测pattern较单一,可能因为缓存掩盖其他依赖服务的性能瓶颈。未来会用更全面的压测pattern继续压榨系统性能。

2、批量刷新能力:对于方案1的批量刷新能力缺陷,caffeine其实有相关feature,见Bulk refresh这个issue。

3、运维方案:缺乏集群批量invalid能力,待建设。

4、架构统一:分布式和单机job使用同一个job管理框架。


这个方案的落地,特别要感谢团队同学的宝贵建议,是大家多次对技术方案“battle”后的结果。虽然笔者不是哈工大的,但借用哈工大的校训来总结,reviewers的意见、对技术的追求,如同追求“规格严格,功夫到家”。Creating great software is crafting a piece of art. 继续加油!





来源  |  阿里云开发者公众号
作者  |
 木将


相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
21天前
|
设计模式 Java 关系型数据库
【Java笔记+踩坑汇总】Java基础+JavaWeb+SSM+SpringBoot+SpringCloud+瑞吉外卖/谷粒商城/学成在线+设计模式+面试题汇总+性能调优/架构设计+源码解析
本文是“Java学习路线”专栏的导航文章,目标是为Java初学者和初中高级工程师提供一套完整的Java学习路线。
178 37
|
12天前
|
监控 Android开发 iOS开发
深入探索安卓与iOS的系统架构差异:理解两大移动平台的技术根基在移动技术日新月异的今天,安卓和iOS作为市场上最为流行的两个操作系统,各自拥有独特的技术特性和庞大的用户基础。本文将深入探讨这两个平台的系统架构差异,揭示它们如何支撑起各自的生态系统,并影响着全球数亿用户的使用体验。
本文通过对比分析安卓和iOS的系统架构,揭示了这两个平台在设计理念、安全性、用户体验和技术生态上的根本区别。不同于常规的技术综述,本文以深入浅出的方式,带领读者理解这些差异是如何影响应用开发、用户选择和市场趋势的。通过梳理历史脉络和未来展望,本文旨在为开发者、用户以及行业分析师提供有价值的见解,帮助大家更好地把握移动技术发展的脉络。
|
11天前
|
网络协议 安全 中间件
系统架构设计师【第2章】: 计算机系统基础知识 (核心总结)
本文全面介绍了计算机系统及其相关技术,涵盖计算机系统概述、硬件、软件等内容。计算机系统由硬件(如处理器、存储器、输入输出设备)和软件(系统软件、应用软件)组成,旨在高效处理和管理数据。硬件核心为处理器,历经从4位到64位的发展,软件则分为系统软件和应用软件,满足不同需求。此外,深入探讨了计算机网络、嵌入式系统、多媒体技术、系统工程及性能评估等多个领域,强调了各组件和技术在现代信息技术中的重要作用与应用。
22 3
|
11天前
|
缓存 监控 负载均衡
在使用CDN时,如何配置缓存规则以优化性能
在使用CDN时,如何配置缓存规则以优化性能
|
23天前
|
缓存 JavaScript 中间件
优化Express.js应用程序性能:缓存策略、请求压缩和路由匹配
在开发Express.js应用时,采用合理的缓存策略、请求压缩及优化路由匹配可大幅提升性能。本文介绍如何利用`express.static`实现缓存、`compression`中间件压缩响应数据,并通过精确匹配、模块化路由及参数化路由提高路由处理效率,从而打造高效应用。
64 5
|
23天前
|
Cloud Native Devops 持续交付
探索云原生架构:构建高效、灵活和可扩展的系统
本文将深入探讨云原生架构的核心概念、主要技术以及其带来的优势。我们将从云原生的定义开始,了解其设计理念和技术原则;接着分析容器化、微服务等关键技术在云原生中的应用;最后总结云原生架构如何助力企业实现数字化转型,提升业务敏捷性和创新能力。通过这篇文章,读者可以全面了解云原生架构的价值和应用前景。
|
23天前
|
运维 Cloud Native Devops
云原生架构的崛起与实践云原生架构是一种通过容器化、微服务和DevOps等技术手段,帮助应用系统实现敏捷部署、弹性扩展和高效运维的技术理念。本文将探讨云原生的概念、核心技术以及其在企业中的应用实践,揭示云原生如何成为现代软件开发和运营的主流方式。##
云原生架构是现代IT领域的一场革命,它依托于容器化、微服务和DevOps等核心技术,旨在解决传统架构在应对复杂业务需求时的不足。通过采用云原生方法,企业可以实现敏捷部署、弹性扩展和高效运维,从而大幅提升开发效率和系统可靠性。本文详细阐述了云原生的核心概念、主要技术和实际应用案例,并探讨了企业在实施云原生过程中的挑战与解决方案。无论是正在转型的传统企业,还是寻求创新的互联网企业,云原生都提供了一条实现高效能、高灵活性和高可靠性的技术路径。 ##
29 3
|
1月前
|
缓存 NoSQL Java
揭秘性能提升的超级武器:掌握Hibernate二级缓存策略!
【9月更文挑战第3天】在软件开发中,性能优化至关重要。使用Hibernate进行数据持久化的应用可通过二级缓存提升数据访问速度。一级缓存随Session生命周期变化,而二级缓存是SessionFactory级别的全局缓存,能显著减少数据库访问次数,提高性能。要启用二级缓存,需在映射文件或实体类上添加相应配置。然而,并非所有场景都适合使用二级缓存,需根据业务需求和数据变更频率决定。此外,还可与EhCache、Redis等第三方缓存集成,进一步增强缓存效果。合理运用二级缓存策略,有助于大幅提升应用性能。
53 5
|
1月前
|
缓存 安全 Java
如何利用Go语言提升微服务架构的性能
在当今的软件开发中,微服务架构逐渐成为主流选择,它通过将应用程序拆分为多个小服务来提升灵活性和可维护性。然而,如何确保这些微服务高效且稳定地运行是一个关键问题。Go语言,以其高效的并发处理能力和简洁的语法,成为解决这一问题的理想工具。本文将探讨如何通过Go语言优化微服务架构的性能,包括高效的并发编程、内存管理技巧以及如何利用Go生态系统中的工具来提升服务的响应速度和资源利用率。
|
21天前
|
canal 缓存 NoSQL
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
根据对一致性的要求程度,提出多种解决方案:同步删除、同步删除+可靠消息、延时双删、异步监听+可靠消息、多重保障方案
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
下一篇
无影云桌面