谈谈Facebook的聊天系统架构

今天看到一份 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