可扩展的几乎实时 RESTful 成就 Web 服务，如何减少调用次数？

Question

我正在构建实时成就网络服务。

我目前的想法是在 MongoDB 中拥有一个成就集合以及一个玩家集合。我会将成就列表存储在成就集合中（可以修改该列表以添加新成就并用作成就定义），它将包含统计数据和阈值列表（完成成就的目标），而玩家集合将包含由 playerID 以及每个成就的字典作为键和许多统计信息（进度）作为值以及信息（完成与否）组成的对象。

当客户发布新的统计数据时，我会获取成就列表，并通过获取成就集合找到那些在其进程中使用这些统计数据的人。然后，我需要获取玩家收藏以查找哪些成就已经完成，并将这些成就从我当前要处理的成就列表中删除。然后我会再次获取玩家集合以获取其他统计数据并计算新进度。我需要更新玩家收藏的成就进度。如果成就完成，我会向客户端发送回调，以便它可以“实时”看到它。

我的问题是我需要该服务在高压下工作（数十万玩家发送大量新统计数据（例如击杀数，可能是数千个成就的数千个统计数据）），而我目前的想法似乎可以对数据库的调用太多了。

我想改用 MySQL 数据库，但我对它们不是很好，所以我不确定这样是否会更好（视图可以加快速度吗？）。 Redis 对于大型数据库来说似乎成本太高。

我应该使用更好的流程/设计模式吗？

有没有办法制作架构，以便在重负载时仍然很快？

我应该改用 MySQL 吗？如果是，那么可以帮助我加快速度的关键因素是什么？ （所以我可以阅读它并设计更好的东西）

Answer 1

我从未使用过 NoSQL，但经常使用 SQL。所以我的想法可能有偏见或过于以 SQL 为中心。

话虽如此，这是我的想法。总的来说，我认为每个新的统计数据都需要两次 db 调用。

当客户发布新的统计数据时，我会获取成就列表，并通过获取成就集合找到在其进程中使用这些统计数据的人。

如果成就集合足够小，您可以在初始化服务时缓存到内存中。 如果没有，我认为您应该采用“MySQL”方法，而不是单独执行此步骤，而是加入下一步。总之，我们可以减少一趟 DB

然后我需要获取玩家收藏以查找已经完成的成就

这可能是第一次去 DB

从我当前要处理的成就列表中删除那些

我相信这与数据库无关，而是您程序中的逻辑。但如果我错了，请纠正我。

然后我会再次获取玩家集合以获取其他统计数据并计算新进度。

我认为您可以从第一次 DB 之旅中获得这些信息，并将其保存在内存中的某个位置。所以不需要进一步的数据库之旅

我需要更新玩家收藏的成就进度。

这将是您第二次更新数据库。

如果一个成就完成了，我会向客户端发送一个回调，这样它就可以“实时”看到它。

而这与 DB 无关

如果这仍然是太多的 DB 调用并且您只想进行一次旅行，我唯一的想法是切换 MySQL 并创建一个处理逻辑的过程。

通过这种方式，您将只与每个统计数据建立一个数据库联系，这是不可避免的，并将您的所有负载推送到数据库层，以便在那里扩展。