Heim >Backend-Entwicklung >PHP-Tutorial >redis实现点击量浏览量

redis实现点击量浏览量

WBOY
WBOYOriginal
2016-06-23 13:46:201632Durchsuche

业务描述 
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值再做日期的区分以防覆盖
在你的分析下,确实方案二更可行
Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn