日报百度流量异常再调查

调查

前次调查

对前次调查进行总结，分析前次调查和代码修正得到了怎么样的结果。

添加计数器之后的结果

[针对百度关键词]

• 9月24日 解码错误：1.3w 总共：469w 长度超范围被过滤掉的：243w 最终有效的：223w
• 9月24日 DC中PV情况 自然搜索来源 463w

分析

添加针对PV的计数器之后，总共有效的关键词数量与DC中的PV自然搜索来源数量基本符合。另外，可以看到大部分被过滤掉的原因在于关键词的长度超标，而长度超标由百度关键词加密引起。据此情况，我们取消掉了长度限制。

-----qingkuang

处理之后的情况

baidu_keyword_hit数据库里面总UV的变化情况

即在25号去掉长度限制后，UV量有所上升，但是与正常水平还有一部分距离。数据库中出现了加密的关键字，说明长度限制去掉后起了一定作用。

本次调查

初步怀疑是PV->UV的过程中出了意外情况，首先要对这个过程进行梳理。

经研究发现：存储过程是

kafka->redis->django

• 调查redis中是否存得正常数量的数据
• 入库时是否正常

经过仔细阅读代码，大略判断，并没有发现问题。如果要确定具体问题，还要细致写代码验证。此时又怀疑没有什么大问题，毕竟代码没看出来。于是将DC中的UV与数据库中的UV进行比较[相减]，得到下面的图：

很明显，这个是存在问题的。9月10号之后，数据库里面的UV明显减少。导致DC里面的UV减去数据库里面的UV得到正值。数据库里面的UV计算方法是:keyword:date:url->uids（列表），也就是说如果一个用户在同一天里用不同的关键字搜索到了同一个url，会导致其uid被存储两遍。初始预计DC中的判断方式是 date:url->uids，这样就去掉了不同关键字的情形（合成了一个）[还有可能就是只统计date不重复的uid的个数，这样也是比数据库中要少]。于是从理论上讲，数据库中的值应该比DC中的多。但是上图在10号之后就不对，数据库里面的UV明显减少了。

查Redis中的情况

Redis中存储12号的数据：scard keywords:2015-10-12 结果为：1484471 也就是说关键字是148w
设计脚本统计12号redis里面存的数据的UV是多少，跟数据库里面的区别是什么，来查看是否是入库问题。

数据库中UV的总值：2544271
DC中UV的总值：3091506
差值近50w，而且应该是数据库UV比DC的多。

redis中的数据：2544363（存入Django模型时会因为少数编码问题无法存入）

经过用脚本统计redis中的数据，发现存入redis中的数据为254w多[要跑一个多小时]，和数据库中的UV对的上。因此判定问题出在存入Redis时或者是存入Redis之前。