如果你重新实现twitter，你会做什么不同？

Question

我刚看到搞笑"The Rise and Fall of Twitter"这让我觉得：

如果你重新实现twitter，你会做什么不同？

您会使用哪些技术？什么语言？

如何确保服务可扩展？

你还会改变什么？

Answer 1

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

每个用户都将有一个包含他们关注的人的鸣叫的表。这个表格将被键入（用户，时间戳降序）。

每个用户还有一个follower_ranges表，它将用户映射到一组连续的跟随者id范围。对于只有几千名粉丝的大多数用户来说，这张表会有一个条目（-inf .. + inf）;这将是默认的默认值。对于拥有更多追随者的用户而言，表格中的每个范围都有几千个用户。范围将随时间平衡以保持每个用户在某个时间间隔内的用户数量，例如，大于1000，小于10000.所有范围的联合将包括所有用户ID。

无论何时创建用户 - >追随者操作，它都会被编码为一个操作并添加到队列中。队列中的每个元素都是（发送者，操作，有效负载，跟随者子范围）元组。队列工作者需要一个项目，找到给定子范围内的所有追随者，并将这个动作应用到他们中的每一个。 （请注意，该动作可以是“添加推文”，“删除推文”，“编辑推文”等。基本上任何需要应用于所有追随者的内容。）

将队列动作应用到每个跟随者将涉及到发出相应的写入和删除到每个用户的推文表。队列的障碍将意味着写入不会立即出现，但应该可以将延迟保持在几秒钟之内。

向用户显示他们的推文将是一个便宜的操作：“SELECT * FROM tweets WHERE user_id =：user_id ORDER BY（created_at DESC）LIMIT：max_per_page”。这将扫描一张表，并且是一个非常快速的操作。 （保持用户阻塞延迟很好！）

我认为这个设计最初会比较好。该系统的每个部件现在可以容易地按比例增加：

• 队列存储可由GAE进行备份，并缩放按任何数据存储表
• 的前端可以自然缩放，并且没有必要为粘性
• 可以随时添加更多队列处理器
• 实际存储表会自然增长，并且应该在数据存储上很好地缩放。

这么说，我能想到的一对夫妇未来的改进我会考虑立刻道：

• 减少很少图示的数据的存储。此设计将每条推文非规范化为每个关注者的副本。不过，通常只能访问最近的推文。通过在用户N天后删除每个用户的推文副本，我们可以恢复大量存储空间。如果用户试图查看古代历史中的某些内容，我们从非规范化表格中获取数据。这将会变慢，但不会经常发生，节省将会很大。存储节省：（#avg_followers - 1）/ #avg_followers
• 写入模式是非最佳的。在多个队列项目中，每个队列工作人员将写入每个用户的tweets表，因此写入的局部地址不会很好。 （最糟糕的情况是，我们会有#processor * #storage服务器连接。）这可以通过对每个用户范围应用多个更新来解决。例如，如果将两个操作A和B应用于范围[0，10000），则让一个队列处理器一次应用这两个操作。

Answer 2

它已经正在做：Laconica

Answer 3

我设计它可扩展像是刚刚从一开始地狱。

我的选择将是微软平台，C＃，IIS，SQL服务器，Memcached的（或速度，如果它是终局的，运行很好，当我开始;-)

Answer 4

1. 它已经正在做第二部分 - 的复仇：identi.ca（这比Laconica的顶部）
2. 它已经正在做第三部分 - 从黑暗面：yammer

VBG！ （ - ：

Answer 5

我打算从回去做一遍的前提开始：我会做什么不同的，是我在twitter上当时

没有的事

？ Twitter的维持要紧的重点：提供服务，这人居然想使用

我很想上变得如此受欢迎，在这样短的时间周期，其最大的威胁变成了自己的可扩展性的产品配合使用这意味着你赢了，成功来自资源和意图利用成功。