我目前正在建立一个类似Facebook的聊天框,并且在此过程中遇到了一些注意事项和问题.
我一直在搜寻有用的资源,例如简单的聊天框示例或在线教程.
我的目标是建立一个像facebook / gmail chatbox和CometChat一样的东西,我知道要扩展到幕后非常困难,但我要做的就是尽可能简单地构建它,并弄清楚facebook / gmail如何chatbox实现其聊天功能.
进展：
我已经完成了类似Facebook的聊天框结构,在其中的边栏在右侧显示了我可以聊天的在线朋友,在底部弹出了chatbox,它能够扩展和最小化它.
我还完成了基于MySQL数据库的简单聊天.
有一个包含4列“发送者”,“接收者”,“消息”,“时间”的表,用于存储对话.
我的聊天框是这样工作的：
1.用户发送一条消息,我的前端javascript将获取用户键入的消息,然后通过Ajax将消息发送到服务器上的php文件.
2.后端php文件会将此消息存储到MySQL.
3.如果接收方向发件人发送消息,则前端将每3秒调用一次更新功能以更新聊天框内容,并在前端的聊天中显示出来.
我不确定这是一个好方法,而且很长,我真的很担心.
如果用户不断增长,我必须想办法很好地扩展它,否则我的数据库和服务器将会爆炸,前端用户在更新对话时可能会感觉到高延迟.
如果您有数百万的在线用户,BigTable是执行此操作的正确方法吗？
Facebook如何在后台很好地存储其客户的短信或聊天记录？
诸如Whatapp之类的聊天应用程序如何存储其短信？
是否可以让用户直接与其他用户聊天而无需在服务器中存储状态？
如果我想在我的聊天框中实现聊天记录功能,有什么好的方法？
我认为服务器可以为文件系统中的每个会话创建.txt文件,并且它具有一个数据库表列来存储文件路径.这是处理聊天记录的好方法,也是正确的方法,我知道有可能用这种方法,但是我不确定这是正确的方法还是好方法.
我知道这可能是一个庞大,详细的应用程序.
我要问的不是详细的实现,而是总体构想！
谢谢！.
解决方法:
这是一个很好的问题,下面是尝试回答的问题.
我相信您对可伸缩性的考虑还为时过早.您的IM应用可能无法正常运行,因此无法达到预期的用户数量.考虑根据需要扩展您的小型产品并扩展规模.
磁盘I / O是扩展Web应用程序时将面临的问题之一.用txt文件将通信直接存储到磁盘上可能不是一个可靠的解决方案.
在考虑对其进行更改或切换到其他内容之前,将技术堆栈推到极限.我假设您正在使用关系数据库进行存储(因为您提到了列和行,但这并不是最终指标,但仍然存在其他选择),这些选择具有良好的基准测试结果,但会牺牲许多其他折衷方案. (NoSQL：您称为BigTable)是一种选择.关系数据库很棒,它们已经成为行业标准已有很长的历史了,但是目前有替代的解决方案很有前途.
查看基于NoSQL文档的数据存储解决方案,例如MongoDB、CoucheDB甚至Casandra,还有许多其他解决方案.在特定情况下和特定情况下,有大量有关它们的性能的信息.选择最能解决当前问题的方法,而不是最时髦或最时髦的方法.
另一种选择是将可伸缩性问题外包给第三方提供商,例如Firebase.在这种情况下,您只需担心的是您的产品,而不是引擎盖下发生的事情.
仅存储您需要的数据,然后存档或删除不需要的数据.
对于可伸缩性,通常有2大类：水平和垂直缩放.
>水平：表示向系统中添加更多节点,即添加更多服务器实例以处理额外的负载.有许多云解决方案提供商可以使这种扩展类型变得非常便宜和即时.
>垂直：表示除了使用允许您充分利用资源的特定技术外,还向当前运行应用程序的节点添加更多资源.这种优化发生在实例资源(即CPU,RAM,磁盘空间等)和您的数据存储,选择的编程语言,所使用的算法等级别上……您可能意识到php和mysql不是这项工作的工具,但这是有争议的.
分布式系统的架构师/程序员还可以在运行时利用其他(更快)的编程语言(例如C,C甚至Java)来加速某些任务.研究如何将应用程序分解为较小的可独立运行的解耦模块/组件. (但是我不确定您是否会使用IM客户端达到这个阶段,除非它像Whatsapp或Facebook聊天一样受欢迎).
我建议您阅读并阅读有关扩展Web应用程序和利用云计算的几本书.研究可伸缩的体系结构,并根据基于它们的业务逻辑来设计应用程序.
这是一个非常广泛和复杂的主题,我相信其他人可能对此事还有其他有趣的见解.