architecture - 触发日常任务的服务消费者 - 架构

Question

我正在构建一个能够审查应用产品的应用程序。评论流量很高，我们决定为评论任务提供单独的服务。就像计算每个产品的平均评分一样。

我们需要在每天结束时计算评论，而不是在添加每条评论后计算，以减少数据库更新量。我们决定为该任务使用消息代理解决方案，以避免在数据库中进行搜索。

满足我们需求的最佳消息代理选项是什么？此外，这是最好的解决方案还是已经有满足此类需求的最佳实践？

标签： architecturemicroservices

Answer 1

如果您想自己管理它，我会使用RabbitMQ进行消息传递。否则，如果您想保持简单，云托管选项（如SQS）非常适合此类用例。

如果我正确理解您的用例，您希望在一天中累积消息队列中的评论，并且在一天结束时您希望运行一项使用消息并更新数据库中的结果的作业。

如果有大量消息，RabbitMQ 服务器的内存/磁盘可能会被填满，或者在一天结束时进行计算的工作可能需要太长时间。

您可能会考虑的另一个选择是将评论存储在数据库中，使用针对范围查询优化的索引，就像在 MySQL中一样，以便非常快速地获取 1 天的数据，然后基于那。

此外，您可以考虑一种更精细的方法，您的服务计算评论的频率高于一天一次（可能是几个小时一次）。这将减少数据库操作的数量，但也会分散该作业的负载。