我刚刚看到了热闹的" Twitter的兴衰"，这使我想到：

如果重新实现了twitter，我们将采取什么不同的措施？

我们将使用什么技术？什么语言？

我们如何确保服务可扩展？

我们还会改变什么？

解决方案

它已经完成了：Laconica

我从一开始就将其设计为可扩展的，就像地狱一样。

我的选择是Microsoft平台，C＃，IIS，SQL Server，Memcached(如果是Final且在我启动时运行良好，则为Velocity ；-)

• 已经完成第二部分-复仇：identi.ca(位于Laconica的顶部)
• 第三部分-从黑暗面看：yammer

VBG！ (-：

我将从重新做一次的前提开始：我会做些不同的事情，那时候我在Twitter吗？

没事

Twitter始终专注于重要事项：提供人们实际上想要使用的服务。

我很想研究一款产品，它在如此短的时间内变得如此流行，以至于其最大的威胁变成了自己的可扩展性。那意味着你赢了。成功伴随着资源和注意力，以利用成功。

我会在GAE上实现它，就像这样：

每个用户都有一张表格，其中包含他们关注的人的推文。该表将由(用户，时间戳降序)键入。

每个用户还具有一个follower_ranges表，该表将用户映射到一组连续的关注者ID范围。对于大多数只有几千个关注者的用户，此表将具有单个条目(-inf .. + inf)；这将是默认的默认值。对于具有更多关注者的用户，表中的每个范围都会有几千个用户。范围将在一段时间内保持平衡，以将每个用户的数量保持在一定的时间间隔内，例如大于1000，小于10000。所有范围的并集将包括所有用户ID。

每当创建用户->跟随者操作时，它就会被编码为一个动作并添加到队列中。队列中的每个元素都是一个(发送者，操作，有效负载，关注者子范围)元组。队列工作者采取一项措施，找到给定子范围内的所有关注者，并将操作应用于每个关注者。 (请注意，操作可以是"添加推文"，"删除推文"，"编辑推文"等。基本上，任何需要应用于所有关注者的内容。)

将队列操作应用于每个关注者将涉及对每个用户的tweet表发出相应的写入和删除操作。队列的障碍将意味着写入不会立即出现，但是应该可以将延迟保持在几秒钟以下。

向用户显示其推文将是一项廉价的操作："从推文中选择* *，其中user_id =：user_id ORDER BY(created_at DESC)LIMIT：max_per_page"。这将扫描单个表，并且是非常快速的操作。 (降低用户阻止延迟是一件好事！)

我认为这种设计最初可以很好地扩展。系统的每个组件现在都可以轻松扩展：

• 队列存储可以由GAE支持，并可以根据任何数据存储表进行扩展
• 前端可以自然缩放，无需粘性
• 可以随时添加更多的队列处理器
• 实际的存储表将自然增长，并应在数据存储区上很好地扩展。

也就是说，我可以想到我会立即研究的一些未来改进：

• 减少很少显示的数据的存储。此设计将每个推文归一化为每个从属副本。但是，通常仅访问最新的tweet。通过在N天前删除每个用户的推文副本，我们可以恢复大量存储空间。如果用户尝试查看古代历史中的某些内容，我们将从非规范化表中获取数据。这将比较慢，但不会经常发生，并且可以节省大量资金。节省的存储空间：(＃avg_followers-1)/ #avg_followers
• 写模式不是最佳的。跨多个队列项目，每个队列工作人员将写入每个用户的tweets表，因此写入的位置将不是很好。 (最坏的情况是，我们将有#processor * #storage服务器连接。)这可以通过对每个用户范围应用多个更新来解决。例如，如果要将两个动作A和B应用于范围[0，10000)，则让单个队列处理器一次应用这两个动作。