我正在启动一个项目，我认为该项目特别适合 MongoDB，因为它提供的速度和可扩展性。
我目前感兴趣的模块是与实时聊天有关的。如果我要在传统的 RDBMS 中执行此操作，我会将其分为：
- 频道（一个频道有很多用户）
- 用户（一个用户有一个频道但有多条消息）
- 消息（一条消息有一个用户）
出于此用例的目的，我假设通常有 5 个通道同时处于活动状态，每个通道每秒最多处理 5 条消息。
需要快速的特定查询：
- 获取新消息（基于书签、时间戳，或者递增计数器？）
- 将消息发布到频道
- 验证用户是否可以在频道中发帖
请记住，MongoDB 的文档限制为 4mb，您将如何设计架构？你的会是什么样子？有什么我应该注意的问题吗？
I used Redis http://code.google.com/p/redis/、NGINX 和 PHP-FPM 用于我的聊天项目。不是超级优雅，但它确实有效。这个谜题有几个部分。
有一个非常简单的 PHP 脚本，它接收客户端命令并将它们放入一个庞大的列表中。它还检查所有房间列表和用户私有列表，以查看是否有必须传递的消息。这是由用 jQuery 编写的客户端进行轮询的，每隔几秒就会完成一次。
有一个命令行 PHP 脚本以每秒 20 次的无限循环操作服务器端，检查此列表，然后处理这些命令。脚本在脚本内存中处理谁在哪个房间以及权限，此信息不存储在 Redis 中。
Redis 为每个房间都有一个 LIST，为每个用户提供一个 LIST，作为私有队列运行。它还为用户所在的每个房间提供多个计数器。如果用户计数器小于房间中的消息总数，则它会获取差值并将其发送给用户。
我无法对这个解决方案进行压力测试，但至少从我的基本基准测试来看，它可能每秒可以处理数千条消息。还有机会将其移植到 Node.js 之类的东西以提高性能。 Redis 也正在成熟，并且具有一些有趣的功能，例如发布/订阅命令，这些功能可能会令人感兴趣，这可能会消除服务器端的轮询。
我研究了基于 Comet 的解决方案，但其中许多都很复杂，文档记录很差，或者需要我学习一种全新的语言（例如 Jetty->Java、APE->C）等...此外，交付和通过代理有时也可以是彗星的一个问题。这就是我坚持民意调查的原因。
我想你可以用 MongoDB 做类似的事情。每个房间一个集合，每个用户一个集合，然后是一个维护计数器的集合。您仍然需要编写后端守护程序或脚本来处理这些消息的去向。您还可以使用 MongoDB 的“有限集合”，它可以保持文档排序并自动清除旧消息，但这在维护适当的计数器方面可能会很复杂。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
