3

我目前正在构建一个类似 facebook 的聊天框，并且在此过程中遇到了一些注意事项和问题。

我一直在谷歌上搜索有用的资源，比如简单的聊天框示例或在线教程。

我的目标是像 facebook/gmail 聊天框和CometChat一样构建一个，我知道在幕后进行扩展很难而且太多，但我想做的就是尽可能简单地构建它，并弄清楚 facebook/gmail 如何chatbox 实现了他们的聊天功能。

进步：

我已经完成了类似 facebook 的聊天框结构，右侧边栏显示我可以聊天的在线朋友，并在底部弹出聊天框，它能够扩展和最小化它。

我也完成了基于 MySQL 数据库的简单聊天。有一个表格，有 4 列 'sender'、'receiver'、'message'、'time' 用于存储对话。我的聊天框是这样工作的：

1.用户发送消息，我的前端javascript会获取用户输入的消息并通过Ajax将消息发送到服务器上的php文件。2.后端的php文件会将此消息存储到MySQL。3.如果接收者向发送者发送消息，前端将每3秒调用一次更新函数更新聊天框内容，并显示在前端的聊天中。

我不确定这是一个很好的方法，而且还有很长的路要走，我真的很担心。如果用户不断增长，我必须想办法很好地扩展它，否则我的数据库和服务器会爆炸，前端用户可能会在更新对话时感到高延迟。

如果您有数百万在线用户，那么 BigTable 是正确的方法吗？

facebook 如何在后台很好地存储客户的短信或聊天记录？像 Whatapp 这样的聊天应用程序如何存储他们的短信？是否可以让用户直接与另一个用户聊天而不在服务器中存储状态？

如果我想在我的聊天框中实现聊天历史功能，有什么好方法？我认为服务器可以为其文件系统中的每个对话创建 .txt 文件，并且它有一个数据库表列来存储文件路径。这是处理聊天记录的好方法和正确方法吗，我知道可以这样做，但我不确定它是正确方法还是好方法。

我知道这可能是一个庞大而详细的应用程序。我问的不是一个详细的实现，而是一个大图，构建它的概念！

谢谢你！。

4

1 回答 1

3

这是一个很好的问题，这里尝试回答它。

我相信您考虑可扩展性有点为时过早。您的 IM 应用程序可能无法达到预期的用户数量，从而无法正常运行。考虑根据需要增强您的小型产品和规模。

磁盘 I/O 是扩展 Web 应用程序时将面临的问题之一。使用 txt 文件将通信直接存储到磁盘上可能不是一个可靠的解决方案。

在考虑更改或切换到其他东西之前，将您的技术堆栈推向极限。我假设您正在使用关系数据库进行存储（因为您提到了列和行，这不是最终指标，但仍然如此），还有其他选项可以提供良好的基准测试结果，但会牺牲多种其他妥协。（NoSQL：您称为 BigTable）是一种选择。关系数据库很棒，很长一段时间以来它们一直是行业标准，但目前有一些非常有前途的替代解决方案。

查看基于 NoSQL 文档的数据存储解决方案，例如MongoDB、CoucheDB甚至Casandra，还有许多其他解决方案。在特定情况和情况下，有大量关于每种性能的信息。选择最适合手头问题的东西，而不是最时尚或最时髦的东西。

另一种选择是将您的可扩展性问题外包给第三方提供商，例如Firebase。在这种情况下，您只需要担心您的产品，而不是引擎盖下发生的事情。

仅存储您需要的数据并归档或关闭您不需要的数据。

对于可扩展性，通常有 2 大类：水平扩展和垂直扩展。

  1. 水平：意味着向系统添加更多节点，即添加更多服务器实例来处理额外负载。有许多云解决方案提供商使这种类型的扩展非常便宜和即时。

  2. Vertical：意味着除了使用允许您充分利用资源的特定技术之外，还向您当前运行应用程序的节点添加更多资源。这种优化发生在实例资源（即 CPU、RAM、磁盘空间等）和您的数据存储、选择的编程语言、您正在使用的算法等方面......您可能会意识到 php 和 mysql 不是t 这项工作的工具，但这是有争议的。

在此处阅读有关它的更多信息

分布式系统架构师/程序员还在运行时利用其他（更快的）编程语言（例如 C、C++ 甚至 Java）来加速某些任务。研究如何将应用程序分解为可以独立运行的更小的解耦模块/组件。（但我不确定你是否会使用 IM 客户端达到这个阶段，除非它变得像 Whatsapp 或 Facebook 聊天一样流行）。

我建议您阅读一些有关扩展 Web 应用程序和利用云计算的书籍。研究可扩展的架构并根据您的业务逻辑设计您的应用程序。

这是一个非常广泛和复杂的话题，我相信其他人可能对此事有更多有趣的见解。

于 2013-06-27T23:20:47.943 回答