我最近完成了一个中间交易（？）网站的开发（峰值60k点击/小时），然而，该网站只需要每分钟更新一次 - 并且可以用一个单词来总结所需的性能：“缓存”。
对于像SO这样的网站，其中为网站提供的数据一直在，，我认为需要采用不同的方法。
页面缓存时间可能需要很短或不存在，并且需要在所有Web服务器上快速传播更新，以使所有用户保持最新状态。
我的猜测是你需要一个分布式缓存来控制几秒钟内更新的数据和页面的服务，可能是数据库上方的分布式缓存来调解写入？
那些经验丰富的人是否可以概述他们采用的一些关键架构/设计原则，以确保像SO这样的高度互动的网站具有高效性？
答案 0 :(得分：3)
您可能对描述维基媒体服务器结构的this article感兴趣。非常有启发性！
文章链接到this pdf - 请务必不要错过。
答案 1 :(得分：3)
绝大多数网站的读取次数多于写入次数。每次写入都有数千甚至数百万次读取并不罕见。
因此，任何缩放解决方案都依赖于将读取的缩放与写入的缩放分开。通常，缩放读取非常便宜且容易，缩放写入操作既复杂又昂贵。
扩展读取的最直接方法是一次缓存整个页面，并在一定的秒数后使它们到期。如果你看看热门的网站，Slashdot。你可以看到这是他们扩展网站的方式。不幸的是，这种缓存策略可能导致最终用户的反直觉行为。
我从你的问题中假设你不想要这种原始的缓存。就像你提到的那样，你需要更新缓存。
这并不像听起来那么可怕。要实现的关键是从服务器的角度来看。 Stackoverflow不会一直更新。它很少更新。也许每秒一次或两次。对于计算机来说，第二个几乎是永恒的。
此外，缓存中的项目往往会发生更新，这些项目不相互依赖。以Stack Overflow为例。我想每个问题页面都是单独缓存的。大多数问题可能在前十五分钟内平均每分钟更新一次，然后可能在一小时后每小时更新一次。
因此，在大多数应用程序中，您几乎不需要扩展写入。它们之间的距离很小，你可以让一台服务器进行写操作;更新缓存实际上是一个非常可行的解决方案。除非您拥有极高的流量，否则您将同时获得同一缓存项目的并发更新。
那么你如何设置呢？我的首选解决方案是将每个页面单独缓存到磁盘，然后有许多Web头从一些可相互访问的空间提供这些静态页面。
当需要完成写入时，它只从一个服务器完成，这将更新该特定的缓存html页面。每个服务器都拥有自己的缓存子集，因此没有单点故障。更新过程经过精心设计，以便事务确保没有两个请求不会在同一时间写入文件。
我发现这个设计已满足我们目前所需的所有缩放要求。但这取决于网站的性质和负载的性质，以确定这是否适合您的项目。