Closed Lixuhuilll closed 1 year ago
缓解 #121 理论上首页将不再需要加载50个size数百的数组,可以节约大量内存
坐等鸽子佬
你们认为需不需要在redis中缓存一周内点赞数,然后每一次点赞重新计算热度?我在重做代码的时候发现,之前的代码不止凌晨3点会统一刷新热度,实际上每次点赞都是会重新计算热度的。
目前作业的评分,会在凌晨3点热度计算后全部迁移,理论上第一天凌晨3点过去后,所有的作业相关迁移代码可以完全删除,不留痕迹。 但是评论的话暂时还没有类似的定时任务,是否需要添加一个。
目前作业的评分,会在凌晨3点热度计算后全部迁移,理论上第一天凌晨3点过去后,所有的作业相关迁移代码可以完全删除,不留痕迹。 但是评论的话暂时还没有类似的定时任务,是否需要添加一个。
评论不添加也不会有太大的影响,评论的点赞数又不会影响什么热度之类的关键计算,所以就算一开始就不迁移,也只是会丢失所有评论的点赞数量。不过要加一个也不是很复杂,就是我肝了一天有点懒orz
改动的地方比较多,看的我头疼也没看出有没有问题。辛苦了。评论区点踩的功能我感觉以前就有点问题,没有特别的用处(只能用来取消点赞)。可能之后也需要重新设计,我提个issue先。
辛苦了
目前作业的评分,会在凌晨3点热度计算后全部迁移,理论上第一天凌晨3点过去后,所有的作业相关迁移代码可以完全删除,不留痕迹。 但是评论的话暂时还没有类似的定时任务,是否需要添加一个。
目前我移除了每次点赞都计算热度的代码,那样太浪费了,但是一天只更新一次有点频率过低,我有一个改造的想法:能不能利用Redis的ZSET集合,member为作业id,每次发生点赞时,指定作业id的分数加1,点踩则减1,并移除分数排行前50名之后的作业id,使用定时任务每过一段时间获取前50的作业id,重新计算它们的热度。
完全重构评分系统,并配置迁移代码。新的评分系统将评分独立成Document,将用户id,评分类型,被评分对象id三者作为复合索引。