这不是趣头条么,不但分享给金币,阅读也给金币,每天固定把广告收入一部分发给用户,所以金币兑换人民币每天汇率不同,在三四线城市趣头条大刀阔虎砍下了 1000 万日活,估值 30 亿美元. 今日头条也跟进做了极速版,还有惠头条等等一帮同类模式的产品

太多了,打卡就有小打卡,鲸打卡,而且都拿到投资的,投票类那更是泛滥,还有给群成员配对的,看群成员地理位置的,五花八门

不是大病,就不用住院啊. 就算不住院,身边还是得有几个好朋友才行

这是很常规的技术,运行前检查一下进程名,已经存在就用那个进程执行,当前实例退出

家长没本事,才会要求孩子的成绩,因为成绩好能省钱. 但不要求成绩,不代表不需要严厉

阿里云 OSS 了解一下

只看流水,越多越好

小程序革的是 H5 的命,不是针对 app 的,但 web 替代 app 这是历史的必然,PC 时代已经发生过了,移动时代苹果也挡不住历史

@luger1990 所以不建议你用推模式啊,不用 nosql,直接关系数据库储存用户最近一周的观看记录来去重即可。就算用推的，也不需要给每个用户储存 100W 的队列，因为实际场景中，用户一辈子都不可能看到 100W 个视频. 如果内容与时间无关,也没有新内容进来,每天固定 500 个给所有人建队列就行了,第二天把前一天的数据删除了再来 500 个,真有人看完就单独给他拉内容。把问题缩小到一个封闭空间内，一下就非常简单了

@murmur 首先用户不可能一天看一万个内容, 大多数内容的生产和消费都和时间相关,假设平均每个用户每天看 50 条(已经很多了),先给用户推荐最近一天生产的内容,如果看完了,再推荐一周内的内容,最多只储存用户最近一周的观看记录用于去重. 1KW 用户就算全部都是铁杆活跃用户,数据总量也就 30 亿级别,且可以按用户 ID 分区,内容按时间分区

拉模式

建个表储存用户已看内容的 ID,推荐的时候用 left join 去重,内容一定有时间属性,只给用户推最近一段时间的内容,也只储存最近一段时间的已看记录,计算量和储存空间都会大大减少

不会都很好,最多都能听说,写作阅读还是只习惯一种语言,另一门语言阅读能力很差