@xuanbg 换成一分钟之后，那这不就是一楼说的那种做法吗？

@luzhh 是的，今天想到了这个，直接解析 nginx 的 log 也是个办法

@xuanbg 那这样子就没有了时间滑动窗口了，我也不会问这个问题了

@keakon 就算用一楼的办法，每分钟也只是同一个普通的 key 。而且也会删掉，”不用看也知道内存扛不住“ 是不是太武断了些....我觉得抗住是没有问题的...

@angryfish 日活目前在 1w 多有，预计会增长至 10w

@vebuqi 看懂了大部分，但疑问是下一个 10 分钟的时间窗口，是另起新的 key 统计吗？还是将旧的清零？比如 10:59 分 过渡到 11:00 的时候，此时 bitmap 上 0 这个 field 还是存储着 10:50 的统计？还是怎么样

@opengps 嗯嗯，这种可以考虑一下

@ch2 这种方案的话，还不如先写到 redis 一分钟同步一次数据到 mysql，基本没有写压力，方案上更趋近于这个

@seth19960929 我知道这个

@ch2 目前没有配置 mongo，mongo 存一亿条磁盘占用要去到多少呢？不用 redis 纯用 mongo 来承载读写的话，mongo 大概能抗住多大的 qps ？有没有稍微具体一点的数据可以支撑一下？

@liujuzzz 这是插眼的意思吗？

@opengps 每分钟转存到归档，归档指的是 mysql 之类的数据落地的东西？
另外每分钟转存是后台起一个脚本来做这个吗？
hash 归档缓存 就相当于只统计了 T-1 分钟的 访问数，这个倒可以接受

@carity 有数据库，但是每次视频被访问就直接写数据库+1 吗？那到时候数据库写压力就很大了

@Jooooooooo 这就是我提到的第 2 种做法了~
但问题是，我想做一个管理后台，在视频列表上，显示每个视频的访问增速，如果我一页拿 20 个视频，每个视频捞 10 个 key，20 个视频就要捞 200 个 key，虽然说用 mget 读取也只要读 20 次....但我视频越多，key 就越多了

@yiqiao 枯了，有什么转机吗

@yaphets666 技术确实一般，这样的话感觉自己凉了

@yaphets666 sad，走社招也没戏吗？

@b1ackjack 这些我都有，只是社招不清楚里面的情况，所以想了解下

@yaphets666 哭了