谈谈Facebook的聊天系统架构

标签: Computer System 高性能Web架构 Facebook | 发表时间:2013-08-12 17:13 | 作者:ideawu
出处:http://www.ideawu.net/blog

今天看到一份 Facebook 公司 2009 年的 PDF, 介绍它的聊天系统架构, 其中的一张图结构非常清晰, 所以我对这张图谈谈我的看法.

Web Tier: 用 PHP 开发, 聊天相关的业务逻辑代码. 如 AJAX 请求, HTML 页面拼接等. 这个模块整个其它的 3 个模块, 向浏览器提供了大部分的聊天接口.

Chatlogger, 用 C++ 开发, 消息的存储服务. 至少向 Web Tier 层提供了消息保存, 聊天历史消息, 最近联系人等基础服务接口.

Presence, 用 C++ 开发, 提供用户在线状态维护服务. 这些服务器会将在线的用户(UID)保存在内存中, 然后接受 Web Tier 的请求, 例如判断某个用户是否在线.

Channel(Comet) Cluster, 用 Erlang 开发, 提供基于浏览器的”Server Push(服务器推)”功能. 是对开源的 Mochiweb 的二次开发. 浏览器会跟 Channel Clusters 进行连接, 当 Web Tier 收到某个用户的消息时, 会通过 Channel Cluster 推送到接收者, 实现网页实时聊天功能.

关于 Web Tier, 其实没有太多的技术可讨论, 因为这主要是业务逻辑, 即使不用 PHP 语言, 用 Python 或者 Java 等都没有问题.

Chatlogger 虽然名字是”日志记录”, 但它不可能是简单的日志记录, 它必须要提供基本的消息服务接口. 而且, 为了存储数亿 Facebook 用户的聊天历史, 必然要涉及到海量数据存储. 这部分 Facebook 曾经用 Cassandra, 后来改为 HBase. Chatlogger 使用 C++ 进行开发是基于性能的考虑, 而且消息存储服务的接口比较固定, 不太可能经常变化.

Presence 维护用户的在线状态, 类似这种服务在网游中比较常见. Presence 服务器使用 C++ 来开发, 也是基于性能的考虑. 如果使用 HTTP + PHP + Memcache/Redis 这样的架构, 一是 PHP 代码执行性能损失很大, 二是 Memcache/Redis 是通用的存储方案, 不适合 Presence 的高性能需求. Presence 在数据全部保存在内存中, 速度快, 设计灵活. 注意, Presence 是一个被动服务器, 它并不主动向外推送消息, 这使得这样的服务器接口非常固定, 独立性很强. Presence 的数据主要来自于 Comet 群集的推送.

Channel(Comet) Cluster 和浏览器保持网络连接. Comet 有通道的概念, 每个用户对应一个通道, 用户会分布在不同的服务器上, 用户每打开一个新的浏览器标签, 就会同服务器建立一个新的网络连接, 但都是连到同一个通道. Comet 服务器是基于开源的 Erlang 服务器 Mochiweb 进行二次开发. 在身份验证和安全方面, 通道的建立是由 Web Tier 进行控制的, 这样如果用户没有在业务逻辑层经过相应的验证, 就直接连接 Comet 服务器, 它是会被拒绝的. 另外, Comet 服务器会在自己的内存中先维护一份在线用户列表, 然后定期更新到 Presence 服务器, 这也是二次开发的原因. 如果 Comet 服务器不自己先缓存一份在线用户列表, 那么用户频繁上线下线都立即通知 Presence 的话, 压力会非常大.

架构已经很清晰, 但要应用起来, 代码的开发是必不可少的. 当然, 不同的技术团队会根据技术情况进行取舍. 例如消息存储使用 MySQL, Presence 使用基于 Web 容器架构的技术来开发, 而 Comet 模块可以使用 nginx-push-stream. 不过, 仅仅依靠整合开源系统而不做二次开发, 不可能解决大问题.

PDF 文件可以在这里下载: http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf

Related posts:

  1. Facebook 网站架构
  2. nginx-push-stream-module 笔记
  3. 使用 Channel 进行可靠传输
  4. Redis被bgsave和bgrewriteaof阻塞的解决方法
  5. SSDB 使用 jemalloc

