日600亿消息，月4.65亿用户——WhatsApp的Erlang世界[架构设计]（最新版）

By admin

- One minute read - 191 words

来自 High Scalability。相较 上篇，这篇内容更新、更全。 译文 a

【编者按】在之前我们有分享过HighScalability创始人Tod Hoff总结的 WhatsApp早期架构，其中包括了大量的Erlang优化来支撑单服务器200万并发连接，以及如何支撑所有类型的手机并提供一个完美的用户体验。然而时过境迁，两年后WhatsApp又是如何支撑10倍于之前的流量，以及应用的飞速扩展，这里我们一起看Tod带来的总结。以下为译文：

两年内的飞跃

天价应用当下的规模显然不能与两年前同日而语，这里总结了一些WhatsApp两年内发生的主要变化：

**1. **从任何维度上都可以看到WhatsApp的巨变，但是工程师的数量却一直未变。当下，WhatsApp有更多的主机、更多的数据中心、更多的内存、更多的用户以及更多的扩展性问题，然而最引以为豪的却是那支10人工程团队——每个工程师平均负责4000万个用户。当然，这也是云时代的胜利：工程师只负责软件的开发，网络、硬件及数据中心运维全部假手于人。

**2. **在之前，面对负载的激增，他们必须让单服务器支撑尽可能多的连接数，但是现在他们已经步出了那个时代。当然，基于总体成本的控制，他们仍然需要控制主机的数量并让SMP主机更效率的运行。

**3. **瞬时的好处。鉴于现在的架构已经囊括多媒体、图片、文本、音频，无需保存这些大体积格式的信息让系统大大的简化，架构的重心被放在吞吐量、缓存以及分片等。

**4. **Erlang的世界。即使他们打造的仍然是一个分布式系统，遇见的问题也大同小异，但是从始至终都在说Erlang确实值得称道。

**5. **Mnesia，这个Erlang数据库似乎已成为他们问题的主要来源。因此，不得不怀疑一味的紧抓Erlang会不会比较盲目，是否有其他更好的替代方案。

**6. **如此规模下问题之多你可以想象。海量连接数的保持、队列因优先级操作变得太长、计时器、不同负载下的代码表现问题、高负载下高优先级消息得不到处理、一个操作被另一个操作意外打断、故障导致的资源问题以及不同用户平台的兼容性等，巨型架构的打造绝非一朝一夕。

**7. **Rick的发现和处理问题能力让人赞叹，也可以说是吃惊。

Rick的分享总是非常精彩，他乐于分享许多细节，其中有许多只能在生产环境出现。下面是他 最新分享 总结：

统计

  • 月4.65亿用户

  • 平均每日接收190亿消息，发送400亿消息

  • 6亿张图片，2亿条语音，1亿段视频

  • 峰值期间1.47亿的并发连接数——电话连接到系统

  • 峰值期间每秒23万次登陆操作——手机上线及下线

  • 峰值期间每秒32.4万信息流入，71.2万的流出

  • 约10个工程师致力于Erlang，他们肩负了开发与运维

  • 节日的峰值

  • 平安夜流出达146 Gb/s，相当多的带宽用于服务手机

  • 平安夜视频下载达3.6亿次

  • 新年夜图片下载约20亿（46 k/s）

  • 新年夜有张图片下载了3200万次

堆栈

  • Erlang R16B01（打了自己的补丁）
  • FreeBSD 9.2
  • Mnesia（数据库）
  • Yaws
  • 使用了SoftLayer云服务和实体服务器

硬件

  • 大约550个服务器+备份

  • 150个左右的Chat服务器（每个服务器处理大约100万的手机、峰值期间1.5亿的连接）

  • 250个左右的多媒体信息服务器

  • 2x2690v2 Ivy Bridge 10-core（总计40的超线程技术）

  • 数据库节点拥有512GB的内存

  • 标准计算节点搭载64GB内存

  • SSD主要用于可靠性，存储资源不足时还用于存储视频

  • Dual-link GigE x2（公共的面向用户，私有的用于后端系统）

  • Erlang系统使用的核心超过1.1万个

