日600亿消息,月4.65亿用户——WhatsApp的Erlang世界[架构设计](最新版)
来自 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连接到瞬态离线存储,用户之间的消息传输通过后端系统控制。
By admin
read more