[关闭]
@chyoo1991 2015-10-14T08:38:10.000000Z 字数 1190 阅读 1132

日报百度流量异常再调查

调查


前次调查

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


添加计数器之后的结果


[针对百度关键词]


分析


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

-----qingkuang

处理之后的情况


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

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


本次调查

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

经研究发现:存储过程是

kafka->redis->django

经过仔细阅读代码,大略判断,并没有发现问题。如果要确定具体问题,还要细致写代码验证。此时又怀疑没有什么大问题,毕竟代码没看出来。于是将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之前。

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注