系统概况

  • 独爱Erlang

  • 非常棒的语言，适合小工程团队。

  • 非常棒的SMP可扩展性。可以运行高配的主机，并且有益于减少节点。运维复杂性只与节点数有关，而不是核心数。

  • 可以飞快的更新代码。

  • 扩展性就像扫雷，但是他们总可以在问题爆发之前发现并解决。世界级事件相当于做系统的压力测试，特别是足球赛，会带来非常高的峰值。服务器故障（通常是内存）、网络故障以及差的软件的推送都考验着系统。

  • 传统的架构

  • 手机客户端连接到MMS（多媒体）

  • Chat连接到瞬态离线存储，用户之间的消息传输通过后端系统控制。

  • Chat连接到数据库，比如Account、Profile、Push、Group等。

  • 发送到手机的消息

  • 文本消息

  • 通知：群组消息，个人简介照片改变等

  • 状态消息：输入状态、离开状态、在线或离线情况等

  • 多媒体数据库

  • 内存Mnesia数据库使用大约2TB的RAM，跨16个分片存储180亿条记录。

  • 只存储正在发布的消息和多媒体，但是在多媒体发布时，会将信息储存在数据库中。

  • 当下单服务器只运行100万的并发连接，而在两年前这个数字是200万，因为现在服务器要做的事情更多了：

  • 随着用户量的增多，WhatsApp期望每个服务器上预留更多的空间以应对峰值。

  • 许多过去不是运行在这个服务器上的功能现在被移到上面，因此服务器更忙了。

解耦

  • 隔离瓶颈，让之不会存在整个系统中

  • 紧耦合会导致相继故障

  • 前端系统和后端系统首先要分离

  • 隔离一切，让组件间不会存在影响。

  • 正在解决问题时，保持尽可能多的吞吐量。

  • 异步处理以最小化吞吐量延时

  • 当延时不可预知及在不同点存在时，异步可以尽可能的保证吞吐量。

  • 解耦可以让系统运行尽可能的快。

  • 避免HOL阻塞

  • 线头阻塞是首位处理会饿死队列中其他项目。

  • 分离读和写队列。特别是在表格上执行事务，写入方面的延时不会影响读取队列，通常情况下读的速度会很快，因此任何阻塞都会影响读性能。

  • 分离节点内部队列。如果节点或者网络连接的节点出现问题，它可能会阻塞应用程序中其他任务。因此，发往不同节点的消息会分配不同的进程（Erlang中的轻量级并发），因此只有当消息发送给问题节点时才会做备份，这将允许消息自由的传输，问题被隔离开来，给Mnesia打补丁以保证async_dirty级响应时间。App发送消息后就会被解耦，因此当一个节点发生故障时，不会导致负载问题。

  • 在不确定延时场景下使用FIFO模型。

  • Meta Custering

  • 本节出现在讲话的第29分钟，不幸但是，信息量不大。

  • 需要一种方法来控制单集群体积，并允许他跨很长距离。

  • 建立wandist，基于gen_tcp的分布式传输，由许多需要相互通信的节点组成。

  • 1个基于pg2的透明路由层，建立一个单跳路由调度系统。

  • 举个例子：两个数据中心的两个主集群，位于两个不同数据中心的两个多媒体集群，以及两个数据中心间一个共享的全局集群，他们之间都使用wandist进行连接。

  • 例子

  • 使用async_dirty来避免Mnesia事务耦合，大部分情况下不会使用事务。

  • 只在从数据库中恢复时才使用call，其他情况下都使用cast来维持异步模型。在Erlang，消息队列会因等待handle_call响应而造成阻塞，handle_cast不会造成阻塞是因为它不关注结果。

  • Call使用超时而不是监视，减少远端进程竞争以及分发时传输的数据。

  • 如果只是想追求最好的交付能力，为cast使用nosuspend。这样会阻止节点受到下游问题影响——不管是节点失败还是网络问题（在这些情况下，发送数据缓冲池会备份到发送节点上），进程发送的开始指令会被调度系统挂起，从而造成了相继故障——大家都在等待，却没有操作正在被处理。

  • 使用大的发送缓冲器，从而降低收来自网络和下游系统的影响。

并行

  • 任务分配

  • 需要在1.1万个核心上分配任务

  • 始于单线程的gen_server，然后建立了一个gen_factory负责多节点之间的任务传递。

  • 在负载达到了一定程度，调度过程本身就变成了瓶颈，不仅仅是执行时间问题。

  • 因此建立一个gen_industry，位于gen_factory之上，从而并行的摄入所有输入，并且有能力立刻给工作节点分配。

  • 工作节点的寻址类似数据库通过key查找，因此这里存在不确定延时，比如IO，所以为了避免线头阻塞，这里使用了一个FIFO模型。

  • 分割服务

  • 在2到32间进行分割，大部分服务都被分割成32个。

  • pg2 addressing，分布式进程组，用于集群上的分片寻址。

  • 节点进行主从设置，用于容灾。

  • 限制访问单ets或者mnesia进程的数量到8，这会让锁争用处于控制当中。

  • Mnesia

  • 因为没有使用事务去保证一致性，他们使用一个进程对一个节点上的记录进行连续访问。哈希到一个分片，会映射到1个mnesia fragment，最后会被调度到1个factory，随后是节点。因此，对每个单记录的访问都会被转换成一个独立的Erlang进程。

  • 每个mnesia fragment都只能在1个节点上的应用程序等级进行读取，这样复制流只需要在一处进行。

  • 一旦节点间存在复制流，分片的更新速度上就会存在瓶颈。他们给OTP打补丁以实现多个事务管理器，用以实现async_dirty，从而记录可以并行的进行修改，这将产生更多的吞吐量。

  • 打补丁允许Mnesia库直接被分割到多个库上，这就意味着它可以写多个驱动，这么做可以直接提升磁盘的吞吐量。这里存在的问题是Mnesia达到峰值，通过多个磁盘来分摊IO，而为了进一步提升可扩展性及性能，甚至会加入SSD。

  • 将Mnesia“island”缩减到2个，每个“island”都是一个Mnesia集群。因此在表格被分割成32份时，将会有16个“island”支撑一个表格。从而，他们可以进行更好的schema operation，因为只需要修改两个节点。在同时打开1或2个节点时，可以减少加载时间。

  • 通过设置警报快速处理Mnesia中的网络分片，让它们继续保持运行，然后手动的调节将它们整合。

