背景

​ 在第三方 DSP 上投放广告，需要根据 DP Link 的点击次数进行控制。比如当 DP Link 达到 5000 后，后续的点击将不能带来收益，但是后续的广告却要付出成本。因此需要建立一个 DP Link 池，当 DP Link 到达限制后，我们可以调用 DSP 的 Marketing API 替换 DP Link。

技术框架

1. 投放上报 接收上报的曝光、点击等行为

2. 通过内部的 redis 队列，处理上报数据，然后新增一个 Kafka 队列，统计 DP Link 的点击数（使用 Redis 统计）

3. 当点击数达到限制，判断当前 DP Link 是否替换过，如果没有替换过，向 DP Link 替换任务队列发送消息

   1. 之所以异步处理 DP Link 替换，是因为需要调用第三方 DSP 的 Marketing API，性能无法保证。而 Kafka Click Count 的队列消息的 QPS 非常高，非常容易积压。

   2. 每个 DP Linke 的最大限制数，需要从投放系统配置和获取。通过本地缓存提升性能

4. DP Link 替换 的消费者：确保 DP Link 替换成功，需要手动执行 ACK

   1. 注意：将 DP Link 替换 设计成幂等性，防止有重复任务，确保不受影响。上游非常有可能重复提交相同的任务

WX20250527-181130@2x

实现上述框架，一个基础的版点击控制已经实现。在现实中跑的过程中发现一个问题：极个别的 DP Link 出现严重的点击超量。比如现实控制 5000 点击，但是实际点击却出现在 10000 左右。替换 DP Link 后，还有大量的点击上报。也就是点击上的滞后性。

为了解决点击上报的滞后性，我们设计了一个等待队列。比如一个 DP Link 总点击限制在 5000，那么在点击数到达 500 时，就进行 DP Link 替换，将替换下来的 DP Link 放到等待队列中。这一段时间等待延迟的点击上报。如果后续达到了 5000，改 DP Link 直接放入完成队列，如果没有完成，继续下放该 DP Link。

等待队列

如下图：统计完毕后点击数后，有两个触发条件：

1. 到达最大点击数

2. 到达本轮的最大点击次数

   1. 在 DP Link 刚被替换上时，使用当前点击数 + 500，便是本轮最大的点击数

等待队列的设计：

1. 等待队列是无重复数据的

2. 等待队列是有界的，比如最多 20 条数据

3. 当队列满时，循环使用队列中的数据。队列中的数据等待时间，队列中所有数据的使用时间

4. 当队列满时，从队列中获取一条 DP Link（新），被替换下的 DP Link（旧） 如果没有达到最大限制，会将旧 DP Link 还给等待队列。

5. 当队列不满时，需要从 未开始的 DP Link 池中获取新的 DP Link，将替换下来的旧 DP Link 放入等待队列，等待队列放满。

WX20250529-104010@2x

等待队列 未满时，新的 DP Link从 未开始队列中获取，替换下来的旧 DP Link，如果不满足最大点击数，放回 等待队列

WX20250603-194341@2x

等待队列 已满时，新的 DP Link从 等待队列 中获取，替换下来的旧 DP Link，如果不满足最大点击数，放回 等待队列

WX20250603-194735@2x

替换下来的旧 DP Link，如果满足最大点击数，放回 完成队列

WX20250603-194927@2x

当 未开始队列 队列空了之后，开始逐渐消耗 等待队列 中的 DP Link，直到消耗完毕。

WX20250603-195052@2x

下图是根据点击数替换 DP Link 的业务流程图：

WX20250603-101500@2x