与PHP和jQuery进行实时聊天。在哪里存储信息？ mysql还是文件？

| 有1对1实时聊天。两种解决方案： 1）我将每条消息存储到数据库中，并在jQuery的帮助下每秒检查数据库中是否有新消息。当然我也使用缓存。如果有的话，我们给出该信息。 2）我将每条消息存储在一个html文件中，并通过jQuery将消息每秒钟重复显示一次。什么是更好的？还是有第三种选择？通常，对于这种项目，mysql或文件有什么更好的选择？非常感谢你。附言最重要的问题是：哪种方法更有效，哪种方法将消耗更少的资源！编辑：现在，对于许多聊天（例如2,500个聊天，意味着5,000个用户）来说，使用长时间轮询并检查何时每隔几秒钟通过javascript编辑文件是一件很不好的事情吗？我使用这种聊天方式非常相似：http://css-tricks.com/jquery-php-chat/会杀死我的主机吗？

已邀请:

13 个回复

桑娠贯涤

每个人都给出了广泛的意见，但我认为没有人真的会碰到钉子。当涉及到存储数据时，数据量，要访问的速率以及其他几个因素都决定了什么是最佳的存储平台。有人建议使用memcached。现在，尽管这是一个有效的答案（您可以使用它），但我并不认为这是一个好主意，仅基于memcached将数据存储在服务器内存中这一事实。您的内存不用于数据存储，而是用于实际的应用程序，操作系统，共享库等。在内存中存储数据会导致当前正在运行的其他应用程序出现很多问题。如果您在RAM中存储太多数据，则应用程序将无法完成分配给它们的操作。尽管这比基于磁盘的存储平台（如MySQL）要快，但它的可靠性却不如它。我个人将MySQL用作您的存储引擎服务器端。这样可以减少您遇到的问题，并使数据易于管理。为了加快对客户的响应，我将查看服务器上的运行节点。这是因为它是事件驱动的和非阻塞的。这意味着什么？好吧，当客户端A请求一些存储在硬盘驱动器上的数据时，传统上PHP可能会对C ++说，请把存储在硬盘驱动器此扇区上的这部分数据取给我。 C ++会说“没问题”，并且在获取信息的过程中，PHP将坐下来等待数据被读取并返回，然后再继续操作，从而阻止了所有其他客户端的访问。与此同时。与节点相比，它略有不同。 Node会对内核说：“获取我这部分信息，完成后，给我打电话”，然后它继续接收来自其他可能不需要磁盘访问的客户端的请求。突然之间，因为我们已经为内核分配了回调，所以不必等待:)，快乐的日子。看一下这张图片：这确实可能是您寻找的答案，请参见以下内容，以获取有关如何使节点成为您的正确选择的更具描述性和详细的信息： http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/

久坡

第四种选择，如果您已经拥有要使用的PHP代码，可能不是您想要的，但是最有效的方法是使用基于Javascript的服务器而不是php。 Node.js很容易成为聊天服务器，并且可以将所有最新消息存储为Javascript变量。您可以使用长时间轮询或其他彗星技术，这样您就不必等待一秒钟的时间来更新消息。同样，基于事件的Javascript服务器体系结构意味着没有闲置等待消息的开销。

骇毖煽洁铂

这取决于同时聊天的数量。如果是为了获得支持，并且您希望一次的平均负载为1至5个聊天会话，那么您不必担心太多。只需确保在一段时间没有任何活动时停止刷新，并显示一条消息让用户单击以恢复聊天会话。如果访问者彼此聊天，并且您希望进行大量的会话-同时进行10到50次会话，您仍然可以使用PHP +数据库。只要确保您没有进行多余的查询并且您的查询已正确缓存即可。为了减少负载，您还可以拒绝聊天脚本登录到Web服务器中：

SetEnvIf Request_URI \"^/chat.php$\" dontlog
CustomLog /var/log/apache2/access.log combined env=!dontlog

