facebook的状态更新机制背后的设计和架构是什么？

我打算创建一个社交网络,我不认为我完全理解facebook的状态更新模块是如何设计的.希望我能在这里找到一些帮助.在算法和数据结构级别,在社交网络中创建状态更新机制的最有效方法是什么？

对所有朋友进行全表扫描然后对他们的更新进行排序是非常天真和昂贵的.我们是否使用基于散列或其他东西的某种机制？请告诉我.

PS:我不是在谈论他们的EdgeRank算法,而是基本的状态更新.他们如何从数据库中查找和获取它们？

在此先感谢您的帮助!

1> Nick Zalutsk..：

---

这是一个很好的演示文稿,可以回答您的问题 具体答案出现在55:40左右,但我建议您观看整个演示文稿,以了解该解决方案如何适应整个架构.

简而言之:

特定服务器("叶子")存储特定用户的所有馈送项.因此,您的每个朋友的数据都完全存储在特定目的地.

当您想要查看新闻源时,其中一个聚合器服务器会向您的朋友的所有叶子服务器发送请求并对结果进行排名.聚合器基于每个朋友的用户ID知道哪些服务器发送请求.

当然,这非常简单.这只能工作,因为所有这些都是memcached,系统旨在最小化延迟,一些排名是在包含朋友的feed项等的叶子服务器上完成的.

你真的不想在数据库中找到任何一个以合理的速度工作的数据库.FB使用MySql主要作为键值存储; 在他们的规模上加入表是不可能的.然后他们将memcache服务器放在数据库和应用程序服务器的前面.

话虽如此,在你拥有它们之前不要担心缩放问题(当然,除非你为了它的乐趣而担心它们.)在第一天,缩放是你问题中最少的.

---

仔细踩踏,因为在游戏的这个阶段按比例建立可能会让你陷入坏习惯(比如将所有东西存放在一个关键的价值存储中而不是利用JOINs),这对你有害无益.)这一切都取决于你想要什么学习.FB由于其规模而具有非常特殊的需求.然而,当他们开始时,他们正在使用一个包含许多表的MySQL数据库服务器,包含许多列,并为每个请求连接表,就像其他人一样.对于99个项目中的100个,这仍然是要走的路.

---

想象一个包含两列的巨大数据库表:id,data.他们使用[分片](http://en.wikipedia.org/wiki/Sharding)根据id拆分此表.所以ids 1-1000将驻留在server1上,ids 1001-2000将驻留在server2上,等等.这些服务器中的每一个都是FB称之为"叶子"的服务器.(即一个分片)现在,如果你想做一个SUM(),例如id为30的东西和id为1030的东西,你就不能,因为它们生活在不同的服务器上.这就是其中一个聚合器服务器进入的地方.它进入两个叶子服务器并获取行.然后它执行SUM()并返回结果.