业务描述
CMS文章浏览量(标题被加载量),点击量统计(文章被点击开的量)
以下是本人设计的统计业务,主要技术redis,nodejs,redis应用点击量缓存以减少数据库压力,nodejs通过异步非阻塞机制实现CMS业务逻辑和统计功能区分
传入参数cateid(分类id),articleid(文章id),sourceip(请求源ip)
一、存储策略
1、按时间粒度记录
redis以hash进行存储
HASH
KEY VALUE
time his
0 0
1 10
cateid_arvicleid_t . .
. .
. .
23 230
2、按来源统计
redis同样以hash进行存储,来源区分到省份
HASH
KEY VALUE
provinc his
HEBEI 0
HENAN 10
cateid_arvicleid_p . .
. .
. .
SHANDONG 230
二、数据同步机制
现在只想到通过linux计划任务定时将redis数据同步到数据库
三、缓存数据过期机制
方案一 通过redis自动过期时间
此方案需要在数据同步机制晚一些执行,保证数据入库后,清理过期缓存,现在考虑同步在每日0时执行,那么redis缓存就需要设置24小时多一点
方案二 通过数据库同步机制同时清除
此方案即把同步和清理缓存做在一起,弃用redis过期机制
小弟希望各位大神给指出不妥和优化的地方
在10000在线用户,1000并发的基础上上述redis的存储机制对内存压力是否可行
同步机制和缓存过期机制是否有更好的解决的方案
在此拜谢
回复讨论(解决方案)
KEY 最好设置成 2014_10_30. cateid_arvicleid_t形式
选择方案二 通过数据库同步机制同时清除 在每天凌晨的2~4点进行同步 因为脚本1.同步脚本可能失败 2.数据量大的时候昨天的0时数据会被今天的0时覆盖
号称1秒10W请求的redis 不惧1000的并发
KEY 最好设置成 2014_10_30. cateid_arvicleid_t形式
选择方案二 通过数据库同步机制同时清除 在每天凌晨的2~4点进行同步 因为脚本1.同步脚本可能失败 2.数据量大的时候昨天的0时数据会被今天的0时覆盖
号称1秒10W请求的redis 不惧1000的并发
非常感谢
确实由于同步机制和缓存过期的存在,要对key值再做日期的区分以防覆盖
在你的分析下,确实方案二更可行