相关 [facebook 聊天 系统架构] 推荐:

谈谈Facebook的聊天系统架构

- - idea's blog
今天看到一份 Facebook 公司 2009 年的 PDF, 介绍它的聊天系统架构, 其中的一张图结构非常清晰, 所以我对这张图谈谈我的看法.. Web Tier: 用 PHP 开发, 聊天相关的业务逻辑代码. 如 AJAX 请求, HTML 页面拼接等. 这个模块整个其它的 3 个模块, 向浏览器提供了大部分的聊天接口..

Facebook 的系统架构

- Ivan - 博客园新闻频道
  来源:http://www.quora.com/What-is-Facebooks-architecture (由Micha?l Figuière回答).   根据我现有的阅读和谈话,我所理解的今天Facebook的架构如下:. Web 前端是由 PHP 写的. Facebook 的 HipHop [1] 会把PHP转成 C++并用 g++编译,这样就可以为模板和Web逻贺业务层提供高的性能.

HBase 系统架构

- - 博客园_首页
HBase是Apache Hadoop的数据库,能够对大型数据提供随机、实时的读写访问. HBase的目标是存储并处理大型的数据. HBase是一个开源的,分布式的,多版本的,面向列的存储模型. 5 可在廉价PC Server搭建大规模结构化存储集群. HBase是Google BigTable的开源实现,其相互对应如下:.

Facebook与Skype合作推视频聊天功能

- Jakey - cnBeta.COM
据国外媒体报道,Facebook今日在新产品新闻发布会上宣布,与Skype合作推出视频聊天新功能. 近期业内一直有关于Facebook推视频聊天的传言,今日Facebook证实了这一消息. Facebook用户目前可以试用这一功能. 用户在浏览朋友主 页时,可在“消息”按钮旁边看到“视频通话”按钮.

Facebook推出手机聊天应用 欲取代短信

- xcv58 - 互联网的那点事
8月10日凌晨消息,Facebook今天在iPhone和Android应用商店中推出独立聊天应用Facebook Messenger,界面与网络版Facebook消息功能类似. 点开Messenger,你会看到最近在Facebook上进行的所有对话和消息. 点击消息即可直接回复,如果在应用没打开时 收到信息,将会受到推送通知.

Digg.com 的系统架构

- - 标点符
在过去的几年间,我们一直致力于重构Digg的架构,现在我们称之为“Digg V4”.本文我们将全面介绍Digg的使用的系统和技术. 首先,我们来看下Digg给大众用户提供的服务吧:. 人们通过浏览器或者其他应用来访问这些Digg服务. 一些有Digg账户的用户,可以得到“我的新闻”. 每位用户可以得到的我们称之为“热门新闻”.

系统架构师JD

- - CSDN博客架构设计推荐文章
国内大型的物流企业,专业从事国内公路运输和航空运输代理. Foss项目的架构设计,包括需求分析,模块设计,系统结构设计,关键功能的开发,技术难题的解决,对团队质量输出的把控等等. 1、熟悉WebLogic/Websphere/JBoss等一个以上大型应用服务器,熟悉Linux及应用服务器集群. 2、 具有丰富J2EE架构设计经验,具有大型基于J2EE体系结构的项目规划、系统架构设计、开发经验.

Android 系统架构分析

- - CSDN博客移动开发推荐文章
Android:开源的 Linux + Google 的封闭软件 + 私有的基带 + 运营商锁定 = 开放的 Android 手机. iPhone:开源的 BSD + 苹果的闭源软件 + 私有的基带 + 运营商锁定 = 封闭的苹果 iPhone. 一个平庸的应用商店,开发者依靠广告赚钱,商店并非独此一家,用户找不到好软件.

twitter系统架构分析

- - 企业架构 - ITeye博客
twitter系统架构分析. (一)twitter的核心业务. twitter的核心业务,在于following和be followed:. (1)following-关注. 进入个人主页,会看到你follow的人发表的留言(不超过140个字),这是following的过程;. (2)followed-被关注.