张鹏 的技术

在众多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’ 应用服务器