高并发环境下热点数据访问的最佳实践。

最新推荐文章于 2025-04-23 16:03:39 发布
原创 最新推荐文章于 2025-04-23 16:03:39 发布 · 831 阅读 · 2 ·
CC 4.0 BY-SA版权

为解决高并发场景下的缓存热点访问问题，提出了一种透明多级缓存方案TMC。该方案通过热点探测与本地缓存前置，有效缓解分布式缓存的压力，并确保数据一致性。

前言：

正常情况下，我们为了缓解数据库读写压力，我们会在应用程序中增加一层缓存，但在高并发场景下，热点数据的访问依旧会对缓存造成压力，通过横向扩容也并不能解决本质问题。那么，有没有一种热点预测，精准匹配的解决方案呢? 以下是我在有赞公司技术文章里看到的一种多级缓存架构设计，以此记录，仅供学习。

TMC，即“透明多级缓存（Transparent Multilevel Cache）”，是有赞 PaaS 团队给公司内应用提供的整体缓存解决方案。

TMC 在通用“分布式缓存解决方案（如 CodisProxy + Redis，如有赞自研分布式缓存系统 zanKV）”基础上，增加了以下功能：

  • 应用层热点探测
  • 应用层本地缓存
  • 应用层缓存命中统计

以帮助应用层解决缓存使用过程中出现的热点访问问题。

为什么要做 TMC

使用有赞服务的电商商家数量和类型很多，商家会不定期做一些“商品秒杀”、“商品推广”活动，导致“营销活动”、“商品详情”、“交易下单”等链路应用出现缓存热点访问的情况：

  • 活动时间、活动类型、活动商品之类的信息不可预期，导致 缓存热点访问 情况不可提前预知；
  • 缓存热点访问 出现期间，应用层少数 热点访问 key 产生大量缓存访问请求：冲击分布式缓存系统，大量占据内网带宽，最终影响应用层系统稳定性；

为了应对以上问题，需要一个能够 自动发现热点 并 将热点缓存访问请求前置在应用层本地缓存的解决方案，这就是 TMC 产生的原因。

多级缓存解决方案的痛点

基于上述描述，我们总结了下列 多级缓存解决方案需要解决的需求痛点：

  • 热点探测：如何快速且准确的发现 热点访问 key ？
  • 数据一致性：前置在应用层的本地缓存，如何保障与分布式缓存系统的数据一致性？
  • 效果验证：如何让应用层查看本地缓存命中率、热点 key 等数据，验证多级缓存效果？
  • 透明接入：整体解决方案如何减少对应用系统的入侵，做到快速平滑接入？

TMC 聚焦上述痛点，设计并实现了整体解决方案。以支持“热点探测”和“本地缓存”，减少热点访问时对下游分布式缓存服务的冲击，避免影响应用服务的性能及稳定性。

TMC 整体架构

在这里插入图片描述

TMC 整体架构如上图，共分为三层：

  • 存储层：提供基础的 kv 数据存储能力，针对不同的业务场景选用不同的存储服务（codis/zankv/aerospike）；
  • 代理层：为应用层提供统一的缓存使用入口及通信协议，承担分布式数据水平切分后的路由功能转发工作；
  • 应用层：提供统一客户端给应用服务使用，内置“热点探测”、“本地缓存”等功能，对业务透明；

本篇聚焦在应用层客户端的“热点探测”、“本地缓存”功能。

TMC 本地缓存

如何透明？

TMC 是如何减少对业务应用系统的入侵，做到透明接入的？对于公司 Java 应用服务，在缓存客户端使用方式上分为两类：

  • 基于 spring.data.redis包，使用 RedisTemplate编写业务代码；
  • 基于 youzan.framework.redis包，使用 RedisClient编写业务代码；

在这里插入图片描述

不论使用以上那种方式，最终通过 JedisPool创建的 Jedis对象与缓存服务端代理层做请求交互。

