我真正的问题是，上述技术堆栈能否每秒扩展1,000,000条消息（文本，图像，视频）？

当然可以。具有正确的设计和足够的硬件。您的客户应该问的问题实际上不是是否可以将其做得那么大，而是可以以什么成本和实用性来完成，并且这些是最佳选择。

让我们看看您提到的每个片段：

node.js- 对于以I /
O为中心的应用程序，它是进行大规模扩展的绝佳选择，并且可以通过在集群中部署多个CPU（每个服务器和多个服务器都具有多个进程）来进行扩展。这种规模的实用性在很大程度上取决于所有这些服务器进程都需要访问哪种共享数据。通常，数据存储最终会成为扩展规模上更难的瓶颈，因为在请求处理时很容易抛出更多服务器。在集中式数据存储中添加更多硬件并非易事。有很多方法可以做到，但是在很大程度上取决于应用程序的要求以及您的操作方式和难度。

socket.io-
如果您需要有效的服务器推送小消息，那么socket.io可能是最好的方法，因为它是推送到客户端的最有效方法。但是，这并不是在所有类型的运输中都很好。例如，我不会通过socket.io来移动大型图像或视频，因为有更多专门构建的方式可以做到这一点。因此，socket.io的使用在很大程度上取决于应用程序到底要使用它的用途。如果您想将视频推送到客户端，也可以只推送一个URL，然后让客户端转转并使用众所周知的大规模技术通过常规http
URL请求视频。

Redis - Again, great for some things, not great at everything. So, it
really depends upon what you’re trying to do. What I explained earlier is that
the design of your data store and the number of transactions through it is
probably where your real scale problems lie. If I were starting this job, I’d
start with an understanding of the data storage needs for a server,
transactions per second of various types, caching strategy, redundancy, fail-
over, data persistence, etc… and design the high scale access to data first.
I wouldn’t be entirely sure redis was the preferred choice. I’d probably
suggest you need a high scale database guy as a consultant early in the
project.

Nginx-
许多使用nginx的大型站点，因此它无疑是一个很好的工具。对于您而言，它究竟是不是正确的工具取决于您的设计。我可能会在最后一部分进行工作，因为它似乎在设计中不太重要，一旦系统的其余部分布置完毕，您就可以在此处考虑所需的内容。

Amazon EC2-
几种可能的选择之一。这些选择很难直接进行比较。大型系统是使用EC2构建的，因此在那里有概念证明，并且通用体系结构似乎很合适。如果您想知道真正的gremlins在哪里，则需要一名在EC2上进行过大规模研究的顾问。

亚马逊S3- 我个人知道使用S3录制视频和图像的一些存储和带宽很高的站点。为此。

因此…如果正确使用这些工具，通常可能是不错的工具。根据实际应用程序的存储需求，Redis将是一个问号（您提供的需求为零，而不能选择需求为零的数据库）。一个更合理的答案是基于将一系列高级要求组合在一起，这些要求分析了系统为满足1,000,000的服务能力而需要做的工作。可以将这些需求与某些组件的已知功能进行比较，以开始扩展系统规模。然后，您必须将一些基准测试组合在一起，才能在系统的某些部分上运行某些测试。失败的成功很大程度上取决于应用程序的构建方式和工具的使用方式，以及选择工具的方式。您可以使用许多不同类型的工具成功进行扩展。哎呀，Facebook在PHP上运行（嗯，高度修改，定制的PHP在运行时根本不是典型的PHP）。