关于一个竞价广告系统的实现，服务器端和客户端的展示与扣费逻辑的优化。

[dreamramon]

最近因为需求需要做按展示竞价的广告系统的后台和客户端 sdk 。
其中通过集成客户端 sdk ，各种 app 可以从广告平台获得广告，并展示，从而帮助开发者和广告平台分账。

遇见一个经典的场景：

https://imgur.com/a/RFHB83E

因为有类似的信息流广告，那为了更流畅
当加载当前 view 的时候，广告 sdk 会一次向服务器请求 3 个广告位的广告信息（每个广告信息包括一张图片和一个链接）。服务器端收到请求后按当前的投放计划排名，锁定了 3 次扣费。
当客户端 view 加载完成时，因为广告 1 和广告 2 在 view 里，所以第一屏自然被显示。因此客户端 sdk 设计的广告显示成功的回调逻辑里，会发请求到服务器确认扣费。
如果用户向下滚动，广告 3 会被展示，从而请求服务器扣费。
如果用户没有向下滚动，广告 3 在服务器端的扣费队列里的锁定在一个时间后会解除锁定。

当前遇到的问题时：
1 ，因为用户不一定会滚动到下面展示广告 3 ，提前锁定的方法，导致了很多时候，如果不锁定可以参与下一次竞价，但是因为锁定了，浪费了的情况。
2 ，用户接电话出去，20 分钟后，再回到 app 向下滚动，这个时候，服务器端已经超时解锁了扣费，这个时候展示，有可能原有的用户的预算已经花完了。。。

不知道，有没有同学有更好的思路～～～

[zsj1029]

为什么要提前锁定扣费队列
既然可以做到滚动显示判定，做成显示广告 3 的时候在扣费呗？
还是整体流程
1 、三个进入扣费队列
2 、因为 1,2 立即显示所以完成扣费，队列踢出
3 、3 号因为显示原因导致以上问题

[dreamramon]

@zsj1029 #1 因为当 app 打开这个 view 的时候，就可以先把这 3 个广告下载下来。要不当滚动到广告 3 的时候，再去请求和显示，速度有点慢。。

[zsj1029]

理解，
下载广告的时候只做日志记录，只有触发显示的时候调用扣费 api 吧，这样感觉简单些。
不用队列，或者你这里的扣费队列还有什么其他用处

[dreamramon]

嗯，因为同一个位置，可能有 100 个广告主（不同的图片）来竞价。
如果不提前下载，很多时候下不完。。。