假设您有一个新网站，里面有大量数据（如大图片），您正准备将其上线。如果您做了“过多”的宣传，那么在最初几天，网站就会被大量请求淹没。
我怎样才能减轻这种风险？
我想到过
- 像 SO 和 SF 一样逐步上线：“私人”测试版、公开测试版、公开
- 允许 X
連接同时进行会话，因此已连接的用户仍可获得良好的网站体验，而其他用户则会收到一条友好的道歉消息
我不能：
- 购买更多服务器，因为在最初几天之后，网站的流量就会少很多:)
答案1
- 尽可能多地缓存。任何动态创建的页面都应缓存，以便用户获得静态版本。页面中查询数据库的组件也应缓存。
- 尝试使用 Amazon S3 等外部服务来提供图像和多媒体（或者在网站突然受到大量流量冲击时准备好使用它）。
逐步上线对 SOF 和 SF 来说是可行的，因为 Jeff 和 Joel 的博客很受欢迎，他们已经拥有了内在的宣传和需求。如果你没有像他们那样几乎保证有用户群，那么逐步上线可能会是致命的。
我会避免通过并发会话进行限制，因为很难定义因不活动而导致的会话结束。如果用户离开 15 分钟并尝试重新加载其页面，却只收到一条错误消息 - 您就失去了一个用户。
答案2
你的数据模型经过了多少规划？你是否设计了一个模式，让你能够增加查询量，而无需昂贵的排序、二进制列或复杂的连接？你是否调整过数据库后端（假设你有一个）？
您如何提供“大图像”？您可以将其拆分成单独的 Web 服务器进程，甚至是单独的域吗？
您是否对系统进行过负载测试？ApacheBench 和 Siege 等工具非常有用。
您的所有配置都在 svn 中吗？您的部署是自动化的吗？当您必须将我们的应用程序推广到第二台服务器时，您会为此感到高兴。
答案3
邀请系统有时是控制网站用户使用率的好方法。一开始就发出一定数量的邀请，这样网站就不会变得不堪重负。然后给每个用户一些邀请，让他们传给其他人，慢慢增加网站上的用户数量。这样一开始就不会有太多人访问网站，也不会出现巨大的流量高峰。
当然，缺点是，一开始你可能会拒绝很多没有邀请的用户，他们以后可能不会再回来。除非你有一个非常好的网站，人们非常乐意使用，否则这可能是一个糟糕的举动。这真的取决于网站。另外，你实际上必须花一些额外的开发时间来添加邀请系统。
答案4
您可能需要研究第三方静态内容托管，例如 Amazon S3。根据您的应用程序，使用 Amazon EC2 进行一些云存储（尽管我讨厌这个流行词）可能是值得的。