TMC 对原生 jedis 包的 JedisPool和 Jedis类做了改造，在 JedisPool 初始化过程中集成 TMC“热点发现”+“本地缓存”功能 Hermes-SDK包的初始化逻辑

使 Jedis客户端与缓存服务端代理层交互时先与 Hermes-SDK交互，从而完成 “热点探测”+“本地缓存”功能的透明接入。

对于 Java 应用服务，只需使用特定版本的 jedis-jar 包，无需修改代码，即可接入 TMC 使用“热点发现”+“本地缓存”功能，做到了对应用系统的最小入侵。

整体结构
在这里插入图片描述

模块划分
TMC 本地缓存整体结构分为如下模块：

  • Jedis-Client：Java 应用与缓存服务端交互的直接入口，接口定义与原生 Jedis-Client 无异；
  • Hermes-SDK：自研“热点发现+本地缓存”功能的 SDK 封装，Jedis-Client 通过与它交互来集成相应能力；
  • Hermes 服务端集群：接收 Hermes-SDK 上报的缓存访问数据，进行热点探测，将热点 key 推送给 Hermes-SDK 做本地缓存；
  • 缓存集群：由代理层和存储层组成，为应用客户端提供统一的分布式缓存服务入口；
  • 基础组件：etcd 集群、Apollo 配置中心，为 TMC 提供“集群推送”和“统一配置”能力；

基本流程

1）key 值获取

  • Java 应用调用 Jedis-Client 接口获取 key 的缓存值时，Jedis-Client 会询问 Hermes-SDK 该 key 当前是否是 热点key；
  • 对于 热点key ，直接从 Hermes-SDK 的 热点模块 获取热点 key 在本地缓存的 value 值，不去访问 缓存集群 ，从而将访问请求前置在应用层；
  • 对于非 热点key ，Hermes-SDK 会通过 Callable回调 Jedis-Client 的原生接口，从 缓存集群 拿到 value 值；
  • 对于 Jedis-Client 的每次 key 值访问请求，Hermes-SDK 都会通过其 通信模块 将 key 访问事件 异步上报给 Hermes 服务端集群 ，以便其根据上报数据进行“热点探测”；

2）key 值过期

  • Java 应用调用 Jedis-Client 的 set() del() expire()接口时会导致对应 key 值失效，Jedis-Client 会同步调用 Hermes-SDK 的 invalid()方法告知其“key 值失效”事件；
  • 对于 热点 key ，Hermes-SDK 的 热点模块 会先将 key 在本地缓存的 value 值失效，以达到本地数据强一致。同时 通信模块 会异步将“key 值失效”事件通过 etcd 集群 推送给 Java 应用集群中其他 Hermes-SDK 节点；
  • 其他 Hermes-SDK 节点的 通信模块 收到 “key 值失效”事件后，会调用 热点模块 将 key 在本地缓存的 value 值失效，以达到集群数据最终一致；

3）热点发现

  • Hermes 服务端集群 不断收集 Hermes-SDK上报的 key 访问事件，对不同业务应用集群的缓存访问数据进行周期性（3s 一次）分析计算，以探测业务应用集群中的热点 key列表；
  • 对于探测到的热点 key列表，Hermes 服务端集群 将其通过 etcd 集群 推送给不同业务应用集群的 Hermes-SDK 通信模块，通知其对热点 key列表进行本地缓存；

4）配置读取

  • -Hermes-SDK 在启动及运行过程中，会从 Apollo 配置中心 读取其关心的配置信息（如：启动关闭配置、黑白名单配置、etcd 地址…）；
  • Hermes 服务端集群 在启动及运行过程中，会从 Apollo 配置中心 读取其关心的配置信息（如：业务应用列表、热点阈值配置、etcd 地址…）

稳定性

TMC 本地缓存稳定性表现在以下方面：

  • 数据上报异步化：Hermes-SDK 使用 rsyslog技术对“key 访问事件”进行异步化上报，不会阻塞业务；
  • 通信模块线程隔离：Hermes-SDK 的 通信模块 使用独立线程池+有界队列，保证事件上报&监听的 I/O 操作与业务执行线程隔离，即使出现非预期性异常也不会影响基本业务功能；
  • 缓存管控：Hermes-SDK 的 热点模块 对本地缓存大小上限进行了管控，使其占用内存不超过 64MB（LRU），杜绝 JVM 堆内存溢出的可能；

