电视广告计费高并发设计问题

电视广告计费高并发设计问题

葬花如无物 发布于 2021-11-24 字数 613 浏览 804 回复 4

目前遇到一个关于电视广告计费问题,详细如下:

一、需求简单概括为:一则广告可以被播放多少次(根据$决定),超过次数则不能再播放。目前前端多台应用服务器通过均衡器转发,需要解决播放次数准确计数。

二、遇到的瓶颈为:

1、如果使用一台Redis做次数统计,前端10台应用服务器对一台Redis压力过大。

2、大量客户端(国外网络电视)正在播放某部非常热门电视栏目时候,大量的广告请求导致后端压力异常巨大,目前预估计高压情况下实时请求数为50w-70w。

3、由于每个客户端看到的广告可能不一样,所以不能预先编排。

4、由于是电视机原因,窗口排队等机制可能不是很好,一般要求3s内返回。

如果你对这篇文章有疑问,欢迎到本站 社区 发帖提问或使用手Q扫描下方二维码加群参与讨论,获取更多帮助。

扫码加入群聊

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

秋意浓 2021-12-01 4 楼

引用来自“lieefu”的评论

所谓客户端,并不是指机顶盒,你的系统内哪个环节可以记录以及控制广告播放次数的? 在你能控制的环节编程缓存广告次数,用来在清算时段汇总上报,或者被轮询.

南汐寒笙箫 2021-12-01 3 楼

所谓客户端,并不是指机顶盒,你的系统内哪个环节可以记录以及控制广告播放次数的? 在你能控制的环节编程缓存广告次数,用来在清算时段汇总上报,或者被轮询.

心舞飞扬 2021-12-01 2 楼

引用来自“lieefu”的评论

把银行业账务清算的概念纳入进你的电视广告计费系统中,解决高并发设计问题,方法是:

比如规定一个小时清算一次(如果实时控制要求高可以设置几分中清算一次),在一小时内,非清算状态下,客户端自己记录播放广告的次数,清算时,服务器轮询,或者客户端主动报送,上个小时内的播放次数数据。由服务端汇总。这样就把即时压力,分摊开来,从而解决了高并发问题。

一个清算场次内的数据,可以压缩上报,也能解决网络峰值压力。

反目相谮 2021-12-01 1 楼

把银行业账务清算的概念纳入进你的电视广告计费系统中,解决高并发设计问题,方法是:

比如规定一个小时清算一次(如果实时控制要求高可以设置几分中清算一次),在一小时内,非清算状态下,客户端自己记录播放广告的次数,清算时,服务器轮询,或者客户端主动报送,上个小时内的播放次数数据。由服务端汇总。这样就把即时压力,分摊开来,从而解决了高并发问题。

一个清算场次内的数据,可以压缩上报,也能解决网络峰值压力。