架构 Twitter

风行的社交应用Twitter ，其底层架构最近已成为多次讨论的焦点。由于团队试图解决一些问题，Twitter已经有几次停止运行的情况，并关闭了几个常用的功能。从Twitter 的前进脚步之中，我们能学到些什么呢？包括 Om Malik 和 Dare Obasanjo 在内的几个人猜测是 Twitter 的底层架构导致了这些问题的出现。最近，Robert Scoble 就应用情况和公司前景采访了Twitter 的Evan Williams 和Biz Stone 。采访的视频可在 qik 上找到。

在采访中，Williams 和 Stone 回答了关于 Twitter 数据架构的大问题：Twitter 是否使用单实例存储（SIS）类型的方法来处理用户消息？在大约 13 分钟的采访记录中，Williams 谈到了消息存储和用户时间线检索：

它不是这么处理的（为用户的每个跟随者都产生一个消息副本），但实际上这可能更有效率。现在消息存储到数据库中，当人们想获取他们的时间线时，我们从数据 库中构造时间线，然后缓存到内存中，当然不是每次都缓存。但由于内容写入太频繁，我们往往也要频繁地访问数据库，而这只是为了更新缓存。所以缓存中有很多 消息副本，而在磁盘上却只有一条消息。我们以后的架构可能更多的是以多次写入的方式，因为读取在这种方式下将快更多。

从 SIS 消息架构迁移的可能性为利用像数据Sharding 这样的数据技术开启了一扇大门，数据Sharding 技术已经在许多高容量网站和应用中广受欢迎。Randy Shoup谈到了eBay 通过部分利用Sharding 来架构系统的方式，以此获得高可伸缩性：> 数据库层次的问题比较有挑战性，原因是数据天生就是有状态的。我们会按照主要的访问路径对数据做水平分割（或称为“Sharding”）。例如用户数据目 前被分割到20 台主机上，每台主机存放1/20 的用户。随着用户数量的增长，以及每个用户的数据量增长，我们会增加更多的主机，将用户分散到更多的机器上 去。商品数据、购买数据、帐户数据等等也都用同样的方式处理。用例不同，我们分割数据的方案也不同。

Bogdan Nicolau 写过一篇为数据库Sharding 基础的概述。在该系列中，Bogdan 讨论了如何决定在何处、以及如何为应用分割数据。决定时的主要一点是：> 我试图表达的是，无论你选择什么逻辑来切分表，总是要记住你不想有任何join、order by、或limit 语句，这些语句会需要不止一个的表Shards。

Bogdan 继续谈论了应用端对Shards 的利用。Bogdan 提供了几个代码例子来解释一个典型问题，同时还解释了背后的原理：> 正如你所看到的，因为要生成映射表，负担主要落在了写入一方。读取时就不需要关心涉及的数据切分算法了。

随着众人参与关于如何扩展Web 2.0 的讨论，Twitter 也许将继续向一个更稳定、可伸缩的架构迈进。InfoQ 有许多性能和可伸缩性相关的资源，在这里查看这些资源。

查看英文原文： Architecting Twitter