eBay 的Scalability最佳实践

用什么来衡量一天没有白过? 可能看到一篇好文章能算做一个条件。infoQ 上的这篇 Scalability Best Practices: Lessons from eBay 会让每个架构师都比较激动的。

过几天估计 infoQ 中文站就翻译这篇文章了,所以只记录一点自己的想法好了。在其中的 7 个实战经验中,每一条都值得写篇学习笔记,我比较关注面向 DB 的几条。

水平切分

对于 eBay 这样个头的大 Web 应用,如果数据不能分片,就无从谈及扩展。这个话题我之前描述过一点,文章中提及数据库层的切片要比应用层复杂许多,我想其中最大的一个难点就是不同用户之间的关联数据问题吧,否则就完全可以根据用户范围或者群体划分到不同的 DB 上。现实的应用总是如此复杂,让每个架构师都早生华发啊。

避免分布式事务

其中提到的前 Inktomi 工程师 Eric Brewer 提出的 CAP 定理: Consistency (C), Availability (A), Partition-tolerance (P) ,最多能同时选择两个。三个不能同时实现。对于 eBay ,选择的是 A 和 P,牺牲了一致性,而通过系统的其它手段(比如事件系统)来追回事务的完整程度。BTW: 这次倒是没有提及 BASE :)

虚拟化所有层次

这样做的目的是为了达到编程上的方便以及运营操作的灵活性。通过 eBay 的 O/R 层实现了对数据库的虚拟化。这样应用程序开发者无需关注数据存在哪里的。

Cache

其中提到了 Cache 的应用场景:针对缓慢改变的数据、只读为主的数据、元数据、配置信息和静态数据等。 把握这个原则是很关键的。我个人就看到有病急乱投医的设计者把数据一股脑的扔进 Cache,潜在的麻烦很难消除。

强烈推荐大家直接点过去看一下该文。

补充:关于 BASE。
Basically Availble
Soft-state
Eventual Consistency
ACID_BASE.png
EOF

此文作者:, 位于 Arch 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

  • 卡布里尼

    fenng老大tw上的泡泡话题是不是过于恶了,
    愈发有大粪青年之感受

  • http://www.dbanotes.net/ Fenng

    什么 TW ? TechWeb 么?
    我好像没搞过类似的什么话题

  • http://www.orawh.com wanghai

    这次这篇Best Practices非常有价值,比以前看到的都震撼

  • HiugongGwok

    啊!被抢先了。我赶紧把这篇翻译出来吧,争取6月2日完成。
    说是要打听一下你们家的架构却一直没动手,行动力真是太低了,抱歉呐。

  • littlez

    我们的切片没那么复杂的吧 最起码我看到的原理还是很简单的哦