cpc卡内计费信息异常包括_CPD，CPM及CPC广告投放系统计费漫谈

互联网广告的售卖方式大体主流可以划分为CPD（按照天或时间售卖），CPM（按照千次曝光售卖），CPC（按照点击售卖）。所以对应这几种售卖方式的不同，广告投放系统也有些许不同。另外有一个前提，我们所提到的广告系统都是基于广告系统是分布式的集群来讨论的。

一、CPD广告计费

CPD广告投放系统，本质上就是一个时间排期系统或订单系统。需要排期的资源为：广告位和时间两个要素组成的元素的集合。比如{（2019-05-06，广告位1），（2019-05-07，广告位1）（2019-05-08，广告位1）}。在订单中选中了（2019-05-06，广告位1）这个元素，那这个元素就不能被其他订单所使用，具有独占性。当这一天真正到来的时候，将具体的广告素材以碎片的形式和内容一起分发到CDN，随着内容的浏览广告便完成了投放，其实完全并不需要一个真实的投放系统。计费以合同约定金额为准即可。或者投放系统自动读取合同系统（一般为CRM）金额，按照特定规则（这个规则各个公司甚至合同都不同，所以是特定规则）拆分到每一个具体执行日期就算作完成了一次CPD广告计费。或者由合同系统进行拆分也一样可行。PS：如果CPD加入了轮播就是广告位，时间和轮播数三元素组成的集合，与两个因素没有区别。

二、CPM广告计费

CPM广告投放系统与CPD广告投放系统有了很大的不同。CPM广告投放系统按照千次曝光量进行售卖，但与cpd不同的是多出了很多的定向条件，常见的比如时间、地域、操作系统、人群等等。CPD广告可以算作CPM广告只有时间定向的特例。从广告投放系统上而言两者有质的差异（具体可以看刘鹏大佬的《计算广告学》），但从计费上而言，都是签订合同保证完成量，然后按照合同金额进行拆分的计费方式。

三、CPC广告计费

1. cpc竞价机制

CPC广告投放系统简化而言就是CPM广告投放系统+点击率预估。CPC广告一般不像合约广告一样保证投放量，而是按照预估ecpm的高低进行竞价投放，价高者得。

2. 点击价格计算

每次点击计费多少是第一个问题：大多数的cpc系统都是采用GSP（广义第二价格）进行结算。第二价格的计算为：cpc = 第二高价ecpm/第一高价的ctr，此处的ctr（点击率）指预估ctr（点击率）。此处的理论依据不敢妄谈，有兴趣的话可以去搜索一下GSP相关的机制的文章。

3. 如何计费

3.1 超投

每次cpc的价格确定之后，在用户点击之后就会按照这个cpc价格进行计费。因为点击相对于投放有一般会有分钟级甚至小时级别的延迟，另外ctr预估不可能是100%准确，所以超投是不可避免的。超投不可避免那如果都计费就意味着超扣（超出广告主设置的预算收费）不可避免，但广告主不可能接受超扣。那就需要抹除多投放的部分。

3.2 投放逻辑

那么要如何处理呢？首先计费和投放不可分，投放和预算不可分。我们的计费的理论是基于以下的投放及计费逻辑进行讨论的。该结构是否是最优方案有机会可以后续讨论。

投放及计费逻辑

a.首先用户访问时，广告投放系统会收到一个用户访问请求。

b.投放系统投放模块会查询要给用户投放的广告是否有余额，如果有余额就将广告投放出去。没有这个广告就不再投放。

c.广告投放后点击回收到投放系统时，依然判断该广告的余额是否足够，如果足够则更新计费，如果不够就记录为浪费。

3.3计费方法

3.3.1集群化方案

一般情况下广告系统的并发量都很大，而面对高并发任务，业内主流的解决方案是集群化。在集群的情况下以上的投放逻辑会面对几个问题：当一个点击到达时，是否要记录这个点击进行计费是面临的第一个问题？集群有多种负载均衡模式，针对每一种负载方式分别讨论：

a 随机、权重：

请求随机发送到后端服务器。此时点击会随机分发到集群内的某台服务器，那么这台服务器接收到点击后需要查询预算是否充足。我们面临一个选择：因为分布式锁会影响系统的整体吞吐量，是否做分布式锁？

无锁：

如果不做分布式锁，这样做的好处很明显：分布式处理可用性比较高，对于高并发支持比较好。但缺点一样明显：在并发较高的情况下会产生脏读，那么就会对某个广告主超扣。此时可以将分布式计费的数据再进行一次汇总然后再进行串行化处理（比如写入MQ），然后单进程从MQ消费数据，将超投数据滤除。这同样会引入一个问题，广告主的预算可能会不定时进行调整。而在集群计费和滤除处理之间有一个时间差，那么如果在这个时间段内，广告主预算进行了调整，比如将预算调小了，那么这就是一个漏洞，广告主先调大预算再改小预算，那么就可能会导致在滤除操作时取到较小的预算从而多过滤，广告主占便宜。一般面对这个问题，可以考虑从业务上避免，比如客户的预算调整并非立即生效，只能在结算完成时生效或者第二天才能够生效。

有锁：

如果做分布式锁，那么系统的吞吐量降低，增加了系统的复杂度，但超扣问题一次解决。

b.基于规则的hash：

如果将客户或订单的信息放置在url中，按照url进行hash，可以将特定客户的数据发送到指定的服务器。在特定服务器只需要处理特定的客户的消耗。这样可以做到高并发又不会有分布式锁的问题。当点击量增大时很容易将而且很容易进行横向扩展。增加服务器，客户预算加载到新增服务器。通过负载分发流量到新服务器，新服务器计费。但同样这样的方案面对数据倾斜严重时会导致服务器压力不均匀。

3.3.2 简单方案（单机方案）

除了以上方案之外其实具体问题具体分析，点击计费系统，其点击数大多也不过百万级多的话也就是千万级。而计费仅有一个读和扣减操作，这完全不需要集群处理，单机也有充足的处理能力。完全可以在单机串行化。为了保证稳定性可以通过主备自动切换的方式进行。

以上便是对于不同投放系统计费模式的一点简单探讨，如果有哪里不合适的地方欢迎各位大佬批评指正。