一致性

TMC 本地缓存一致性表现在以下方面：

  • Hermes-SDK 的 热点模块 仅缓存 热点 key 数据，绝大多数非热点 key数据由 缓存集群 存储；
  • 热点 key 变更导致 value 失效时，Hermes-SDK 同步失效本地缓存，保证 本地强一致；
  • 热点 key 变更导致 value 失效时，Hermes-SDK 通过 etcd 集群 广播事件，异步失效业务应用集群中其他节点的本地缓存，保证 集群最终一致；

热点发现

整体流程
在这里插入图片描述

TMC 热点发现流程分为四步：

  • 数据收集：收集 Hermes-SDK 上报的 key 访问事件；
  • 热度滑窗：对 App 的每个 Key，维护一个时间轮，记录基于当前时刻滑窗的访问热度；
  • 热度汇聚：对 App 的所有 Key，以 的形式进行 热度排序汇总；
  • 热点探测：对 App，从 热 Key 排序汇总 结果中选出 TopN 的热点 Key ，推送给 Hermes-SDK；

数据收集

Hermes-SDK通过本地 rsyslog将 key 访问事件以协议格式放入 kafka，Hermes 服务端集群的每个节点消费 kafka 消息，实时获取 key 访问事件。

访问事件协议格式如下：

1.appName：集群节点所属业务应用
2.uniqueKey：业务应用 key 访问事件 的 key
3.sendTime：业务应用 key 访问事件 的发生时间
4.weight：业务应用 key 访问事件 的访问权值

Hermes 服务端集群节点将收集到的 key 访问事件存储在本地内存中，内存数据结构为 Map<string,map>，对应业务含义映射为 Map<appname,map>。

热度滑窗
在这里插入图片描述

时间滑窗
Hermes 服务端集群节点，对每个 App 的每个 key，维护了一个 时间轮：

  • 时间轮中共 10 个 时间片，每个时间片记录当前 key 对应 3 秒时间周期的总访问次数；
  • 时间轮 10 个时间片的记录累加即表示当前 key 从当前时间向前 30 秒时间窗口内的总访问次数；

映射任务

Hermes 服务端集群节点，对每个 App 每 3 秒 生成一个 映射任务，交由节点内 “缓存映射线程池” 执行。映射任务内容如下：

  • 对当前 App，从 Map<appname,map>< appname,map<="" code="">中取出 appName 对应的 Map Map>；
  • 遍历 Map>中的 key，对每个 key 取出其热度存入其 时间轮 对应的时间片中；

热度汇聚

在这里插入图片描述

完成第二步“热度滑窗”后，映射任务继续对当前 App 进行“热度汇聚”工作：

  • 遍历 App 的 key，将每个 key 的 时间轮 热度进行汇总（即 30 秒时间窗口内总热度）得到探测时刻 滑窗总热度；
  • 将 < key , 滑窗总热度 > 以排序集合的方式存入 Redis 存储服务 中，即 热度汇聚结果；

热点探测

  • 在前几步，每 3 秒 一次的 映射任务 执行，对每个 App 都会产生一份当前时刻的 热度汇聚结果
  • Hermes 服务端集群 中的“热点探测”节点，对每个 App，只需周期性从其最近一份 热度汇聚结果 中取出达到热度阈值的 TopN 的 key 列表，即可得到本次探测的 热点 key 列表；

TMC 热点发现整体流程如下图：
在这里插入图片描述

特性总结

实时性

Hermes-SDK 基于rsyslog + kafka 实时上报 key 访问事件。映射任务3 秒一个周期完成“热度滑窗” + “热度汇聚”工作，当有 热点访问场景出现时最长 3 秒即可探测出对应 热点 key。

