MongoDB Schema Design - 实时聊天

Question

我正在启动一个项目，我认为它特别适合 MongoDB，因为它提供的速度和可扩展性。

我目前感兴趣的模块是实时聊天。如果我要在传统的 RDBMS 中执行此操作，我会将其拆分为:

• channel (一个 channel 有很多用户)
• 用户(一个用户有一个 channel 但有很多消息)
• 消息(消息有用户)

为了这个用例的目的，我想假设一次通常有 5 个 channel 处于事件状态，每个 channel 每秒最多处理 5 条消息。

需要快速的特定查询:

• 获取新消息(可能基于书签、时间戳或递​​增计数器？)
• 向 channel 发布消息
• 验证用户是否可以在 channel 中发帖

考虑到 MongoDB 的文档限制为 4mb，您将如何设计架构？你的会是什么样子？有什么我应该注意的问题吗？

Answer 1

我使用了 Redis ，NGINX 和 PHP-FPM 用于我的聊天项目。不是 super 优雅，但它可以解决问题。这个难题有几个部分。

1. 有一个非常简单的 PHP 脚本，它接收客户端命令并将它们放在一个巨大的 LIST 中。它还检查所有房间列表和用户私有(private)列表，以查看是否有必须传递的消息。这是由一个用 jQuery 编写的客户端轮询的，每隔几秒钟就会完成一次。

2. 有一个命令行 PHP 脚本在无限循环中运行服务器端，每秒 20 次，它检查这个列表，然后处理这些命令。脚本在脚本内存中处理谁在什么房间和权限，此信息不存储在 Redis 中。

3. Redis 为每个房间都有一个 LIST，每个用户都有一个 LIST，作为私有(private)队列运行。对于用户所在的每个房间，它也有多个计数器。如果用户计数器小于房间中的消息总数，则它会获取差值并将其发送给用户。

我无法对这个解决方案进行压力测试，但至少从我的基本基准测试来看，它可能每秒可以处理数千条消息。还有机会将其移植到 Node.js 之类的东西上以提高性能。 Redis 也正在成熟，并且有一些有趣的功能，例如发布/订阅命令，这可能很有趣，可能会消除服务器端的轮询。

我研究了基于 Comet 的解决方案，但其中许多都很复杂，文档记录不完善，或者需要我学习一门全新的语言(例如 Jetty->Java、APE->C)等...还有交付和经历代理有时可能是 Comet 的一个问题。所以这就是我坚持投票的原因。

我想你可以用 MongoDB 做类似的事情。每个房间一个集合，每个用户一个集合，然后是一个维护计数器的集合。您仍然需要编写后端守护程序或脚本来处理这些消息的去向。您还可以使用 MongoDB 的“有限集合”，它可以保持文档排序并自动清除旧消息，但维护适当的计数器可能会很复杂。