facebook/gmail一样的网络聊天框——现在聊天应用存储短信的好方法是什么？

Question

我目前正在构建一个类似于facebook的聊天室，在构建过程中我遇到了一些考虑事项和问题。

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

我的目标是建立一个像facebook/gmail聊天室和Cometchat一样的聊天室，我知道这很难，而且场景背后有太多的东西要扩展，但是我想做的就是尽可能简单地构建它，并弄清楚facebook/gmail聊天室是如何实现他们的聊天的功能性。

进展情况：

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

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

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

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

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

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

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

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

非常感谢。

Answer 1

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

我相信你考虑可扩展性有点太早了。您的IM应用可能无法达到预期用户数，因此无法停止良好运行。考虑增强您的小产品和规模，因为你去尽可能多的需要。

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

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

看看NoSQL基于文档的数据存储解决方案，比如MongoDB、CoucheDB甚至Casandra，还有很多其他的解决方案。在特定的情况下，有大量关于每一个人表现的信息。选择最适合当前问题的，而不是最时尚或时髦的。

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

只存储您需要的数据，归档或丢弃您不需要的数据。

可伸缩性通常有两大类：水平和垂直伸缩。

>

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

垂直：意味着向当前运行应用的节点添加更多资源，此外还可以使用特定技术来充分利用资源。这种优化发生在实例资源的级别上（即：CPU，RAM，磁盘空间等）和您的数据存储，选择的编程语言，您正在使用的算法等...你可能意识到php和mysql不是这项工作的工具，但这是有争议的。

阅读更多关于它在这里

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

我建议你抓住并阅读几本关于扩展网络应用程序和利用云计算的书。研究可扩展架构，并根据基于它们的业务逻辑设计应用程序。

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