我的解决思路,非精确统计(我觉得这个需求也没必要太精确统计),但是对原架构几乎无侵入,架构也不用做任何修改。直接聚合统计access log就行了。我们假定用户看视频平均停留是5分钟,那么筛选最后5分钟访问这个页面地址的记录count一下就行了,也就是说最后5分钟访问过这个页面的访问记录,我们都假定是用户在看这个视频。为了更精确一些,可以剔除一些机器人的UA。这个方法最简单,不是特别精确,但是前端几乎不用做任何处理。如果非要用redis的话,你可以弄个后台定时任务定期去聚合统计access log把select video_page_url, count(*) from access_log group by video_page_url where timestamp >= (now() - 5min)(伪SQL描述)结果写入redis就行了。日志本来就是纯文本的,你用各种文本处理工具通过正则就可以解析,你也可以直接用现成的access log分析工具,比如goaccess https://goaccess.io/ ,就支持nginx和apache即开即用的分析,可以脚本化
前后端通信一般是用 websocket, 这个地方轮询也可以感觉也没必要用redis吧, 多少人再看, 可以直接读取这个视频流链接地址的链接量不就好了, 这个应该都可以吧. 这种应该是由视屏服务那边应该直接暴露, 不应该由后端处理吧
利用视频缓存。先用redis设置一个过期时间为用户已经加载视频的时间,每下载一段视频就加对应视频片段的播放长度作为要增加的ttl到redis对应的用户。利用用户观看进度。这里也可以动手脚的,如果长期没有收到用户发送的进度记录请求就直接跳过对应统计,防止用户提前关闭视频,或者发送的进度一直没有变就跳过。或者使用ws,这个代价就有点高了。这样就基本保证了“正在看”这个需求。
我的解决思路,非精确统计(我觉得这个需求也没必要太精确统计),但是对原架构几乎无侵入,架构也不用做任何修改。
直接聚合统计access log就行了。我们假定用户看视频平均停留是5分钟,那么筛选最后5分钟访问这个页面地址的记录count一下就行了,也就是说最后5分钟访问过这个页面的访问记录,我们都假定是用户在看这个视频。为了更精确一些,可以剔除一些机器人的UA。
这个方法最简单,不是特别精确,但是前端几乎不用做任何处理。如果非要用redis的话,你可以弄个后台定时任务定期去聚合统计access log把
select video_page_url, count(*) from access_log group by video_page_url where timestamp >= (now() - 5min)
(伪SQL描述)结果写入redis就行了。日志本来就是纯文本的,你用各种文本处理工具通过正则就可以解析,你也可以直接用现成的access log分析工具,比如goaccess https://goaccess.io/ ,就支持nginx和apache即开即用的分析,可以脚本化