第一个架构改动是创建一个直写式向量缓存包含了一个tweet ID的数组，tweet ID是序列化的64位整数。这一缓存的命中率是99%。

    第二个架构改动是加入另一个直写式行缓存，它包含了数据库记录：用户和tweets。这一缓存有着95%的命中率并且使用了Nick Kallen的名为Cache Money的Rails插件。Nick是Twitter的一名系统架构师。

    第三个架构改动是引入了一个直读式的碎片缓存，它包含了通过API客户端访问到的tweets的序列化版本，这些tweets可以被打包成JSON，XML或者是Atom的格式，有着同样是95%的命中率。这一碎片缓存“直接消费向量，而且如果现在缓存了一个序列化的碎片，它不会加载你试图看到的该tweet的实际的行，因此它将在大量时间将数据库置于短路状态，”Evan这样说到。

    还有另一个改动是为页面缓存创建一个单独的缓存池。根据Evan的说法，该页面缓存池使用了一个分代的键模式，而不是直接的失效，因为用户可以发送HTTP的if-modified-since并且将任何他们想要的时间戳放入请求路径，我们需要将这一数组切片并只呈现给他们他们想要看到的tweets，但我们不想跟踪客户端所使用的所有可能的键值。这一分代的键模式有一个大问题，在于它不会删除所有失效的键值。每一个被加入的对应到人们所接收的tweets数目的页面都会向缓存推送有效的数据，最后变得我们的缓存仅仅只有五个小时的有效生命周期，因为所有的页面缓存都将流过。

    当该页面缓存转移到其自己的池之后，缓存未命中降低了将近50%。

    这是Twitter现在所使用的缓存模式：

    因为80%的Twitter流量都来自API，因此还有额外的二层缓存，每一个最多将处理95%来自前一层的请求。整体的缓存改动总共有百分之二三十的优化，它带来了

    10倍的容量提升，它本可以更多，但现在我们遇到了另一瓶颈...我们的策略是首先加入直读式缓存，确保它正确失效，然后再转移到直写式缓存并且在线修复，而不是当一个新的tweet ID进来时每次都要销毁。