准确性

key 的热度汇聚结果由“基于时间轮实现的滑动窗口”汇聚得到，相对准确地反应当前及最近正在发生访问分布。

扩展性

Hermes 服务端集群节点无状态，节点数可基于 kafka 的 partition 数量横向扩展。

“热度滑窗” + “热度汇聚” 过程基于 App 数量，在单节点内多线程扩展。

参考资料：https://tech.youzan.com

Java Servlet 高并发场景下的性能优化的最佳实践
欢迎来到我的优快云空间！这里聚焦AI大模型应用实战，分享前沿技术、实战案例与开发经验。
04-12 1151
本文旨在为Java开发者提供一套完整的Servlet高并发性能优化方案，涵盖从基础配置到高级调优的各个方面。我们将重点关注生产环境中常见的性能问题和解决方案。文章首先介绍Servlet的基本工作原理，然后深入分析性能瓶颈，接着提供具体的优化策略，最后通过实际案例展示优化效果。Servlet容器：管理Servlet生命周期的运行环境，如Tomcat、Jetty等：每秒查询数，衡量系统吞吐量的关键指标：每秒事务数，衡量系统处理能力云原生趋势：容器化部署带来的新调优维度GraalVM。
Golang读写锁实战：高并发场景下的最佳实践
Golang编程笔记的博客
06-20 314
在高并发的程序里，多个线程或者协程可能会同时访问和修改共享资源。如果没有合适的并发控制机制，就可能会出现数据不一致、程序崩溃等问题。Golang的读写锁就是为了解决这类问题而设计的工具。本文的目的就是帮助大家学会如何在高并发场景下正确使用Golang的读写锁，范围涵盖了读写锁的基本概念、原理、使用方法以及实际应用等方面。本文首先会介绍与读写锁相关的核心概念，包括什么是读写锁、读锁和写锁的区别等。然后讲解读写锁的算法原理和具体的操作步骤，还会给出相关的数学模型和公式。
高并发“热点”缓存数据快速“退火”
热门推荐
优快云研发技术
11-25 1万+
背景电商场景促销活动的会场页由于经常集中在某个时间点进行“秒杀”促销，这些页面的QPS（服务器每秒可以处理的请求量）往往特别高，数据库通常无法直接支撑如此高QPS的请求，常见的解决方案是让大部分相同信息的请求都尽可能地压在缓存（cache）上来缓解数据库（DB）的压力，从而尽可能地去满足高并发访问的诉求（如图2-1所示）。图2-1 常规数据缓存方案在一次业务促销过程中，运营给一大批用户集中推送了一
【高并发】热点数据更新导致CPU100%的解决方案
DreamSun的博客
08-03 835
在平常的工作中，更新数据是再正常不过的一个需求了，我们只需要执行一个update语句即可，如果有必要我们还可以加上事务来保证数据的可靠性。但是如果这是一个热点数据，就比如说直播下单，如果这个商品很火爆，价格又很低，那么就会有很多人下单，这种下单不像秒杀，秒杀是有限制数量，但是这种直播下单是不限量的，可以同时有很多人在下单，这时候用户来下单，那么首先就要判断库存是否足够，如果有库存，那么就更新库存。这时候，这个库存就成了热点数据，因为如果有几万人同时下单，那么就会导致同时有几万个线程来更新这个库存数据。
高并发系统设计：缓存的读写策略
weixin_40108561的博客
07-22 418
缓存分类 静态缓存、分布式缓存、热点本地缓存。 静态缓存通过生成 Velocity 模板或者静态 HTML 文件来实现。部署在Nginx，可以减少对于应用服务器的压力。 分布式缓存典型的就是我们平常用来存储动态数据的redis。 热点本地缓存指的是一些极端热点的数据，比如某凡的瓜，主要部署在代码层面，阻挡热点查询对于分布式缓存节点和数据库节点的压力。 由于本地缓存是部署在应用服务器中，而应用服务器通常会部署多台，当数据更新时，不能确定哪台服务器本地中了缓存，更新或者删除所有服务器的缓存不是一个好的选择，所
有赞透明多级缓存解决方案（TMC）设计思路
cpongo011702
04-05 541
引子TMC 是什么TMC，即“透明多级缓存（Transparent Multilevel Cache）”，是有赞 PaaS 团队给公司内应用提供的整体缓存解决方案。TMC 在通用“分布式缓存解决方案（如 CodisProxy + Redis，如有赞自研分布式缓存系统 zanKV）”基础上，增加了以下功能：应用层热点探测应用层本地缓存应用层缓存命中统计以帮助应用层解决缓存使用过程中出现的热点访问问题...
redis热点key解决方案_多级缓存解决方案（TMC）
weixin_39612122的博客
12-03 754
一、引子1-1. TMC 是什么TMC ，即“透明多级缓存( Transparent Multilevel Cache )”，是有赞 PaaS 团队给公司内应用提供的整体缓存解决方案。TMC 在通用“分布式缓存解决方案(如 CodisProxy + Redis ，如有赞自研分布式缓存系统 zanKV )”基础上，增加了以下功能：应用层热点探测应用层本地缓存应用层缓存命中统计以帮助应用层解决缓存使用...
排行榜系统设计：高并发场景下的最佳实践
孤芳不自赏
08-29 1220
Hello，大家好！我是你们的技术分享小伙伴小米，29岁，喜欢技术，也喜欢分享各种有趣的项目经验。今天，我们来聊聊如何设计一个。无论是游戏中的战力排行榜，还是电商平台的热销产品榜单，排行榜都在我们生活中扮演了重要的角色。而作为一个技术人，设计一个高效、稳定、易扩展的排行榜系统是非常有成就感的。下面，我将带你一步步探讨如何设计一个排行榜。
大数据数据服务架构设计：最佳实践与案例分析
AI天才研究院
04-23 1846
在数据量呈指数级增长（IDC预测2025年全球数据量将达175ZB）、业务需求快速迭代（如实时推荐、智能风控）的背景下，传统“烟囱式”数据处理模式（各业务线独立开发数据接口）已无法满足企业需求。本文聚焦大数据数据服务架构如何构建高并发、低延迟的数据服务接口？如何实现多源异构数据的统一服务化封装？如何平衡数据服务的实时性与成本？如何保障数据服务的安全性与可治理性？第2章：解析数据服务架构的核心概念与分层模型；第3章：拆解关键组件的技术实现（含Python代码示例）；
【并发访问控制】：Python字典在多线程环境下的最佳实践
[【并发访问控制】：Python字典在多线程环境下的最佳实践](https://img-blog.csdnimg.cn/e95da9f8054f4657a545af416114738c.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LiA5...
Redis缓存及热点key问题解决方案
08-19
主要介绍了Redis缓存及热点key问题解决方案,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
高并发场景下对热点数据的处理
银湖冰河
07-02 2031
高并发场景下对热点数据的处理 1、在支付、物联网、超大人群红包领取等业务场景下，对于高并发问题有缓存、集群、分库分表等方式解决。 2、依然可能存在单条热点数据的的问题，例如热点商户的账务数据（就是mysql上的一条记录），可能同时有数十万人在往上面转账，这种情况下是不可能全部同步update到这条记录的。或者是商家准备一笔钱给社交网络发放红包（发放时机依赖用户行为，不能分批主动发送），需要在高并发下对这条账户减钱成功，并不会减成负数。 解决方案： 第一种可以称之为加钱频繁账户，可以采用加钱时只做记录，然后
Redis的热点key
沐白的博客
09-04 1603
在Redis中，我们把访问频率高的key，称为热点key。如果某一热点key的请求到服务器主机时，由于请求量特别大，可能会导致主机资源不足，甚至宕机，从而影响正常的服务。主要会带来这些问题: 资源过载或者内存资源紧张、负载不均衡、主从同步延迟、缓存击穿.CPU资源过载：如果某个Key被频繁访问，处理这些请求的Redis实例可能出现CPU过载的情况，导致处理其他请求的能力下降，影响整体性能。
【redis】热点key问题
weixin_44823875的博客
10-16 3001
热key问题就是某个瞬间有大量的请求去访问Redis上某个固定的key，导致缓存击穿，请求都打到了DB上，压垮了缓存服务和DB服务，从而影响到应用服务可用的可用性；被大量刊发、浏览的热点新闻、热点评论、明星直播等，这些典型的读多写少的场景就会产生热点key问题；相对DB，Redis的查询性能会高不少，但是再好的查询性能也是有阈值的。Rdis单节点的查询性能一般在2W的QPS，因此，对于单个固定key的查询不能超过这个值；
Redis——热点key问题
娜娜米的博客
06-06 1万+
本篇主要介绍Redis中的热点Key问题，包括热点Key产生的原因、如何监控发现热点key以及热点Key的解决方案；
Redis中的热点Key问题
qq_46130027的博客
05-05 881
在Redis中，我们把访问频率高的key，称为热key。比如突然有几十万的请求去访问redis中某个特定的key，那么这样会造成redis服务器短时间流量过于集中，很可能导致redis的服务器宕机。那么接下来对这个key的请求，都会直接请求到我们的后端数据库中，从而可能导致后端服务不可用。进而导致服务雪崩。简单理解，热Key就是访问频率高的那些Key。
Redis Key的层级格式
人生苦短，何妨一试
05-25 1541
key 的结构 Redis的key允许有多个单词形成层级结构，多个单词之间用":"隔开，格式如下： 项目名:业务名:类型:id 格式非固定，可以根据自己的需求来删除或添加词条 name相关的key: test:name:1 value: {"id":1,"name":"Jack","age":21},{"id":2,"name":"make","age":18} set test:name:1 '{"id":1,"name":"Jac...
Redis热点Key发现及常见解决方案
hellozhxy的博客
08-18 1932
一、热点Key问题产生的原因 1、用户消费的数据远大于生产的数据（热卖商品、热点新闻、热点评论、明星直播）。 在日常工作生活中一些突发的的事件，例如：双十一期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击浏览或者购买时，会形成一个较大的需求量，这种情况下就会造成热点问题。 同理，被大量刊发、浏览的热点新闻、热点评论、明星直播等，这些典型的读多写少的场景也会产生热点问题。 2、请求分片集中，超过单 Server 的性能极限。 在服务端读数据进行访问时，往往会对数据进行分片切分，此过程中会
Redis中的热点Key问题及解决方案
m0_73355421的博客
01-19 2133
Redis作为常用的缓存解决方案，其性能和稳定性至关重要。然而，在高并发场景下，Redis可能会遇到热点Key问题，即大量请求集中在同一个Key上，导致缓存击穿，影响数据库服务，甚至拖垮整个应用。本文将详细解析热点Key问题的原理、如何发现热点Key以及如何通过多级缓存策略解决这一问题。
微服务在高并发环境的挑战和实践有哪些
最新发布
10-03
在高并发环境下，微服务架构虽然具备良好的可扩展性和灵活性，但也面临诸多挑战。这些挑战主要来源于 **服务间通信、资源竞争、系统复杂性上升、故障传播风险增加** 等因素。 以下是微服务在高并发环境下的核心挑战与应对实践的详尽分析： --- ## ✅ 一、主要挑战 | 挑战 | 描述 | |------|------| | 1. **服务雪崩（Cascading Failure）** | 某个服务响应慢或宕机，导致调用方线程阻塞，进而拖垮整个调用链。 | | 2. **网络延迟与抖动加剧** | 高并发下网络拥塞，RTT 增加，影响服务间通信性能。 | | 3. **数据库连接池耗尽 / 锁竞争激烈** | 多实例同时访问数据库，引发连接瓶颈或死锁。 | | 4. **服务发现与负载均衡压力大** | 注册中心（如 Nacos、Eureka）可能成为瓶颈。 | | 5. **分布式追踪与监控困难** | 请求路径变长，定位性能瓶颈复杂。 | | 6. **限流降级策略缺失导致系统崩溃** | 缺乏保护机制时，突发流量直接压垮后端服务。 | | 7. **数据一致性难以保证** | 分布式事务成本高，并发写操作易引发脏读、幻读等问题。 | --- ## ✅ 二、关键实践与解决方案 ### 1. **熔断与降级：防止雪崩** #### 原理： 当某个依赖服务失败率达到阈值时，自动“熔断”对该服务的调用，避免资源耗尽。 #### 实践工具： - **Hystrix（已停更）** - **Resilience4j（推荐，轻量级 Java 库）** - **Sentinel（阿里巴巴开源，支持流量控制、熔断、系统自适应）** #### Sentinel 示例代码（Java + Spring Cloud Alibaba）： ```java @RestController public class OrderController { @GetMapping("/order") @SentinelResource(value = "getOrder", blockHandler = "handleBlock", // 流控/熔断时触发 fallback = "fallback") // 异常时降级逻辑 public String getOrder() { // 模拟业务逻辑 if (Math.random() < 0.2) throw new RuntimeException("Service Error"); return "Order Data"; } public String handleBlock(BlockException ex) { return "请求过于频繁，请稍后再试"; } public String fallback(Throwable t) { return "系统繁忙，使用缓存数据"; } } ``` > ✅ 效果：当 QPS 超过设定阈值或错误率过高时，自动返回降级结果，保护系统稳定。 --- ### 2. **限流（Rate Limiting）：控制入口流量** #### 目标： 防止突发流量击穿系统，保障核心服务可用。 #### 常见算法： - **令牌桶（Token Bucket）** - **漏桶（Leaky Bucket）** - **滑动窗口计数器（Sliding Window）** #### 实践方式： ##### （1）网关层限流（API Gateway） 使用 **Spring Cloud Gateway + Redis + Lua 脚本** 实现分布式限流： ```yaml # application.yml spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path=/api/order/** filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 10 # 每秒补充10个令牌 redis-rate-limiter.burstCapacity: 20 # 最大突发容量 key-resolver: "#{@ipKeyResolver}" # 按IP限流 ``` ```java @Bean public KeyResolver ipKeyResolver() { return exchange -> Mono.just( exchange.getRequest().getRemoteAddress().getHostName() ); } ``` > ✅ 效果：每 IP 最多每秒处理 10 个请求，峰值允许 20，超出则返回 `429 Too Many Requests`。 --- ### 3. **异步通信与消息队列解耦** #### 场景： 将同步调用改为异步处理，削峰填谷。 #### 架构演进： ``` [用户下单] → [订单服务] → 同步调用 → [库存服务] ❌（高并发下容易失败） ↓ [用户下单] → [订单服务] → 发送消息 → [Kafka/RocketMQ] → [库存服务异步消费] ✅ ``` #### 使用场景： - 订单创建后通知积分、优惠券、物流等服务 - 日志收集、审计记录异步落库 #### 示例（Spring Boot + Kafka）： ```java @Service public class OrderService { @Autowired private KafkaTemplate<String, String> kafkaTemplate; public void createOrder(Order order) { // 1. 创建订单 orderRepository.save(order); // 2. 异步发送消息 kafkaTemplate.send("order-topic", order.getId(), JSON.toJSONString(order)); } } ``` ```java @KafkaListener(topics = "order-topic") public void consumeOrder(String orderId, String message) { // 更新库存、发放积分等 } ``` > ✅ 效果：提升吞吐量，降低服务耦合度，增强系统容错能力。 --- ### 4. **缓存优化：减少数据库压力** #### 分层缓存策略： ``` Client → CDN → API Gateway → Redis → DB ``` #### 实践建议： - 使用 **Redis Cluster** 支持横向扩展 - 设置合理过期时间 + 热点 Key 探测 - 使用 **本地缓存（Caffeine）+ 分布式缓存（Redis）** 双层结构 #### Caffeine + Redis 示例（两级缓存）： ```java @Cacheable(value = "user", key = "#id", sync = true) public User getUser(Long id) { User user = caffeineCache.getIfPresent(id); if (user != null) return user; // 缓存穿透防护 user = redisTemplate.opsForValue().get("user:" + id); if (user == null) { user = userRepository.findById(id).orElse(null); if (user != null) { redisTemplate.opsForValue().set("user:" + id, user, Duration.ofMinutes(30)); } else { redisTemplate.opsForValue().set("user:" + id, NULL_USER, Duration.ofMinutes(5)); // 空值缓存 } } caffeineCache.put(id, user); return user; } ``` > ✅ 防止缓存穿透、击穿、雪崩。 --- ### 5. **数据库优化：读写分离 + 分库分表** #### 问题： 单库无法承受百万级 QPS 写入。 #### 解决方案： | 方案 | 说明 | |------|------| | **读写分离** | 主库写，多个从库读，通过中间件（如 ShardingSphere）路由 | | **分库分表** | 按用户 ID、订单 ID 等字段水平拆分 | #### ShardingSphere 配置示例（YAML）： ```yaml dataSources: ds_0: # 主库 url: jdbc:mysql://master:3306/db_order ds_1: # 从库 url: jdbc:mysql://slave:3306/db_order rules: - !READWRITE_SPLITTING dataSources: pr_ds: writeDataSourceName: ds_0 readDataSourceNames: [ds_1] - !SHARDING tables: t_order: actualDataNodes: ds_${0..1}.t_order_${0..3} tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: order_inline shardingAlgorithms: order_inline: type: INLINE props: algorithm-expression: t_order_${order_id % 4} ``` > ✅ 支持千万级数据量下的高效查询。 --- ### 6. **全链路压测与容量规划** #### 目的： 提前发现系统瓶颈，评估扩容需求。 #### 工具： - **JMeter / Gatling**：模拟高并发请求 - **阿里全链路压测平台（Takin）**：真实流量复制 + 影子库隔离 #### 实践流程： 1. 标记压测流量（如 header 中加 `x-traffictype=stress`） 2. 压测数据写入影子表（不影响生产） 3. 监控各服务 CPU、内存、GC、DB 慢查询等指标 > ✅ 提前暴露性能瓶颈，避免大促期间宕机。 --- ### 7. **可观测性建设：Metrics + Logs + Traces** #### 工具栈： - **Prometheus + Grafana**：监控 QPS、延迟、错误率 - **Loki**：集中日志查询 - **Tempo / Jaeger**：分布式追踪 #### 关键指标监控： ```promql # 请求速率 rate(http_server_requests_seconds_count[1m]) # P99 延迟 histogram_quantile(0.99, sum(rate(http_server_requests_seconds_bucket[1m])) by (le)) # 错误率 sum(rate(http_server_requests_seconds_count{status=~"5.*"}[1m])) / sum(rate(http_server_requests_seconds_count[1m])) ``` > ✅ 快速定位慢接口、异常源头。 --- ### 8. **弹性伸缩与自动扩缩容（HPA）** #### Kubernetes HPA 示例： ```yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: order-service-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-service minReplicas: 3 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: External external: metric: name: http_requests_per_second selector: {matchLabels: {service: order-service}} target: type: AverageValue averageValue: "1000" ``` > ✅ 根据 CPU 或自定义指标自动扩容 Pod 数量。 --- ## ✅ 三、总结：高并发微服务最佳实践清单 | 类别 | 推荐做法 | |------|---------| | **稳定性** | 熔断、降级、限流、超时设置 | | **性能** | 缓存、异步化、数据库优化 | | **可扩展性** | 微服务拆分合理、无状态设计、K8s 自动扩缩容 | | **可观测性** | 全链路追踪、统一监控告警 | | **容灾能力** | 多副本部署、跨可用区容灾、灰度发布 | | **开发规范** | 接口幂等性、防重提交、优雅关闭 | ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值