编辑：您可以拥有延迟架构。例如，如果您以1秒的延迟查询2次，但没有任何数据，则可以将延迟增加到2秒。如果您遇到10个没有响应的查询-将延迟增加到5秒。 10分钟后，您可以暂停对话，要求用户单击按钮以恢复聊天。这样，再结合上面的建议，将确保足够低的负载以进行许多并发聊天编辑2：我建议您找到一些Flash或Java解决方案并购买。对于拥有5000-10000个用户的用户，必须要有天才才能使其在VPS上工作，尤其是在RAM不多的情况下。并非不可能，但是您可以租用更便宜的VPS，并用其余的钱购买Java或Flash的一些解决方案（不知道flush是否支持2路连接，我不是Flash专家）。请注意有关用户数量的信息：如果您有1万个用户，我想您一次最多只能进行100个聊天。去看看约会网站-他们的在线用户不超过10％，也许大多数人在做其他事情而不是聊天

公藕

第三选择。使用MEMCACHE。无限快的读/写。非常适合您的应用程序。

陷牡彭拈峰

将聊天消息存储在数据库中，但将Memcached用作数据库读取的缓存层。因此，最受欢迎的阅读内容（例如，聊天室中的最后20条消息）将始终在内存中直接显示。这使您受益于最频繁操作的速度和所有消息的持久存储。

雇砰

只是要提出另一种选择...平面文件可以提供一种较少资源占用的选择。每个聊天都被分配一个唯一的ID和一个平面文件。每次聊天都会在该文件中添加一行。然后，每台客户端计算机都使用jquery仅检查文件的修改日期，以查看聊天是否已更新。虽然我通常不会在数据库上推荐平面文件，但我有一种偷偷摸摸的感觉，即检查平面文件上的修改日期会比MySQL替代方案更好地扩展。我很感兴趣，所以做了一些测试，结果如下：使用现有的数据库连接，可以在1秒钟内运行的\“ SELECT table FROM table LIMIT 0,1 \”的数量：〜4,000 打开和关闭数据库连接，但运行相同的查询：〜1,800 检查各种不同文件的修改日期：〜225,000 因此，要检查对话是否已更新，将对话存储在平面文件中并检查上次修改的日期将比使用数据库执行操作更快。

超可林

通常，在将数据推送到客户端时，http连接不是很有用。考虑到您的流量很大，每x秒进行一次轮询通常是任何服务器上的资源浪费。您应该将XMPP与BOSH结合使用。幸运的是，大多数繁重的工作已经为您完成。您可以非常快速地实现基于纯jquery（或其他js框架）的解决方案。阅读本教程，它将对您有很大帮助-不仅解决了您的特定问题，而且还使您更广泛地了解了如何在优质的http上实现推送技术。

蜗仓馈

除非是小型受众脚本-在数据库与文件系统之间，否则最好使用Database（。）附注：-Flash也是聊天服务器的绝佳平台，您可能也想研究一下。

孤捷侩

如果将对话定义为只有两个人，那么每秒的请求将看起来像是每个用户每秒一个读取请求，而每当有人写东西时（例如每10秒）就会发出一个写请求。因此，每10秒钟，您每次会话每秒大约有2.2个请求。对于50个会话，每秒有100个用户和220个请求。对于如此少量的对话，这在服务器上的负载很大。将对话编写为JSON或XML，可能会提供更具扩展性的解决方案。本文讨论了Meebo的体系结构-长轮询彗星。事后，您是否考虑过像Jabber这样安装IM服务器，而不是从头开始？

磨标烫徽啪

您总是可以找到适合该工作的正确工具...兼容XMPP的软件。因为文档很差，所以ejabber还可以。因为它严格遵循XMPP标准：http://code.google.com/p/ijab/，所以您可以使用任何XMPP客户端。如果愿意，可以将其全部存储在RDBMS中，并提供gmail / google talk中提供的类似功能。 $ 0.02