优化

  • 在峰值情况下，离线存储系统曾是1个非常大的瓶颈，无法更快的将消息推送到系统。

  • 每条消息都被用户快速的读取，60秒内完成50%。

  • 添加一个回写缓存，这样消息就可以在写入文件系统之前被交付，缓存命中率达98%。

  • 如果IO系统因为负载而阻塞，缓存会对消息交付起到额外的缓冲作用，直到IO系统恢复。

  • 给BEAM（Erlang VM打补丁）以实现异步文件IO来避免线头阻塞问题，在所有异步工作线程上轮训文件系统端口请求，在大型mailbox和缓慢磁盘的情况下可以缓解写入。

  • 让大型的mailbox远离缓存，有些用户加入了大量的组，每小时收入数千消息。他们会影响整个缓存，并让处理变慢。将它从缓存中驱除。需要注意的是，不成比例的大型用户处理是每个系统都存在的问题，其中包括Twitter。

  • 使用大量的fragments降低mnesia表格的访问速度

  • 账户表格被分割成512份打入“island”，这就意味着用户和这512个分片间存在一个稀疏映射，大部分的fragments都是空的和空闲的。

  • 主机数量翻倍，但是吞吐量降低。记录访问变慢的原因是当目标为7时，哈希链的大小超过了2K。

  • 这里存在的一个问题是哈希模式会导致建立大量的空bucket，有些甚至会非常长。双线的变化解决了这个问题，并将性能从4提升到1。

补丁

  • 计时器轮上的竞争，当1个主机的连接数达到几百万，同时每个链接上的手机发生变化时就会建立或重置计时器，从而导致了每秒数十万的计时器。计时器轮上的锁则是竞争的主要来源，解决方法就是建立多个计时器轮。
  • mnesia_tm 是个非常大的选择循环，因此虽然负载未满，也可能会造成事务的积压，打补丁以收取事务流并且保存以作稍后处理。
  • 添加多个mnesia_tm async_dirty发送者
  • 存在许多的跨集群操作，因此mnesia最好从附近的节点加载。
  • 给异步文件IO加入循环调度。
  • 使用ets哈希开防止w/ phash2的同时发生。
  • 优化ets main/name table来应对规模
  • 不要队列mnesia dump，因为队列中存在太多的dumps时，schema ops将不可行。

2月22日的停机

  • 即使做了如此多的努力，停机仍然不可避免，而且发生在了最不应该发生的时候，在被Facebook收购后宕机了210分钟。
  • 负载的变化导致了问题的发生，此次宕机归结于后端系统的路由问题。
  • 路由器造成了一片局域网的瘫痪，造成了集群中大量节点的断开和重连。同时，在节点重连之后，集群出现了前所未有的不稳定状态。
  • 最终，他们不得不停机修复，这种情况在几年内都未出现过。
  • 在检查中，他们发现了一个过度耦合的子系统。在断开和重连时，他们发现pg2在做n^3的消息，消息队列在数秒钟内从0飙升到了400万，为此他们推出了1个补丁。

特性发布

  • 无法模拟如此规模的流量，特别是高峰期间，比如新年的钟声。因此，他们只能缓慢的发布特性，先在小流量下发布，然后迅速迭代直到良好运行，接着再向其他的集群推广。
  • 上线是一个滚动的更新过程。冗余一切，如果他们想做一个BEAM更新，在安装后他们需要一个个的重启集群中的节点然后更新。也存在热补丁的情况，但是很罕见，通常的升级都非常麻烦。

原文连接： How WhatsApp Grew to Nearly 500 Million Users, 11,000 cores, and 70 Million Messages a Second（编译/仲浩 审校/魏伟）