写点什么

要快速伸缩?重新架构吧!

  • 2008-06-25
  • 本文字数:1692 字

    阅读完需:约 6 分钟

虽然经受“/. 效应”的考验常被人拿来说事,但其实 Yahoo! 的首页才是互联网上最繁忙的站点。Lukas Biewald 讲述了他的 FaceStat 网站被 Yahoo!首页上榜之后访问人数急速上升到 100,000,因而不得不快速完成伸缩的故事

星期天早上我坐在厨房里,边看报纸边想着早饭午饭一块儿吃了就在这时候接到了 Chris 的电话。他告诉我他家里的电话有好几通留言,都是说我们的网站 FaceStat 挂了。 FaceStat 是我们 Dolores Labs 用来展示群众资源技术的一个站点,发布一个月以来已经有了一小群追随者。我检查了一下网站的情况,发现它给我返回了 500 错误——10 次请求里大概只有一次能打开真正的页面。于是我登录到应用服务器上,发现磁盘已经满了,log 文件竟然涨到了 20GB!我把 log 文件删了,然后让朋友 Zuzka 查查看我们是不是被 Slashdot 临幸了。

第一反应是建立静态的页面,但他们发现仍不足以在汹涌的潮水中站住脚:

难以置信,我们的 Web 服务器( nginx )连静态页面也没办法可靠地显示……Brendan 发现我们已经达到了系统对最大文件打开数的限制——100,000——因为连接也算是打开文件。

接着团队转向要求主机托管商增加服务器资源,增加缓存,并且开始去除一些功能:

Brendan 忙着安装新的机器,我则开始砍掉系统里所有数据库密集的功能,Chris 负责增加缓存……大概中午 1 点网站重新上线,看起来很稳定。

周一负荷继续增大,于是团队增加了 memcached、监控工具,还把数据库移到了另一台更大的机器上:

现在已经是周二的晚上,原来在一台机器上处理的负载,现在已经增长到了 50 倍,网站看上去有点摇摇欲坠。我们有 6 台应用服务器和一台大型的数据库服务器。Chri 和 Brendan 真是了不起的黑客,现在的工具进步也很了不起。 Slicehost 的伸缩速度正是我们需要的。Amazon 的 S3 负担了所有的图片,虽然响应延迟不甚完美,但单凭我们自己绝对解决不了这种带宽问题。 Capistrano 让我们得以随时随处部署和回滚;git 加上 github 让我们得以争分夺秒地分头行动,再把代码合并到一起做部署。 God 保障服务器运行。 memcached 给了我们出色的缓存,而痛苦非常少(基本上……:))。

Lukas 总结他们在三天里得到的教训:

编写可伸缩的代码然后随着负载增长慢慢地提高,这是一回事;像我们这样在一两天里疯狂地重新架构一个工作中的网站则是截然不同的另一回事。我想现在网站已经是互联网上能排得上号的了,应该不会再有更大规模的流量突然上升……不过如果再发生这样的事情,我已经在这次经历中学到了一些教训:

(1)做好网站的监测。在此之前已经让异常处理程序发送邮件给我们,但异常很多,所以我并不会认真看,而且事情发生的时候我不在线。预先就为这种负载来伸缩网站显然是不合理的,但我们错在不该依靠好心人查出 Chris 的邮件地址和家庭电话去告诉他……

(2)不要畏惧放上一个错误页面。当我们放上一个页面说明网站挂了并解释原因之后,收到了很多兴高采烈的用户来信。而当我们的网站勉强运行,不但延迟严重还断断续续地死机的时候,我们收到了很多愤怒的用户来信。不切实际的想法让我们在网站真正准备好之前一两个小时就把它上了线。

(3)静态生成的首页是件好东西,memcached 是件了不起的东西。

Brendan O’Connor 在一篇后续文章中谈到了 FaceStat 应用背后的技术:

