Architecture 类似Reddit的热页后端体系结构

我正试图对reddit如何计算和服务热门页面进行后端设计。我还使用“热门”评级在我的网站上订购帖子。我有一些我正在努力克服的问题。以下是我认为设计有意义的一些方式：

计算热门值：目前，每当有人上传帖子或加载帖子时，我都在计算该值并将其与投票本身一起存储在数据库中。这可能不太好。我想简单地通过cron作业每5分钟更新一次所有帖子的热值，例如，仅更新2个月以上的帖子。这种设计应该适用于成千上万的帖子，有些我不确定这是否是最好的解决方案，但我确实了解到reddit至少在一开始使用了cron jobs

查询帖子：这是我现在最担心的部分。现在的问题是，如果我滚动（更多的帖子在页面底部加载），我可能会看到重复的帖子，因为帖子在热值中上升和下降。现在，每次加载新帖子时，都会执行一个db查询来检索帖子。我认为使用memcached和缓存帖子的查询会很有意义（这需要应用到很多页面），但我不确定这是否能完全解决我的问题。理想情况下，我会找到一个解决方案，它基本上是“快照”（缓存？）数据库，并从数据库中该版本的表加载，直到加载新页面

---

这是一个困扰我多年的问题，我试图找到一个合适的解决方案，在我向下滚动页面并加载新的帖子集时，如何最好、最有效地计算热门评级值，并按热门评级的顺序获取帖子，而不改变值（以避免重复和可能丢失帖子），同时保持流程的良好和高效。对此有什么想法吗？

你不必太担心重复的帖子。大多数网站（包括reddit）都有这个问题

我认为没有一个解决方案可以很好地扩展。大多数站点看重性能和可扩展性而不是一致性。这就是为什么nosql在这些方面越来越流行的原因。它们不能保证一致性（或只是最终的一致性），但作为回报，它们提供了更好的性能和水平可伸缩性

---

如果你真的想解决这个问题，我会看看客户端。从您的描述中，我了解到您将拥有一个“无限卷轴”类型的站点。您可以让客户“记住”已经显示的帖子。如果服务器向其发送更多的帖子（向下滚动时），客户端可以过滤掉上面已经显示的帖子，例如保留一个帖子id列表。

您不必太担心重复的帖子。大多数网站（包括reddit）都有这个问题

我认为没有一个解决方案可以很好地扩展。大多数站点看重性能和可扩展性而不是一致性。这就是为什么nosql在这些方面越来越流行的原因。它们不能保证一致性（或只是最终的一致性），但作为回报，它们提供了更好的性能和水平可伸缩性

如果你真的想解决这个问题，我会看看客户端。从您的描述中，我了解到您将拥有一个“无限卷轴”类型的站点。您可以让客户“记住”已经显示的帖子。如果服务器向其发送更多帖子（向下滚动时），客户端可以过滤掉上面已经显示的帖子，例如保留帖子id列表

现在的问题是，如果我滚动（更多的帖子在页面底部加载），我可能会看到重复的帖子，因为帖子在热值中上升和下降

这是reddit长期存在的问题。没有简单的解决方案，但是您可以使用客户端方法隐藏当前页面上已经存在的帖子

计算热门值：目前，每当有人上传帖子或加载帖子时，我都在计算该值并将其与投票本身一起存储在数据库中。这可能不太好

不考虑视图的数量，因此不需要在线程的每个视图上更新它们。但是，它们会在每次投票时更新排序值，无论是向上、向下还是取消投票。只要您在单独的队列中执行此操作，并且有足够的队列处理器，这是一种合理的可扩展方法

如果您确实希望在排序计算中包含页面视图，我可能会采用一种类似于处理度量的缓冲方法：在每次页面加载时，向某个服务发送ping，该服务可以非常快速地将这些值写入内存，并定期将这些值一起刷新到更永久的存储中。您可以直接通过编写它刷新到的处理程序来完成这项工作

现在的问题是，如果我滚动（更多的帖子在页面底部加载），我可能会看到重复的帖子，因为帖子在热值中上升和下降

这是reddit长期存在的问题。没有简单的解决方案，但是您可以使用客户端方法隐藏当前页面上已经存在的帖子

计算热门值：目前，每当有人上传帖子或加载帖子时，我都在计算该值并将其与投票本身一起存储在数据库中。这可能不太好

不考虑视图的数量，因此不需要在线程的每个视图上更新它们。但是，它们会在每次投票时更新排序值，无论是向上、向下还是取消投票。只要您在单独的队列中执行此操作，并且有足够的队列处理器，这是一种合理的可扩展方法

如果您确实希望在排序计算中包含页面视图，我可能会使用一种类似于处理度量的缓冲方法：在每次页面加载时，发送一个p