2012-07-29 63 views
2

假设我每秒钟都会有大约150个请求到达api(node.js),然后这些请求将记录在Redis中。按照这个速度,中等价位的RedisToGo例如将填补每隔一小时左右。如何处理大量日志和Redis的吗?

日志仅用于生成每日\每月\年度统计数据:这是最高请求的关键字,这是最高请求的网址,每天请求的总数量等。没有超重计算,但有点时间 - 通过数组遍历数组来查看每个数组中最频繁的元素。

如果我分析,然后转储这个数据,也就是说,每30分钟,它看起来像这样一个大问题(在节点中的setInterval函数也许?)不会。但是如果突然间我必须处理每秒2500个请求呢?

突然之间,我正在处理每小时4.5Gb的数据。每30分钟约2.25Gb。即使redis \ node速度有多快,计算最频繁的请求仍需要一分钟。

问题:虽然值得达达2.25 GB正在处理 会发生什么Redis的实例? (从列表中,我想象)

有没有更好的方式来处理潜在的大量日志数据比移动它的Redis,然后定期冲洗出来?

回答

6

IMO,你不应该使用Redis的作为缓冲来存储你的日志行,之后在批量处理它们。为此,消耗内存并没有意义。通过在一台服务器上收集日志并将它们写入文件系统,可以更好地服务您。

现在你可以用Redis的尝试来计算实时统计信息做什么。这就是Redis真正闪耀的地方。不要将原始数据保存在Redis中(稍后将批处理),您可以直接存储和汇总需要计算的统计数据。

例如,对于每个日志行,你可以管道下面的命令来的Redis:

zincrby day:top:keyword 1 my_keyword 
zincrby day:top:url 1 my_url 
incr day:nb_req 

这将计算出最佳的关键字,最常用网址和当天的请求数。在一天结束的时候:

# Save data and reset counters (atomically) 
multi 
rename day:top:keyword tmp:top:keyword 
rename day:top:url tmp:top:url 
rename day:nb_req tmp:nb_req 
exec 

# Keep only the 100 top keyword and url of the day 
zremrangebyrank tmp:top:keyword 0 -101 
zremrangebyrank tmp:top:url 0 -101 

# Aggregate monthly statistics for keyword 
multi  
rename month:top:keyword tmp 
zunionstore month:top:keyword 2 tmp tmp:top:keyword 
del tmp tmp:top:keyword 
exec 

# Aggregate monthly statistics for url 
multi  
rename month:top:url tmp 
zunionstore month:top:url 2 tmp tmp:top:url 
del tmp tmp:top:url 
exec 

# Aggregate number of requests of the month 
get tmp:nb_req 
incr month:nb_req <result of the previous command> 
del tmp:nb_req 

在月底,这个过程是完全相似(使用zunionstore或获得/月度数据增量来汇总年度数据)。

这种方法的主要好处是,而每月和每年的聚集可以很容易地计算出每个日志行来完成操作的数量是有限的。

+0

太棒了。您如何建议定期从zlist中删除只增加1的值?我担心的是,有很高的数量,可能有85%的查询是独特的,因此会添加到zlist中,这就是我想按照我的方式处理它们的原因。 – 2012-07-30 23:51:53

+0

zremrangebyrank定期? – 2012-07-31 00:17:18

+0

此外,似乎那一天:顶部:关键字例如将被覆盖每一个新的一天 - 说我需要复制数据以显示在其他地方的仪表板上 - 我只是在数据的最后运行这些命令之前复制数据这一天,并在月份\年做同样的事情? – 2012-07-31 00:47:05