MongoDB模式设计-实时聊天

Question

我正在启动一个项目，由于它所提供的速度和可伸缩性，我认为它将特别适合MongoDB。

我目前感兴趣的模块是实时聊天。如果我要在传统的RDBMS中这样做，我会将它分成以下几个部分：

• 频道(一个频道有很多用户)
• 用户(用户有一个通道，但有多条消息)
• 消息(消息有用户)

根据这个用例的目的，我想假设通常一次会有5个通道处于活动状态，每个通道最多每秒处理5个消息。

需要快速查询的特定查询：

• 获取新消息(基于书签、时间戳或递增计数器？)
• 将消息发送到频道
• 验证用户是否可以在信道中投递

考虑到MongoDB的文档限制为4mb，您将如何设计模式？你的长什么样？有什么需要我注意的地方吗？

Answer 1

我在聊天项目中使用了Redis，NGINX &PHP。不是超级优雅，但它能起作用。这个谜题有几块。

1. 有一个非常简单的PHP脚本，它接收客户端命令并将它们放在一个庞大的列表中。它还检查所有房间列表和用户私有列表，以确定是否有它必须传递的消息。这是由一个用jQuery编写的客户机进行的，它每隔几秒钟就完成一次。
2. 有一个命令行PHP脚本在无限循环中操作服务器端，每秒20次，它检查这个列表，然后处理这些命令。脚本处理谁在哪个房间和在脚本内存中的权限，这个信息没有存储在Redis中。
3. Redis为每个房间提供了一个列表&为每个用户提供了一个用作私有队列的列表。它还为用户所在的每个房间设置了多个计数器。如果用户计数器小于房间中的总消息，则会得到差异并将其发送给用户。

我一直无法对这个解决方案进行压力测试，但至少从我的基本基准测试来看，它可能每秒可以处理数千条消息。也有机会将其移植到像Node.js这样的地方，以提高性能。Redis也正在成熟，并且有一些有趣的特性，比如Pub/ side命令，这可能会让您感兴趣，这可能会删除服务器端的轮询。

我研究了基于Comet的解决方案，但其中很多都是复杂的，文档编写得很糟糕，或者需要我学习一种全新的语言(例如Jetty->Java，APE->C)等等。此外，交付和通过代理有时可能是彗星的一个问题。这就是为什么我一直坚持投票。

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

Answer 2

为什么使用mongo作为消息传递系统？无论静态存储有多快(而且mongo非常快)，无论是mongo还是db，要模拟消息队列，您都必须使用某种轮询，而这种轮询并不是非常可伸缩或高效的。当然，你并没有做什么非常强烈的事情，但是为什么不使用正确的工具来做正确的工作呢？使用像兔子或ActiveMQ这样的消息传递系统。

如果你必须使用芒果(也许你只是想玩它，这个项目是一个很好的机会这样做？)我设想您将为用户提供一个集合(每个用户对象都有一个用户侦听队列的列表)。对于消息，您可以为每个队列拥有一个集合，但是接下来您必须轮询您感兴趣的每个队列以获取消息。最好是将单个集合作为队列，因为在单个集合上的查询在mongo中很容易“执行”，因此在列表a、b、c中的任何队列中获取比X更新的所有消息都很容易。

您还可以考虑将您的集合设置为mongo上限集合，这意味着您在设置集合时告诉mongo，您的集合应该只包含X个字节或X个项数。添加附加项具有先入先出的行为，这对于消息队列来说是非常理想的。但同样，这并不是一个真正的消息传递系统。

Answer 3

1) ap-project.org

2) http://code.google.com/p/redis/

3)在完成所有这些工作之后，您可以将数据屏蔽到mongodb中，以便进行日志记录，并存储一致的数据(用户、通道)。