要点：
- Facebook 统一消息系统（邮件、短信、聊天、消息等）；
- 用 HBase 作为后端存储设施，每个用户数据存储在 HBase 的单独一行里，每个实体（文件夹、主题、消息等等）都存储在自己的HBase列中；
- 涉及 HayStack 图片处理基础设施；
- 使用 Apache Lucene 维护反向索引列表；
- 镜像了大约 10% 用户的实时聊天和收件箱中的信息到测试集群中，并通过 dark launch 进行测试。
![clip_image001]( "clip_image001")
Facebook Messages 是我们曾经所创建的最具技术挑战性的一个代表产品。
当我们发布Facebook Messages 时所提到的是我们需要打造一个专门的应用服务器来管理其基础架构。
我们最近讨论了消息后台和我们如何处理所有来自 email, SMS, Facebook Chat 和 Inbox 的通信。
今天我们将深入消息应用服务器的核心。
应用服务器的业务逻辑
应用服务器集成了众多Facebook服务和保护(shields)来自各种终端的复杂性。它提供了一个简单接口方便客户端进行标准消息处理，包括：创建、读取、删除、更新消息和收件箱。
下面是每一部分的流程。
当创建一个新消息或回复消息时，应用服务器代表发送者传递消息到收件人。如果收件人是通过其邮件地址，则服务器通过HayStack获得附件(如果有的话)，构造HTML主体，并创建一个RFC2822消息。
输出流
![clip_image002]( "clip_image002")
当消息发送给用户时，如果地址是一个回复处理，服务器将从存在的邮件地址和传递的输入消息中获得正确收件人的信息。服务器最终将消息传递到用户邮箱，运行所有必要的预处理和后期处理过程，并决定基于多个信号的文件夹和主题的消息路由。
输入流
![clip_image003]( "clip_image003")
当读取消息时，服务器取得有关用户邮箱的多个统计，如容量；消息、主题和回复数；朋友的数量等。同时也获得文件夹相关统计和属性，各种搜索条件的主题列表(文件夹，属性，作者，关键字等等)，主题属性和这个主题的其它消息。
当删除消息时，服务器标记要删除的消息和主题。一个离线任务具体清除消息内容。
当更新消息和主题时，服务器改变消息或主题属性，如读取和到达状态，标签等等。同时也处理多个用户对主题的订阅和取消订阅的请求。
![clip_image004]( "clip_image004")
管理群组主题
Facebook Messages 使用一个聊天室模型管理群组消息主题。用户能加入（订阅）和离开（取消订阅）。
当邮件地址是是这个主题的指定接收者时这个模型是必须的，应用服务器创建一个回复处理器，类似聊天室ID。当一个邮件接收者回复了主题，则消息会被发送到回复处理器地址。
为了优化读取性能和简化移植和备份处理，消息主题以一种非规格化(denormalized)的方式存储。于是每个用户都拥有一份主题元数据和消息 的拷贝，服务器广播订阅和取消订阅事件，在一个分散的方式中同步所有接收者订阅和回复处理的主题元数据。服务器也管理类似用户仍旧使用老的收件箱或通过他们的邮件地址订阅的情形。
缓存用户元数据
当用户访问收件箱时，应用服务器装载最常用的用户元数据(也称活动元数据)并将它们保存在最近最少使用的缓存中(a least recently used cache，也就是LRU算法)。随后，同一用户的请求会通过少量的HBase查询被快速的处理。
我们需要减少HBase查询，因为HBase不支持join, 为处理一个读请求，服务器可能需要在分开的HBase查询中查找多个索引和匹配元数据和消息体。HBase的最佳化体现在写操作而不是在读取上，用户行为 通常拥有好的时间和地域性(good temporal and spatial locality)，于是缓存能帮助解决这个问题并提升性能。
我们也在通过减少用户内存占用和转移到细粒度模式进而提升缓存的有效性方面做出了很多努力。我们能缓存5%-10%的用户量和95%的活跃元数据缓 存命中率。我们在全局的memcache层缓存了访问极为频繁的数据（如在Facebook首页显示没有阅读的消息数）。当新消息到达时应用服务器标记缓存为(dirties)(注：dirties表示修改了但还没有写到数据文件的数据)。
同步
HBase对事务隔离提供了有限的支持。针对同一用户的多个更新可能同时发生。为解决它们之间的潜在冲突，我们使用应用服务器作为用户请求的同步点。一个用户在任何给定的时间里由独有的服务器提供服务。这样，同一用户请求就可以在应用服务器中以一种完整孤立的方式(Fashion)同步和执行。
存储模式
MTA代理特性附件和大量消息实体，在它们能到达应用服务器之前被存储在Haystack中。然而，元数据，包含索引数据和小的消息体，它们存储在 HBase中并由应用服务器维护着。每个用户的收件箱都是独立于任何其它用户的；用户数据不会在HBase中共享(shared)。每个用户数据存储在 HBase的单独一行里，它包含了以下部分：
![clip_image005]( "clip_image005")
元数据实体和索引
元数据实体包含收件箱对象属性，如文件夹、主题、消息等等。每个实体都存储在自己的HBase列中。不像关系型数据库(RDBMS)，HBase没 有提供用于索引的本地支持 。我们在应用级维护辅助索引(Secondary Indexes)，同样以键/值对的方式存储在分开的列中。
比如，要回答查询“loading unread threads on the second page of the Other folder,” 应用服务器首先搜寻元数据索引以获得符合条件的主题列表，然后取出指定主题的元数据实体，以它们的属性构造响应。
正如我们前面所提到的，缓存和有效的预装载能减少HBase查询量以获得更好的性能。
活动日志
用户邮箱中的任何更新（如发表和删除消息，标记主题为已读等等）会立即以时间的顺序添加到列中，这称为一个活动日志(action log)。小的消息实体也存储在活动日志中。
我们能通过回放(replaying )活动日志的方式构造或恢复用户邮箱的当前状态，我们使用最后活动日志的ID以元数据实体和索引的版本回放。当用户邮箱被加载，应用服务器比较元数据版本 和最后活动日志ID，如果元数据版本滞后(lags behind)则更新邮箱内容。
活动日志存储在应用级带来极大的灵活性：
- 我们能通过回放活动日志无缝切换到一种新的模式并且能通过一个离线的 MapReduce 任务或在线的应用服务器自身生成新的元数据实体和索引。
- 我们能在一个批处理中执行大量HBase异步写以节省网络带宽和减少HBase压缩成本。
- 它是与其它组件交换持久性数据的标准协议。比如，我们通过将活动日志写到记录日志(Scribe log)做应用级的备份。这个移植管道转化用户老的收件箱数据到活动日志并且通过离线MapReduce生成元数据和索引。
搜索索引
为支持全文检索，我们维护着一个从关键字到匹配消息的反向索引。当一个新消息到达时，我们使用 Apache Lucene 去解析和转化它到一个(keyword, message ID, positions)元组(tuples)中，然后以递增的方式加入到 HBase 的列中。每个关键字都拥有自己的列。所有的消息，包括聊天记录，邮件和短信都被实时索引。
dark launch 测试
应用服务器是我们从零开始构建的一个全新软件，因此在将它推向5亿用户前我们需要监控它的性能、可靠性和伸缩性。我们最初开发了一个压力测试机器人 (robot)用来生成模拟请求，但是我们发现这样的结果可能会受到其它一些新因素的影响，如消息长度，不同类型请求的分发，用户活跃度的分布等等。
为了仿真一个真实的产品负荷，我们制作了 dark launch，我们镜像了大约10%用户的实时聊天和收件箱中的信息到测试集群中。Dark launches 帮助我们发现更多性能问题和识别瓶颈。我们也使用它作为一个有说服力的指标来评价我们所做的很多改进。接下来，我们会继续努力为我们的所有用户提供崭新的消息系统。
作者：Jiakai 是 Facebook Messages 开发小组成员。
英文来源：Inside Facebook Messages’ Application Server
