206
附录
B
除了像龙卷风摧毁数据中心这样的灾难外,你可能面对的最大的问题就是太多的
访问流量。具有讽刺意味的是,如果你的网站流量超过了网站的处理能力,对网
站运维来说,那将成为你经历过最糟糕的噩梦。你可能幸运地拥有一个遍布全球
的链接都指向的受欢迎的网站内容,或者是发布了一个新的、吸引了比你预想更
多关注的超级功能。这可能和将你的名字印在星光大道上一样令人激动,但是当
这一切真的发生时,你可能就不会觉得如此幸运了。
从容量的观点看,一瞬间的工夫并不能完成太多事情。如果你被托管在公有云中,
可以根据其如何使用而相对快速地添加容量,但是这种方法有局限性。添加服务
器智能解决“我需要更多服务器”的问题。它不能解决在你最不期望的时候出现
的更难的架构性问题。
发现边缘案例的出现并不常见(可能比常规的容量问题更频繁)。以至于以我们
所没有预料到的方式在使我们的基础架构设施遭受重负。例如回到
Flickr
,一个用
户把他的网络摄像机设置为每天的每分钟自动拍摄一张他家后院的照片,并将照
片上传至
Flickr
上,并且把它们用
UNIX
时间戳标记出来。这会引发有趣的数据
库边际效应,因为我们并未预料到会为如此多的照片产生如此多的唯一标记。我
们同样遇见过那些只有很少照片但却为每张照片生成成千标记的用户。这些案例
中的每一个都让我们知道我们的数据库瓶颈在哪里。
环节故障
以下的方法是针对那些最坏情况的场景,当所有其他增加容量的选择都不起作用,
并且从根本上改变基础架构本身是不可能的时候。应该说这种救火的场景是容量
规格化所应该极力避免的;但是有时候它确实是不可避免的。这些技巧和诀窍并
非是万能的,当爆发的访问流量来临并且你的服务器在负载下正要挂掉时,能对
你有所帮助。
优雅地退化和禁用重量级的功能
一种可能的方法就是禁用网站一些重量级功能