深入 Facebook 消息应用服务器,互联网营销

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:   要点:Facebook 统一消息系统(邮件、短信、聊天、消息等);用 HBase 作为后端存储设施,每个用户数据存储在 HBase 的单独一行里,每个实体(文件夹、主题、消息等等)都存储在自己的HBase列中;涉及 HayStack 图片处理基础设施;使用 Apache Lucene 维护反向索引列表;镜像了大约 10% 用户的实时聊天和收件箱中的信息到测试集群中,并通过 dark launch 进行测试。

  要点:

  1. Facebook 统一消息系统(邮件、短信、聊天、消息等);
  2. 用 HBase 作为后端存储设施,每个用户数据存储在 HBase 的单独一行里,每个实体(文件夹、主题、消息等等)都存储在自己的HBase列中;
  3. 涉及 HayStack 图片处理基础设施;
  4. 使用 Apache Lucene 维护反向索引列表;
  5. 镜像了大约 10% 用户的实时聊天和收件箱中的信息到测试集群中,并通过 dark launch 进行测试。

clip_image001

  Facebook Messages 是我们曾经所创建的最具技术挑战性的一个代表产品。

  当我们发布Facebook Messages 时所提到的是我们需要打造一个专门的应用服务器来管理其基础架构。

  我们最近讨论了消息后台和我们如何处理所有来自 email, SMS, Facebook Chat 和 Inbox 的通信。

  今天我们将深入消息应用服务器的核心。

  应用服务器的业务逻辑

  应用服务器集成了众多Facebook服务和保护(shields)来自各种终端的复杂性。它提供了一个简单接口方便客户端进行标准消息处理,包括:创建、读取、删除、更新消息和收件箱。

  下面是每一部分的流程。

  当创建一个新消息或回复消息时,应用服务器代表发送者传递消息到收件人。如果收件人是通过其邮件地址,则服务器通过HayStack获得附件(如果有的话),构造HTML主体,并创建一个RFC2822消息。

  输出流 
clip_image002

  当消息发送给用户时,如果地址是一个回复处理,服务器将从存在的邮件地址和传递的输入消息中获得正确收件人的信息。服务器最终将消息传递到用户邮箱,运行所有必要的预处理和后期处理过程,并决定基于多个信号的文件夹和主题的消息路由。

输入流 
clip_image003  当读取消息时,服务器取得有关用户邮箱的多个统计,如容量;消息、主题和回复数;朋友的数量等。同时也获得文件夹相关统计和属性,各种搜索条件的主题列表(文件夹,属性,作者,关键字等等),主题属性和这个主题的其它消息。

  当删除消息时,服务器标记要删除的消息和主题。一个离线任务具体清除消息内容。

  当更新消息和主题时,服务器改变消息或主题属性,如读取和到达状态,标签等等。同时也处理多个用户对主题的订阅和取消订阅的请求。 
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  元数据实体和索引

  元数据实体包含收件箱对象属性,如文件夹、主题、消息等等。每个实体都存储在自己的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

