问是否对10000客户端/秒问题的解决方案进行了现代审查

EN

C10K问题通常假设您正在尝试优化单个服务器，但正如您的参考文章所指出的那样，“硬件不再是瓶颈”。因此，要采取的第一步是确保它不是最简单和最便宜的，只是在混合中投入更多的硬件。

如果我们有一个每秒为X个客户提供服务的500美元的盒子，那么只需再购买500美元的盒子就可以使我们的吞吐量翻一番，而不是让员工狼吞虎咽地想着如何从原来的盒子里挤出更多的时间和金钱。当然，这是假设我们的应用程序是多服务器友好的，我们知道如何负载平衡，等等……

巧合的是，就在几天前，编程Reddit或Hacker News提到了这篇文章：

Thousands of Threads and Blocking IO

在Java的早期，我的C编程朋友嘲笑我用阻塞线程做套接字IO；那时，我别无选择。如今，有了充足的内存和处理器，这似乎是一种可行的策略。

这篇文章的日期是2008年，所以它将你的视野拉高了几年。

要回答OP的问题，您可以说，今天的等效文档不是针对负载优化单个服务器，而是针对负载优化整个在线服务。从这个角度来看，组合的数量是如此之大，以至于你正在寻找的不是一个文档，而是一个收集了这样的架构和框架的实时网站。这样的网站已经存在，它的名字叫www.highscalability.com

附注1：

我反对将更多的硬件投入其中是一个长期的解决方案：

• 也许与单个服务器的成本相比，“获得”性能的工程师的成本很高。向外扩展时会发生什么？假设您有100台服务器。服务器容量提高10%可以为您每月节省10台服务器。
• 即使您只有两台计算机，您仍然需要处理性能峰值。在负载下优雅降级的服务和崩溃的服务之间的区别在于，有人花时间优化负载方案。

附注2：

这篇文章的主题有点误导。CK10文档没有尝试解决每秒10k个客户端的问题。(每秒的客户机数是无关紧要的，除非您还定义了一个工作负载以及有限延迟下的持续吞吐量。我想Dan Kegel在写那篇文章的时候就意识到了这一点。)相反，可以将其视为构建并发服务器的方法的概要，以及相同的微基准。也许从那时到现在的变化是，您可以在某个时间点假设该服务是为提供静态页面的网站提供的。如今，服务可能是noSQL数据存储、缓存、代理或数百个网络基础设施软件中的一个。