是的,我们基本上是用 Rails。我们实际上用的从 Rails 衍生出来的 Merb ,它的效率更高一些,底下用的是 Thin 。我们发现 Rails 类的平台对于快速打造新网站的原型真是无价之宝。特别是我们启动 FaceStat 的时候完全是当作一个实验品,根本不清楚人们会不会喜欢,而且最初的功能设想和后来实际的情形差别很大。 Chris 这个 Ruby 专家对于我们的团队也是无价之宝:)。

不过,与整体的架构相比,高层的平台实在不算什么:我们如何使用数据库(postgres)、如何缓存(memcached/merb-cache)、如何分摊负载、如何部署新系统(xen/slicehost),这些才是真正有影响的架构议题。FaceStat 是写操作密集的、要执行的统计计算也相当复杂,种种问题都不可小视。但现在我们所服务的用户比原先的负载提高了将近 100 倍,也就是说我们干得还算不错——至少现在!

查看英文原文: Need to Scale Fast? Just Re-Architect it!

2008-06-25 17:271206
用户头像

发布了 225 篇内容, 共 66.8 次阅读, 收获喜欢 51 次。

关注

评论

发布
暂无评论
发现更多内容

3D渲染速度慢,花重金买显卡还是用云渲染更划算

3DCAT实时渲染

实时渲染云

人工智能自然语言处理:N-gram和TF-IDF模型详解

汀丶人工智能

人工智能 自然语言处理 nlp tf-idf N-gram

代码随想录Day18 - 二叉树(五)

jjn0703

PyTorch: 权值初始化

timerring

PyTorch

人工智能大语言模型微调技术:SFT 监督微调、LoRA 微调方法、P-tuning v2 微调方法、Freeze 监督微调方法| 社区征文

汀丶人工智能

LoRa NLP 大模型 LLM模型 年中技术盘点 Freeze微调

chatgpt和文心一言哪个更厉害 | 社区征文

张三丰无极

年中技术盘点

Visual Studio Code错误:Cannot build and debug because the active file is not a C or C++ source file

codists

Visual Studio Code

一个普通程序员如何看待chatgpt大火 | 社区征文

不觉心动

年中技术盘点

Open AI爆火,4个中国版ChatGPT扎堆爆发 | 社区征文

我搬去水星了

年中技术盘点

小设计,大作用——谈谈防腐层的妙用

JAVA旭阳

Java

Ins风韩国美少女【InsCode Stable Diffusion美图活动一期】

繁依Fanyi

学校招生报名小程序开发笔记(一)

CC同学

CnosDB x LangChain: 聊着天来查询时序数据库

CnosDB

开源 时序数据库 CnosDB

WAIC2023丨AI图像内容安全“黑科技”如何助力科技向善发展?

陈橘又青

领导和团队的自主权——《敏捷实战-破解敏捷落地的60个难题》读后感(二)

Bruce Talk

敏捷开发 Agile

Antlr4如何自动解析得到AST而不是ParseTree

canonical

ANTLR 低代码 dsl antlr4

可爱小猫猫【InsCode Stable Diffusion美图活动一期】

繁依Fanyi

明代元素时装小姐姐【InsCode Stable Diffusion美图活动一期】

繁依Fanyi

申请 GPT4.0Key!含详细步骤

石云升

AIGC ChatGPT GPT-4

C语言宏定义中的#和##

芯动大师

从0到1:跑团小程序开发心得笔记

CC同学

2023-07-16:讲一讲Kafka与RocketMQ中零拷贝技术的运用?

福大大架构师每日一题

福大大架构师每日一题

IoTOS-v1.5.3 新增 智能诊断&会话记录导出

开源物联卡管理平台-设备管理

物联网平台 IoT 开源物联网 国产开源 开源项目介绍

Nautilus Chain NautDID NFT 将上主网,Layer3 数字身份时代开启

股市老人

少年侠客【InsCode Stable Diffusion美图活动一期】 | 社区征文

度假的小鱼

Stable Diffusion 年中技术盘点

我与OpenHarmony| 社区征文

坚果

年中技术盘点

要快速伸缩?重新架构吧!_Ruby_Gavin Terrill_InfoQ精选文章