张鹏 的技术

在众多Facebook 产品中，消息系统无疑是技术挑战最大的一个。因此我们需要建立一个专有的应用服务器来管理这些基础设施。

我们最近讨论了消息系统的后端组件，以及我们如何扩展我们的服务以处理来自Email ，SMS， Facebook Chat ,收件箱的海量消息，本文我们就分享一下应用服务器的设计细节。

应用服务业务逻辑层

应用服务器整合了很多Facebook服务，封装了访问这些服务的复杂性。 他为客户端，封装了一个简单的接口来处理标准的消息操作，包括创建，读取，删除，更新消息和收件箱。

下面介绍一个每个操作的流程。

当创建一个新的消息或者回复一个消息的时候，应用服务器将消息投递到接收方（用户），如果接收方是个email地址，应用服务器还会去HayStack检查一下，是否有附件，然后创建一个html格式，遵从RFC2822标准的消息。

当消息（邮件）通过外部的邮件地址发送到Facebook内部用户系统的时候，服务器会将消息投递到用户的收件箱，根据一些预设的条件，对消息进行必要的处理，决定消息投递到哪个目录，那个话题里面。

当读取消息的时候，服务器会获取多项关于用户Mailbox的统计数据，例如容量，消息数量，话题数量，回复数量； 用户的活跃联系人数量。 服务器还会获取收件箱里面目录的统计信息和属性信息。在读取话题列表的时候，是通过一系列的搜索条件（目录，属性，作者，关键词等），话题列表里面包括话题的基本属性和话题下面的消息。

当删除消息的时候，服务器将消息和话题标识成删除状态，然后一个离线的作业会执行具体的删除消息操作。

当更新消息和话题的时候，服务器变更消息和话题的属性，比如【已读/未读】 ，归档状态，Tag 等等。更新操作还负责处理针对话题的订阅，退订操作。

管理话题组

Facebook 通过聊天室的模型管理群组话题消息。 用户可以加入（订阅），或者离开（退订）某一话题。在回复某个话题，当收件人不是某个用户，而是一个Email地址的时候，应用服务器会创建一个回复处理器，就像聊天室ID一样，当收件人通过回复了这个话题，消息会通过回复处理器，直接投递到那个话题。

为了优化读性能，简化迁移和备份过程，话题消息存储通过一个非规范化的模式来存储，因此每个用户，都有他自己的一份话题元数据，和消息的拷贝。服务器广播订阅和退订事件，在所有的接收者中，同步话题的元数据数据，从而可以用去中心化得方式，来处理订阅和回复等请求。当处理老的系统时候，比如用户的老的收件箱，或者通过Email地址来订阅，应用服务器会做些特别的适配工作，以保证业务流畅。

缓存用户的元数据

当用户访问收件箱的时候，应用服务器加载用户常见的元数据，（我们叫做活动元数据），然后缓存在LRU里面，后续请求可以尽量少查询HBASE，从而提升效率。

我们尽量减少对HBASE          的查询，是因为HBASE不支持join. 为了服务一个读请求，服务器可能要查找多个索引，在不同的     HBASE查询中抓取元数据和消息内容。Hbase针对写，而不是读做的优化，幸运的是，用户行为通常具有良好的时间和空间局部性，因此通过Cache可以解决性能问题。

我们也做了很多努力，通过减少用户内存痕迹，采用更细粒度的架构来提高Cache效率。我们可以缓存5%-10%的用户，命中率在95%左右。对于超热点数据，比如主页的未读消息数，我们将其放到全局的Memcache层。当新的消息到达时，应用服务器负责将缓存中的数据做过期处理。

同步

HBase对于交易的隔离提供了有限的支持。因此对于用户的多个并发更新，为了解决更新冲突，Facebook采用应用服务器来解决这个问题。每个用户，都会被分配到特定的应用服务器，因此针对这个用户的更新操作，都可以在这个应用服务器内，通过代码做到完全的同步隔离。

存储模式

MTA代理，将附件和大的消息到达应用服务器以前，将他们提提取出来，存储在Haystack中。当然元数据，包括搜索索引数据和小消息体，存储在HBASE中，由应用服务器来维护。每个用户的邮箱同其他用户的邮箱，都是相互独立的；用户数据在Hbase中，是不会共享的。每个用户的数据，都会存储在HBase中的一行中，Hbase行的数据结构如下：

元数据实体和索引

元数据实体，包含着收件箱对象的属性，比如文件夹，话题，消息等等。 每个实体存储在他自己的HBASE列中，不像传统的RDBMS，HBASE没有原生的索引支持。我们在应用层面，维护着二级索引。每个单独的列都已key/value对的形式存储。

例如，当我们查询“在其他目录的第二页加载未读话题”，应用服务器首先查询元数据索引，获取符合查询条件的话题，然后抓取特定话题的元数据实体，通过他们的属性来构造响应对象。

就像我们前面提到的，缓存和有效的预加载减少了Hbase的查询次数，提升了系统效率。

动作日志 . . . → Read More: 深入理解Facebook Messages’ 应用服务器

谁能看到什么？ 谁能回复谁？ 内容在多长时间内可见？ 内容之间，如何关联？ 谁和谁能够关联？ Who can see what? Who can reply to whom? How long is content visible? What can link to what? Who can link to whom?

区分社交媒体类型的6个维度

生产者，消费者的用户数量 交互频率 基本元素的类型 对于基本元素，是如何控制的 用户之间连接的类型 内容维系方式

Hulu.com 是在大洋彼岸的一个小传奇。由NBC ，FOX,ABC共同出资建立，出身很传统。刚刚开始上线的时候，硅谷乃至整个IT业看好它的人并不多。人们以为这不过是旧媒体的又一次“垂死挣扎”，但很快事情向另一个方向发展—— Hulu结束测试时已拥有500万用户和无数赞美。

Hulu的流量占美国视频网站的1%，但是收入占到了33%，传统传媒人，赚钱能力果然很猛。Hulu目前靠广告生存，2010年收入2.52亿美金，预计2011年5亿美金。广告客户600+。

Hulu的团队，带有明显的技术驱色彩，70%的技术人员，采用最fashion的方式来做事情，更重要的是，虽然stem from 美国，但是是纯粹的华人团队。

Hulu影片都是正版，制作精良，比如你可以在上面看到《英雄》。有250+各种机构，为他提供内容。正是因为版权，Hulu屏蔽了大部分国外地址，很多代理服务器，amazon的EC2,因此你不能在中国看到这个网站。但是这并不妨碍我们研究他:)

Hulu的郑华，在2011推荐系统峰会上面，介绍了他们的个性化推荐系统，您可以在这里下载Personalization in Hulu