• 使用 Redis 进行阅读数统计并定时持久化


    之前,统计每篇博文的阅读数的方式是经过筛选去重之后直接更新数据库,并发压力直接传导到数据库,假设1秒有1000个并发请求,传统方案会在1秒内并发进行1000次数据库更新操作。

    为了降低数据库的并发压力,需要重新设计统计服务。思路是即使1秒有1万个并发请求,也只是依次更新数据库,对数据库没有并发压力。

    统计服务要做的事情很专一:去重+计数

    去重的业务根据具体的需要来设计规则,例如一个用户1个小时内所有访问都只计算一次,没有用户信息的按 IP 地址或者浏览器标识去统计。去重就是把这些标志去重,有多种实现方法,Hash过滤,数据库唯一性等。

    这里我们采用 Redis 的 HyperLogLog ,简称HLL,它是一个高效的结构,内存占用极小,能快速统计出所有不一样的元素。有三个方法:
    PFADD:向结构中增加一个元素,其实 HLL 并没有存储这个元素,而是按照概率论的算法进行统计,所以 12K 内存就能统计 2^64 个数据,返回值为1表示该元素被统计了,反之则没有;
    PFMERGE:可以把合并两个 HLL
    PFCOUNT:获取统计数,这个算法虽然高效,但是也有弊端,就是存在误差,在 1% 以下,只要不是非常精确的业务基本上也是可以忽略的。

    我们的业务逻辑实现比较简单,可以用博文和时间作Keyhll_{postId}_{yyyymmddhh},再把访问博文的用户标志按照规则生成一个字符串,name_{userName} ip_{ipAddress},用PFADD它添加进去,HLL会判断是否重复,重复的就不会统计,然后把不重复的也就是返回值为 1 的 Key 存储到集合 SET 中,记录下来方便遍历。

    经过去重之后我们就要统计总数并持久化到数据库中,每篇博文在 Redis 中对应至少一个 HLL 结构,创建观察者服务不停地Pop SET中所有的 hll 的 Key,然后再通过PFCOUNT 得到对应的博文的统计数。 拿到统计数之后再发送给持久化服务处理,或者通过负载均衡交给多个持久化服务处理。

    如上图所示,部署多个 Counter web服务负责接收请求,一个 redis 服务或者集群负责统计阅读数,多个 watcher 服务负责把统计结果取出来,交给多个数据存储服务去持久化。

    我们线上用的是 docker-swarm 集群,它本身就有负载均衡作用,所以可以省略负载均衡。

    这里之所以用SET.POP(),是因为它支持并发访问的,不会锁 Redis。如果直接遍历所有 HLL Key,就只能用 SCAN 全局查找,虽然也不会锁住 Redis,但是它不支持并行操作,对扩展不够友好。

    这样架构的优点就是可以横向扩展,任何地方出现性能瓶颈都能通过扩展解决。

    参考资料
    多个消费者重复消费问题
    HypterLogLog
    HyperLogLog 原理

  • 相关阅读:
    动态规划——划分
    动态规划——子序列
    动态规划——棋盘
    广搜——变换类
    广搜——连通块
    贪心
    数学——大整数问题
    图论——生成树
    动态规划——面积覆盖
    广搜——路径寻找
  • 原文地址:https://www.cnblogs.com/kexxxfeng/p/redis-counter.html
Copyright © 2020-2023  润新知