10W中的3000条,概率是3%
那么只要在保存文章时,按照3%的概率,把本次更新文章保存到缓存中
这种缓存用redis的set类型最好,set类型不会保存重复的元素,所以文章反复更新也不会在列表里面产生多个结果
key的格式可以用"analyze:list:(Y-m-d)"
然后这个缓存可以设置为48小时过期,如果有需要的话,每天可以拿前一天的缓存归档到数据库
考虑到随机概率的误差,可以把3%放大到5%,最后肯定会记录得超过3000,但是也不会超太多,反正最后只拿3000条来用就行了
把每次更新都记录起来的话,无论是记录到缓存还是数据库,其实大部分的记录是没用的,不如按照概率先过滤一遍
其实记录每条文章的update_time也可以,我觉得where update_time >= ? and update_time <= ? order by random() limit 3000差不多就行了,反正每天才跑一次而已,不过既然是面试的话,怎么能不秀秀思路呢
优点:
1、没有update_time字段也能玩,对现有表结构无要求,给生产环境的数据库加字段是件麻烦事
2、万一生产环境的数据库负载比较高,order by random()查询导致数据库卡死也不好,这样的话,最好是读写分离架构,在只读库上查询才行,产生了架构要求,我这个设计完全是个旁路记录,除了redis之外没要求
3、需要多少才记多少,额外IO少