【专题】应用计数案例归纳和总结

发表信息: December 20, 2021 by 欧阳Boy_Petter

字数：557 字， 预计阅读时间：5 分钟

• 分类:
• 总结 7
• 整理 20

• 标签:
• 计数 1
• 通用性 1
• 高并发 1

这是一次公司内的分享，个人感觉普适性应该比较高，这里分享下~

需要讨论的点

谈到计数，我们会讨论什么？

1. 高并发
2. 实时性
3. 准确性
4. 真实性
5. 一次性
6. 有效性
7. 复用性

我们需要从一些点来切入

1. 高低并发与否
2. 是否允许轻微误差
3. 最小业务维度内是否可重复
4. 是否双向计数
5. 虚拟计数
6. 是否一次性可消除
7. 是否受历史累计影响
8. 如何复用计数能力

示例展开，以点带面

个人以在云音乐接触或了解过的一些计数场景，这里抛转引玉，和大家一起讨论一下。

播放

特征：高并发、可重复、单向计数、实时级

解决方向：聚合处理、批量处理

不同数据层次或存储介质，流量承受能力不同。
网关 - 消息 - 缓存 - 数据库

播放本是一个可能发生高并发的事件，解决这类计数问题主要两个方向：
1、加快单元事件处理速度 ———— 拆分处理（一件事拆成多个步骤）
2、减少底层存储介质访问频率 ———— 聚合处理（多个事结果汇总）

云音乐内部提供了类似能力的成熟工具

略。

播放日志的常规处理流程或者步骤

由于播放行为的可重复性和操作简单性，且具有极大的并发性，目前成熟的做法基本是：

1. 记录不入库，或仅日志记录（播放日志）或存入搜索索引平台（比如 ES）
2. 计数二次分发（消息），且通过缓存层聚合，定时 hash 入库。

1、搜索索引平台，是成熟的大数搜索体系。比如日志的 ELK，一些公司也会自研搜索平台。
2、消息二次分发，可以让并发在一定范围更加均匀，抚平高并发突刺；消息也可以实现一定的可靠性。
3、缓存层聚合，可以极大减少数据库访问，提升存储性能；由于缓存层可靠性不够稳定，最好实现冷备或备用缓存。
4、hash 入库，服务器（消费者）通常通过计数表均衡字段选择消费，保证单台服务器处理的计数数据落到同一个数据库。

扩展：去噪

同一时刻，同一用户，同一视频，同一机器，产生了大量播放行为。（重复日志）
同一时间，同一用户，同一视频，不同机器，产生了大量播放行为。（反作弊）

真实计数和展示计数

业务初期由于流量不足，为了快速增长或吸引用户，通常都会做特殊的展示计数逻辑，即 Mock 计数。
新人为了扶持流量或 Buffer 加持也可能会采用 Mock 计数来增长展示计数。

一般 Mock 计数有如下类似的模式：

1. 展示计数给个随机初始计数，或算法定时计算随机给予展示计数一个增量扶持计数
2. 增量展示计数=增量真实计数 * 因子

不言而喻，【增量展示计数=增量真实计数 * 因子】更自然，因此很多文章做在因子上：

1. 因子=随机可选值
2. 因子=fn(时间变量)
3. 因子=fn(真实计数总量，时间变量)

由于，【增量真实计数】在固定时间窗内总数有不确定性，因此有一定的自然度，所以以上策略基本没有太大差异。

PS：不过随着时间的增长，因子的作用会越来越小，其实可以使用对数函数，让因子结果显得更自然。

点赞、收藏数

特征：实时级、双向计数、不可重复、允许轻微误差

用户行为的触发难度决定表现模式

1、某种用户行为触发越简单，其越容易发生，产生的流量越大，同样并发级也越高
2、某种用户行为可重复性越高，实现难度越低，越有可能产生大流量，同样并发级也越高
3、某种用户行为产生的利益越高，越有可能被作弊，越有可能产生大流量，同样并发级也越高

用户维度通用计数存储结构

用户互动行为通用计数能力复用

1、存储结构复用
2、Dao层逻辑复用（动态表）
3、消息逻辑复用（动态消息）
4、前后流程控制复用（入参控制）
    1）同时记录和计数
    2）先记录，异步计数

目前复用此能力的服务有：

1. SDK 方向（本地化）： 用户行为关系业务领域服务SDK
2. API/RPC 方向（服务化）： 互动中台接入文档

评论数

特征：即时级、可重复、不允许误差、双向计数

评论不仅是一种交互行为，还是一种资源

评论虽然是作为一种附属资源，但却拥有很多资源自身的独立业务。
除了普通的计数，还有其他相关业务计数。
------------------------------------------------------------
由于评论是一种计数，所见即所得，评论数对应会展示对应数量的评论。
------------------------------------------------------------
由于评论还带状态，我们初略分为：所有人可见、仅自见可见
故，某资源评论数=所有人可见评论数+仅自见可见评论数

评论计数表结构：略

分享数

特征：实时级一般、可重复、允许误差、单向计数

普通却不可少，有潜力却没机会

分享是产品借助流量传播的重要渠道，是所有互动里面必不可少的环节。
-----------------------------------------------
我们来看下分享这个交互的表面优势：
1、人人都爱分享，这个在社交里面是刚需
2、分享可以新增流量引入，增加曝光，造成更多的分享
3、分享可以重复，重复可以造成更多的流量，站内、微信、微博...
-----------------------------------------------
但是，分享没有优势基因：
1、分享是跨 APP 的，难以打破这种断层般体验感
2、分享比较隐私，操作会打断体验，触发成本比较高
3、分享不能做为激励指标，由于是跨 APP 操作，很难确定有效性
    PS：如果作为激励指标，由于它的重复性和跨APP操作，无法感知作弊，很容易被刷。

我的作品数

特征：即时级、双向计数、不允许误差、多状态

贯穿整个产品的生命周期

作品数记录着作品的生命周期指标，影响它变化的因素非常多样：
1、从作品发布后经历 反垃圾、人工审核 到确定可见性后
2、后续还会碰到用户主动删除
3、用户主动修改可见性
4、政策或突发事件导致重新审核导致下架
5、其他影响作品状态的因素

内容为王的当前，创作者体验是产品出位的重点：
1、作品数对于创作者是一种敏感性数据，如果出现误差会引起负反馈。
2、作品数对于客态访问者，如果出现不一致会引起产品信任危机。
3、作品数对于统计数据，如果作为激励或指标排名，会引起客诉。

云音乐产品的优势

云音乐相比于微信或微博，能够做出层次更加丰富的社交体验。
想要做出更丰富的社交体验，则需要做出更多层次的隐私权限。

Mlog 产品计数层次
1、NomalStatusCount（所有人可见）
2、OnlySelfSeeCount（仅自见，反垃圾导致）
3、UserDeleteCount（自己删除）

动态产品的计数层次
1、所有人可见
2、好友可见
3、仅粉丝可见
4、仅圈子可见
3、仅自见可见

多层次的隐私权限结构设计

话题参与人数

特征：实时性低、单向计数、允许误差

同样是作品产生的计数，却地位不同

某用户在某个话题下发布了作品，则认为该用户参与了此话题。
同样是作品发布产生的计数，其准确性、实时性却并不显得和作品数这般重要。
1、参与人数是单向计数，只能单向积累，作品状态变化不会影响计数。
2、话题参与人数并不是一个敏感指标，关注的用户不多。
3、话题参与人数只是一个参考数据，不能关键性影响话题本身的热度。

消息数、红点计数

特征：即时级、一次性、单向计数

一次性特征的计数业务

红点或数字气泡或者特殊引导属于一次性计数业务。
目标：引流、引导业务
特征：只要用户曝光过，就清零。
-----------------------------------------
计数仅单纯累加模式，清除用拉模式直接归零。

消息私信数（半一次性）

1、One to One 的私信计数主表（一次性特征）
略

2、用户私信总计数表（普通双向计数表，用户维度低并发）
略

动态红点计数（一次性）

用户维度的持久化缓存（redis）—— event_redis_count_key
1、业务 1： 动态流推荐数据，单纯累加 event_redis_count_key 缓存计数
2、业务 2： 共鸣匹配推荐数据，单纯累加 event_redis_count_key 缓存计数
3、业务 3： 音乐人新歌提醒，单纯累加 event_redis_count_key 缓存计数
4、业务 n： xxx，单纯累加 event_redis_count_key 缓存计数

热榜点击数

特征：实时级、高并发、单向计数、实时排序

时间窗口区计数缓存

热度计数最重要的就是规避历史高热度的累积资源，涉及到计数更新的问题
1、如何淘汰现在已经不热了的历史热度资源（范围计数 -> 时间窗口计数）
2、如何做到快速排序（维护时间窗口计数排序列表）
3、如何做到时间窗计数的连贯性（分片粒度+分段窗口）

异化计数： 话题热度

若将话题点击数改成话题热度，那么只需要一个增量的公式。
将点击数累积转化成热度值累积，则变成实时话题热度排行榜的需求。
而上述就是一种异化计数。
热度公式可以类似于： hotScore = clickCount * (100 / totalCount) + x

听歌记录数

高并发、实时性低、可重复、允许误差

BI 处理或缓存延迟处理

时间和准确性要求低的情况，基本可以延迟甚至离线处理。

思考

思考与应用

这里有几个现想的需求，大家可以思考下，可以看下他们分别归属于哪一类：

1. 动态需要开发专题，专题有订阅的功能，订阅这块的计数如何设计？
2. 云圈广场需要在云圈龙珠上展示每个圈子圈内所有未读的消息数，这块需要如何设计？
3. 云音乐要开发听歌沉浸时间的需求，需要统计听歌时长，并且出用户维度月报、周报听歌时长分析报告，如何设计？
4. 云音乐需要开发实时活跃歌曲在线听榜单，如何设计？

结语

什么是计数？

计数一般是针对资源附加属性，而资源涉及到方方面面，
它可以是用户产生的内容（我的作品数），
也可以是内容的附加描述（视频的播放数、点赞数），
也可以是一种产品描述（我的听歌总数），
甚至可以是一种异化的计数（我的听歌时长），
抑或是描述资源间的关系指标（我的好友数、关注我的人数）

我们发现，应用内的一切对象或元素（meta）都可以成为一种资源。
PS：用户是不是一种资源？ ———— 是的，用户也是一种资源，是一种特殊的资源。

这里，我们将计数异化定义下：一切累积效应的数字，可以认为是某种资源的计数。
它承担着重要的故事讲述能力。
首先，它显而易见的向用户传达，这个数字不是一蹴而就的，是慢慢积累的。
其次，它告诉用户：
  你这个人火不火，看你的粉丝数。
  你这个作品好不好，看你的播放数、点赞数。
  你这个产品优不优秀，看用户总数、使用时长、总活跃度。
  你这个应用热不热，看下载数、讨论热度。

我们做一个功能模块或产品内容，若给用户传达的累积量化指标很少。
用户不会理解这个产品的故事，他们就不会用时间去买单。

我们可以认为，计数是荣誉、成就感、归属感、标杆、方向、品牌图腾。

用户心智

当用户开始关注这些数据，被这些数据引导行为，并开始为这些数据买单时；随之而来的就是用户心智。