轻博客始祖Tumblr:哈希以支撑2.3万Blog请求/秒

2014-8-6 10:20| 发布者: joejoe0332| 查看: 3273| 评论: 0|原作者: 仲浩|来自: CSDN

摘要: Tumblr是目前全球最大的轻博客网站，也是轻博客网站的始祖。当下已有超过1.96亿博客，930亿帖子，每秒2万3千请求。近日，该公司网站可靠性工程师Michael Schenck在HighScalablity上公布了其架构设计。 ...

对比静态分割和一致性哈希

上图显示了每个varnish节点上的变化，对比了使用最佳哈希函数前后

附加思考

节点增长

　　在这两种模型中，节点增长都意味着keyspace转移，因此缓存失效。在一致性哈希模型中，失效key所占的比率更加容易预测。在静态分割模型中，除下做很具体的统计，很难预测到这个百分比。

节点故障

　　通过静态分割，单点故障将导致 1/N的key无法访问，除非你提供一个故障转移机制。HAProxy确实允许你拥有一个备份节点，因此你需要做出决策，是否要为每个key space都做活跃和备份缓存节点设置，或者共享一个备份节点。一个极端意味着你将浪费50%的硬件，另一个（共享备用节点）则意味着两个故障节点就需要备用节点支撑活跃节点的2倍keyspace。

　　通过一致性哈希，节点故障被自动处理。当一个节点被移除后，那么1/N的key会被转移同时无效，然后把这些分配到剩余的活跃几点上。

清理缓存

　　清理请求可以很简单的发送到单独的varnish节点上，那么从多个varnish节点上的清理应该同样简单。取代谨慎的保持proxy和清理同步，将所有清理请求发送到相同的proxy显然更加简单。同时，需要注意的是，拒绝不同IP空间上的清理请求非常重要，这可以防止恶意的批量清理。

学到的知识

有时候，问题的答案比你问题出现的更早。当面对一些扩展性挑战时，不要在那些已经在其他地方攻克过的问题上浪费时间。
保持简单。通过复杂性来解决扩展性问题必然深受其害。
理解你的哈希函数。哈希函数的选择同样至关重要。
Degrade，not fail。让proxy具备监视自己后端到达情况的能力非常必要。如果出现异常，不要停止advertise路由，继续advertise非优先级路由。这种情况下，如果你所有的后端都出了问题，那么你仍然可以显示错误页面。

推荐阅读