高并发架构-发现热点

关注

原创最新推荐文章于 2026-08-10 15:51:59 发布 470 阅读 AI 写同款· GEO 优化 ›

高并发“热点”缓存数据快速“退火” 背景电商场景促销活动的会场页由于经常集中在某个时间点进行“秒杀”促销，这些页面的QPS（服务器每秒可以处理的请求量）往往特别高，数据库通常无法直接支撑如此高QPS的请求，常见的解决方案是让大部分相同信息的请求都尽可能地压在缓存（cache）上来缓解数据库（DB）的压力，从而尽可能地去满足高并发访问的诉求（如图2-1所示）。图2-1 常规数据缓存方案在一次业务促销过程中，运营给一大批用户集中推送了一阅读详情

高并发项目通常是javaWeb 项目中ToC 场景，例如常见的秒杀，抢票。
从项目开发到上线，整个项目周期都需要关注热点数据，准去的预测和监控热点数据可以帮助开发更好的实现系统。
这篇文章从小处入手，浅析高并发的架构设计。

一、什么是热点

热点分为热点操作和热点数据。

1.1热点操作

所谓“热点操作”，例如大量的刷新页面、大量的添加购物车、双十一零点大量的下单等都属于此类操作。对系统来说，这些操作可以抽象为“读请求”和“写请求”，这两种热点请求的处理方式大相径庭（差不多），读请求的优化空间要大一些，而写请求的瓶颈一般都在存储层，优化的思路就是根据 CAP 理论做平衡。

1.2 热点数据

而“热点数据”比较好理解，那就是用户的热点请求对应的数据。而热点数据又分为“静态热点数据”和“动态热点数据”。

静态热点数据

所谓“静态热点数据”，就是能够提前预测的热点数据。例如，我们可以通过卖家报名的方式提前筛选出来，通过报名系统对这些热点商品进行打标。另外，我们还可以通过大数据分析来提前发现热点商品，比如我们分析历史成交记录、用户的购物车记录，来发现哪些商品可能更热门、更好卖，这些都是可以提前分析出来的热点。

动态热点数据

所谓“动态热点数据”，就是不能被提前预测到的，系统在运行过程中临时产生的热点。例如，卖家在抖音上做了广告，然后商品一下就火了，导致它在短时间内被大量购买。

二、发现热点

架构通常是分层和异构的，我们利用Linux 、jvm 或者mysql的监控工具通常可以准确的定位热点操作

2.1 nginx 日志分析

nginx 日志中包含请求路径，可以通过命令分析热点请求路径：

cat log_file|awk '{print $11}'|sort|uniq -c|sort -nr | head -10

cat log_file|awk '{print $11}'|sort|uniq -c|sort -nr|head -20

awk '{print $1}' log_file |sort -n -r |uniq -c | sort -n -r | head -20

如果使用阿里云服务器，其访问入口自带热点分析功能。

或者使用工具搭建一套日志分析服务

在这里插入图片描述

GoAccess is an open source real-time web log analyzer and interactive viewer that runs in a terminal in *nix systems or through your browser.

It provides fast and valuable HTTP statistics for system administrators that require a visual server report on the fly.

https://goaccess.io/features

2.1 业务日志分析热点

业务员日志经过阿里云日志分析系统
可以根据业务关键词查找分析业务热点

2.3 Redis 热点数据分析

Redis可以使用Monitor 命令查看实时Redis 操作

redis-faina的两种用法：

1，可以通过管道从stdin读取N条命令

redis-cli -p port MONITOR | head -n <NUMBER OF LINES TO ANALYZE> | ./redis-faina.py [options]

2，也可以从一个文件中读取N条命令

redis-cli -p port MONITOR | head -n <NUMBER OF LINES TO ANALYZE> > /tmp/outfile.txt
./redis-faina.py /tmp/outfile.txt

# redis-cli -p 6381 MONITOR | head -n 10000 | ./redis-faina.py
Overall Stats
========================================
Lines Processed  10000
Commands/Sec     274.73
Top Prefixes   #按照key的前缀统计
========================================
testcache-rendsord-lang        1684(16.84%)
testcache-inuanGoods-id        1090(10.90%)
testcache-riceroup-cat_id      307 (3.07%)
testcache-ategorynfo-id        190 (1.90%)
testcache-ategoryey-lang       189 (1.89%)
testcache-earchtrremplate-id  61  (0.61%)
testcache-riceroup-id          15  (0.15%)
testcache-otordata-lang       9   (0.09%)
Top Keys     #请求最频繁的key
========================================
testcache-acebookhareandsave  2373(23.73%)
testcache-hippingFee           2198(21.98%)
testcache-rendsord-lang:en    1464(14.64%)
testcache-ountryurrency       1181(11.81%)
testcache-inuanoods          442 (4.42%)
testcache-ategoryey-lang:     183 (1.83%)
testcache-rendsord-lang:es    124 (1.24%)
testcache-inuanoods-id:68    114 (1.14%)
Top Commands     # 执行最频繁的命令
========================================
GET      9957(99.57%)
AUTH     13  (0.13%)
COMMAND  13  (0.13%)
SADD     10  (0.10%)
info     5   (0.05%)
SET      1   (0.01%)
Command Time (microsecs)    # 命令执行时长
========================================
Median  2309.0
75%     4959.75
90%     8447.0
99%     18482.0
Heaviest Commands (microsecs)    #耗时最多的命令
========================================
GET      36281717.75
COMMAND  85269.25
SADD     17985.75
info     10698.5
SET      3228.0
AUTH     625.5
Slowest Calls     #执行最慢的命令
========================================
179962.0  "GET" "testcache-hippingee"
62659.0   "GET" "testcache-romotionullateeduce"
44902.0   "GET" "testcache-hippingee"
40305.25  "GET" "testcache-hippingee"
39559.0   "GET" "testcache-hippingee"
36831.25  "GET" "testcache-hippingee"
33852.0   "GET" "testcache-hippingee"
33501.0   "GET" "testcache-hippingee"