科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网服务器频道虚拟化/云计算日600亿消息 月4.65亿用户的WhatsApp世界(下)

日600亿消息 月4.65亿用户的WhatsApp世界(下)

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

两年,流量翻了10倍,月用户增至4.65亿,平均每日接收190亿消息,发送400亿消息,同时还有6亿张图片、2亿条语音、1亿条视频,然而他们依仗的只是1个10人工程团队。

作者:Todd Hoff 来源:CSDN 2014年4月8日

关键字: Erlang 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更新,在安装后他们需要一个个的重启集群中的节点然后更新。也存在热补丁的情况,但是很罕见,通常的升级都非常麻烦。
    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章