我的客户要求我构建一个可以实时聊天，发送图像和视频的实时应用程序。他让我想出了我自己的技术堆栈，所以我做了很多研究，发现最容易构建的是使用下面的技术堆栈
1）Node.js和cluster为一个服务器实例最大化CPU核心 - 语言
2）Socket.io - 实时框架
3）Redis - 用于多个服务器实例的pub / sub
4）Nginx - 反向代理和负载均衡多个服务器
5）Amazon EC2 - 运行服务器
6）Amazon S3和CloudFront - 保存图像/视频并发送
如果我对上述筹码有误，请纠正我。我真正的问题是，上述技术堆栈每秒可以扩展1,000,000条消息（文本，图像，视频）吗？
任何有过node.js和socket.io经验的人都可以给我一些见解或上述堆栈的替代方案。
此致
SinusGob
答案 0 :(得分：1)
我真正的问题是，上述技术堆栈能否扩展1,000,000条消息 每秒（文字，图像，视频）？
当然可以。拥有合适的设计和足够的硬件。你的客户应该问的问题实际上不是能否做到这么大，而是以什么成本和实用性来做，那些是最好的选择。
让我们看看你提到过的每件作品：
node.js - 对于以I / O为中心的应用程序，它是高规模的绝佳选择，它可以通过在群集中部署多个CPU来扩展（每个进程都是多进程的）服务器和多服务器）。这种规模的实际程度取决于所有这些服务器进程需要访问的共享数据类型。通常，数据存储最终会成为扩展中更难的瓶颈，因为在请求处理中容易投入更多服务器。在集中式数据存储中投入更多硬件并不容易。有很多方法可以做到这一点，但这很大程度上取决于应用程序对你如何做到以及它有多难的要求。
socket.io - 如果您需要有效的服务器推送小消息，那么socket.io可能是最好的方法，因为它是推送客户端最有效的方式。但是，它在所有类型的运输方面都不是很好。例如，我不会通过socket.io移动大图像或视频，因为有更多专门建立的方法来做到这一点。因此，socket.io的使用很大程度上取决于应用程序想要使用它的具体内容。如果您想将视频推送到客户端，您还可以只推送一个URL并让客户端转身并使用众所周知的高级技术通过常规http URL请求视频。
Redis - 再次，对某些事情很好，对一切都不是很好。所以，这实际上取决于你想要做什么。我之前解释的是，您的数据存储的设计和通过它的交易数量可能是您的实际规模问题所在。如果我开始这项工作，我首先要了解服务器的数据存储需求，各种类型的每秒事务数，缓存策略，冗余，故障转移，数据持久性等......以及设计首先是大规模访问数据。我不能完全确定redis是首选。我可能建议您在项目早期需要一名高级数据库人员作为顾问。
Nginx - 很多使用nginx的高规模网站，所以它肯定是一个很好的工具。它是否适合您的工具取决于您的设计。我可能最后工作在这部分，因为它似乎不那么重要的设计，一旦系统的其余部分布局，你可以考虑你需要的东西。
Amazon EC2 - 几种可能的选择之一。这些选择很难在苹果与苹果的比较中直接比较。 EC2已经构建了大规模系统，因此可以得到概念证明，并且通用架构似乎是合适的匹配。如果你想知道真正的小鬼在哪里，你需要一个在EC2上做过大规模工作的顾问。
Amazon S3 - 我个人知道一些非常高的存储和带宽网站使用S3进行视频和图片处理。它适用于此。
所以......如果以正确的方式使用它们，这些通常可能是很好的工具。 Redis将是一个问号，取决于实际应用程序的存储需求（您提供了零要求，数据库无法选择，零要求）。一个更合理的答案将基于整合一系列高要求，分析系统需要做什么来为1,000,000提供服务。这些要求可以与其中一些部分的已知功能进行比较，以便在扩展系统时开始。然后，您必须将一些基准测试组合在一起，对系统的某些部分进行一些测试。失败的成功与否取决于应用程序的构建方式以及工具的使用方式，因为选择了哪些工具。您可以使用许多不同类型的工具进行成功扩展。哎呀，Facebook在PHP上运行（嗯，一个高度修改的，定制的PHP，在运行时根本不是典型的PHP）。