动态热门列表优化

[medz]

为了更高的性能，将重写热门列表数据，数据每小时更新一次。方案如下：
按照 按照 offset 的值进行列表数据的缓存。采用一主双备方案。

即主缓存时长为 1 小时。备份时长大于 1 小时上浮动 0.5 和 1 小时。即：主：1H, 备1: 1.5h, 备2: 2h

先检查主缓存是否到期，如果到期，检查是否有其他任务正在进行缓存生成任务，如果有任务，则跳过主缓存从双备中随机获取 1 个缓存。如果获取失败，从余下的获取一份缓存，如果全部获取失败，则返回空列表数据。

如果主缓存不存在，且没有缓存任务，生成缓存任务。然后从数据库查询数据进行缓存生成。生成后进行三个缓存块备份。

缺点：

1. 数据不再实时，而是在缓存时间内随机。
2. 第一个生成缓存任务的请求速度会慢下来

优点：

在缓存时间内，读取速度会很快！可以负载更高请求！

为什么只优化动态热门列表？

因为只有热门是最慢的～，而最新列表按照 id 进行索引查询，速度不会慢！

关注可优化，如果不需要实时，可采用本方案。

[westudiodev]

会不会有些复杂，是否可以试试用更简单的redis消息队列功能或rabbitmq消息队列来实现。可能更清晰简单。以后可扩展性也更强。

[medz]

@webpatser 如果采用消息列队确实可以，但是有两个需要解决：

1. 热加载数据表数据，目前这个一主双缓存方案是为了减少服务要求。如果采用列队，需要解决消息通知，任务通知，以及预热数据问题。
2. 其次增加了部署成本。缓存则没有部署成本。

解释下，这个方案是针对性的方案，可以有多用途，抽离成通用模块，运用在不需要实时的列表数据的地方

[medz]

@westudiodev 目前这个方案是预设在动态数据达到百万即以上的方案。列队使用如此海量的数据做，也会有很高的成本问题。而且列队需要加载不需要的冰点数据。做完方案会生成一百万的动态进行测试

[863324395]

能不能实现下拉刷新重新加载一组动态 . 这样不会把前面的动态内容都沉淀下去了

[medz]

@863324395 你看不到一小时这个词？😂

[medz]

New

因为之前的需求变动，放弃双缓存方案，进行动态应用重构以达到热门列表需求：

方案如下，在 feeds 表增加热门索引字段。然后「阅读」、「点赞」、「评论」进行热门索引的计算与更新。热门数据通过热门索引进行排序查找，翻页进行 where 条件定位，以达到高性能的数据加载！

[medz]

重构完成！