php - facebook/gmail 类似 web 聊天框 - 现在聊天应用程序存储文本消息的好方法是什么？

Question

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

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

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

进度:

我完成了类似 facebook 的聊天框结构，右侧有侧边栏显示可以聊天的在线 friend ，底部有弹出式聊天框，它可以展开和最小化。

我也完成了基于MySQL数据库的简单聊天。 有一个包含 4 列“发送者”、“接收者”、“消息”、“时间”的表格，用于存储对话。 我的聊天框是这样工作的:

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

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

如果您有数百万在线用户，BigTable 是否是执行此操作的正确方法？

facebook 是如何在后端存储客户的短信或聊天记录的？ Whatapp 之类的聊天应用程序如何存储他们的短信？ 是否可以让用户直接与另一个用户聊天而无需在服务器中存储状态？

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

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

谢谢!

Answer 1

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

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

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

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

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

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

只存储您需要的数据，归档或关闭不需要的数据。

关于可伸缩性，通常有两大类:水平和垂直伸缩。

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

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

Read More about it here

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

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

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