本文讨论了在高并发环境下，如何有效统计页面浏览量（PV）。通过引入二级缓存，结合JVM内存和Redis，降低对Redis的访问压力。文章详细介绍了二级缓存的实现，包括时间块的概念，以及定时任务同步数据到数据库和Redis的过程，以实现高效并发处理。
高并发 PV 问题
他的文章标题是这样的：
首先他给出了一个业务场景：在一些需要统计 PV(Page View), 即页面浏览量或点击量高并发系统中，如：知乎文章浏览量，淘宝商品页浏览量等，需要统计相应数据做分析。
比如我的公众号阅读量大概在 3000 左右，如果要统计我这种小号主的 PV 其实就很简单，就用 Redis 的 incr 命令轻轻松松就实现了。
但是，假设微信公众号每天要统计 10 万篇文章，每篇文章的访问量 10 万，如果采用 Redis 的 incr命令来实现计数器的话，每天 Redis=100 亿次的写操作，按照每天高峰 12 小时来算，那么 Redis 大约 QPS=57万。
如此大的并发量，CPU 肯定满负载运行，网络资源消耗也巨大，所以直接使用 incr 命令这种技术方案是行不通的。
假设这是一个面试场景题，你会怎么去回答呢？
其实你也别想的有多复杂，剥离开场景，这无外乎就是一个高并发的问题。
而高并发问题的解决方案，基本上逃不过这三板斧：缓存、拆分、加钱。
所以这个老哥给出的方案就是：缓存。
二级缓存
Redis 都已经是缓存了，那么再加缓存算什么回事呢？
那就算是二级缓存了。
而且这个缓存，就在 JVM 内存里面，比 Redis 还快。
其核心思想是减少 Redis 的访问量。这些理论的东西，大家应该都知道。
那么通过什么方案去减少 Redis 的访问量呢，这个二级缓存应该怎么去设计呢？
首先，文章服务采用了集群部署，在线上可以部署多台。
然后每个文章服务，增加一级 JVM 缓存，即用 Map 存储在 JVM，key 为当前请求所属的时间块。
就是这个意思：
Map<Long,Map<Integer,Integer>> = Map<时间块，Map<文章id,访问量>>
但是我觉得巧妙的地方在于这里提到的“时间块”的概念。
什么是时间块?
就是把时间切割为一块块，例如：一篇文章在1小时，30分钟、5分钟的时间内产生了多少阅读量。
如何切割时间块呢？
这里利用到了时间是不断增长的特性。
时间戳是自 1970 年1月1日（00:00:00 GMT）至当前时间的总数，通过确定时间块大小，算出当前请求所属的时间戳从 1970 年算起位于第几个时间块，这个算出来的第几个时间块就是小时 key ，即 map 的 key。
举个例子：
我们把时间按照“小时”的维度进行划分。
先把当前的时间转换为为毫秒的时间戳，然后除以一小时，即当前时间 T/1000*60*60=小时key，然后用这个小时序号作为key。
比如：
2021-12-26 15:00:00 = 1640502000000毫秒
那么小时key= 1
最低0.47元/天 解锁文章
扫一扫
3040
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