目录
相关文章
|
3月前
|
弹性计算 关系型数据库 数据库
阿里云服务器ECS是什么?ECS应用场景、租用流程及使用教程整理
阿里云ECS(弹性计算服务)是性能稳定、弹性扩展的云计算服务,支持多种处理器架构和实例类型,适用于网站托管、开发测试、数据存储、企业服务、游戏多媒体及微服务架构等场景。提供从注册、配置到部署、运维的完整使用流程,助力用户高效上云。
|
4月前
|
存储 分布式计算 安全
阿里云服务器ECS实例选型参考:场景适配、应用推荐
选择阿里云服务器ECS实例之前,需要结合性能、价格、工作负载等因素,做出性价比与稳定性最优的决策。对于很多新手用户来说,在初次购买阿里云服务器的时候,面对众多实例规格往往不知道如何选择,因为云服务器实例规格不同,价格也不一样,性能表现更是千差万别。因此,在购买阿里云服务器ECS实例之前,需要结合性能、价格、工作负载等因素,做出性价比与稳定性最优的决策。本文将通过一些常见的选型场景推荐,为大家详细介绍阿里云服务器实例选型的最佳实践,便于大家在选择云服务器实例规格时做个参考。
|
5月前
|
开发框架 人工智能 Java
破茧成蝶:阿里云应用服务器让传统 J2EE 应用无缝升级 AI 原生时代
本文详细介绍了阿里云应用服务器如何助力传统J2EE应用实现智能化升级。文章分为三部分:第一部分阐述了传统J2EE应用在智能化转型中的痛点,如协议鸿沟、资源冲突和观测失明;第二部分展示了阿里云应用服务器的解决方案,包括兼容传统EJB容器与微服务架构、支持大模型即插即用及全景可观测性;第三部分则通过具体步骤说明如何基于EDAS开启J2EE应用的智能化进程,确保十年代码无需重写,轻松实现智能化跃迁。
447 41
|
2月前
|
存储 弹性计算 运维
阿里云服务器全解析:ECS是什么、应用场景、租用流程及优缺点分析
阿里云ECS(Elastic Compute Service)是阿里云提供的高性能、高可用的云计算服务,支持弹性扩展、多样化实例类型和多种计费模式。适用于网站搭建、数据处理、运维测试等多种场景,具备分钟级交付、安全可靠、成本低、易运维等优势,是企业及开发者上云的理想选择。
373 5
|
8月前
|
搜索推荐 关系型数据库 分布式数据库
PolarDB 开源基础教程系列 7.3 应用实践之 精准营销场景
本文介绍了基于用户画像的精准营销技术,重点探讨了如何通过标签组合快速圈选目标人群。实验分为三部分: 1. **传统方法**:使用字符串存储标签并进行模糊查询,但性能较差,每次请求都需要扫描全表。 2. **实验1**:引入`pg_trgm`插件和GIN索引,显著提升了单个模糊查询条件的性能。 3. **实验2**:改用数组类型存储标签,并结合GIN索引加速包含查询,性能进一步提升。 4. **实验3**:利用`smlar`插件实现近似度过滤,支持按标签重合数量或比例筛选。
162 3
|
3月前
|
Java Linux 网络安全
Linux云端服务器上部署Spring Boot应用的教程。
此流程涉及Linux命令行操作、系统服务管理及网络安全知识,需要管理员权限以进行配置和服务管理。务必在一个测试环境中验证所有步骤,确保一切配置正确无误后,再将应用部署到生产环境中。也可以使用如Ansible、Chef等配置管理工具来自动化部署过程,提升效率和可靠性。
353 13
|
5月前
|
安全 应用服务中间件 网络安全
从零(服务器、域名购买)开始搭建雷池WAF到应用上线简明指南
本文详细介绍了基于雷池WAF的网站防护部署全流程,涵盖服务器与域名准备、WAF安装配置、网站接入设置及静态文件站点搭建等内容。通过最低1核CPU/1GB内存的服务器配置,完成Docker环境搭建、雷池一键安装及端口设置,实现域名解析、SSL证书配置和防护策略优化。同时支持301重定向与HTTP到HTTPS自动跳转,确保访问安全与规范。最后还提供了使用静态文件搭建网站的方法,帮助用户快速构建具备基础WAF防护能力的网站系统。
从零(服务器、域名购买)开始搭建雷池WAF到应用上线简明指南
|
6月前
|
搜索推荐 数据挖掘 数据安全/隐私保护
频率派与贝叶斯统计在营销组合建模中的应用比较:隐私优先时代的方法选择
营销组合建模(MMM)是量化营销渠道贡献的核心工具,在数字营销进入隐私优先时代后焕发新生。文章探讨了频率派与贝叶斯统计学在MMM中的应用,前者实现简单、结果直观,适合数据充足场景;后者能整合先验知识、量化不确定性,适应复杂和数据稀缺情况。两者各有优劣,选择需结合业务需求与数据条件。贝叶斯方法在隐私保护趋势下尤为重要,为未来营销分析提供新思路。
182 47
频率派与贝叶斯统计在营销组合建模中的应用比较:隐私优先时代的方法选择
|
5月前
|
关系型数据库 MySQL Linux
购买阿里云服务器选择应用镜像和系统镜像区别,哪个好?
在阿里云购买服务器时,选择应用镜像还是系统镜像需根据需求与技术能力决定。应用镜像适合快速部署、无需环境配置的场景,如建站或测试;系统镜像则提供更高灵活性,适合自定义开发和企业级服务。两者各有优劣:应用镜像操作简单但版本可能较旧,系统镜像可控性强但需手动配置。建议新手优先使用应用镜像,技术用户可选系统镜像以优化性能。
|
6月前
|
开发框架 人工智能 Cloud Native
破茧成蝶:阿里云应用服务器让传统J2EE应用无缝升级AI原生时代
一场跨越20年的技术对话:在杭州某科技园的会议室里,一场特殊的代码评审正在进行。屏幕上同时展示着2005年基于WebLogic开发的供应链系统和2025年接入DeepSeek大模型的智能调度方案——令人惊叹的是,二者的核心业务代码竟保持着惊人的一致性。"我们保住了20年积累的238个核心业务对象,就像修复传世名画时保留了每一笔历史痕迹。"企业CTO的感慨,揭开了阿里云应用服务器助力传统系统智能化转型的奥秘。
135 13

热门文章

最新文章