# 全球范围扩展的 10 个 eBay 秘密 > 原文： [http://highscalability.com/blog/2009/11/17/10-ebay-secrets-for-planet-wide-scaling.html](http://highscalability.com/blog/2009/11/17/10-ebay-secrets-for-planet-wide-scaling.html) 您甚至不必出价，eBay 杰出建筑师 Randy Shoup 就免费提供了有关如何扩展 eBay 的[演示文稿](http://www.hpts.ws/session9/shoup.pdf)。 Randy 在本演示文稿以及本文结尾处列出的其他演讲中做了出色的工作，成为可伸缩性原理的核心。 与关注特定技术堆栈有关，更多的是关于事物如何协同工作的想法。 ### 令人印象深刻的统计 如果您不确定，eBay 很大，有很多：用户，数据，功能和更改... * 全球超过 8900 万活跃用户 * 1.9 亿种商品在 50,000 个类别中销售 * 每天超过 80 亿个 URL 请求 * 每季度数百个新功能 * 每天大约有 10％的项目被列出或终止 * 在 39 个国家/地区提供 10 种语言 * 24x7x365 * 每天 700 亿次读/写操作 * 每天处理 50TB 的新增量数据 * 每天分析 50PB 数据 ### 10 课 该演示文稿很好地解释了每节课，但清单是... 1. **对所有内容**进行分区-如果无法拆分，则无法缩放。 按功能和数据将一切划分为可管理的块。 2. **到处都是异步**-通过事件队列连接独立组件 3. **自动化所有**-组件应自动调整，系统应学习并自我完善。 4. **记住所有故障**-监视所有故障，即使零件开始出现故障也要提供服务。 5. **拥抱不一致**-为需要在 CAP 连续性上使用的每个功能选择，没有分布式事务，可以通过谨慎的操作顺序使不一致最小化，并通过异步恢复和协调最终变得一致。 6. **预期（R）演进**-更改是恒定不变的，可扩展性设计，应逐步部署更改。 7. **依赖性问题**-最小化和控制依赖性，使用抽象接口和虚拟化，组件具有 SLA，消费者负责从 SLA 违规中恢复。 8. **权威**-知道哪些数据是权威的，哪些数据不是权威的，并进行相应的处理。 9. **数据不足-**数据驱动寻找优化机会，预测和建议，因此请保存所有内容。 10. **定制基础结构**-最大限度地利用每种资源。 ### 相关文章 * [eBay 有关高扩展性的帖子](http://highscalability.com/blog/category/ebay) * [可伸缩性最佳做法：来自 eBay 的经验教训](http://www.infoq.com/articles/ebay-scalability-best-practices)，作者 Randy Shoup * [第 109 集：eBay 的架构原则](http://odeo.com/episodes/23259163-Episode-109-eBay-s-Architecture-Principles-with-Randy-Shoup)和 Randy Shoup，[成绩单](http://www.se-radio.net/transcript-109-ebay039s-architecture-principles-randy-shoup) 我喜欢设计大型系统，但是甚至无法想象 50PB 的数据分析。 哇！ 具有讽刺意味的是，我在 eBay 遇到与他们的搜索引擎有关的大规模后端故障的那天碰到了这篇文章。 任何特殊原因，除了在内存引擎中使用 MySQL 的联接等之外，还不包括用于个人化和会话缓存的内存缓存。 @Raj，持久性将是我的猜测，为什么不谈论您提到的 memcache（d）。 “管理不可用和违反 SLA 的行为是..消费者的责任是什么？” 服务提供商是否应该尽一切可能满足 SLA 中的可用性保证？ 我认为当前 SP 在管理可用性方面做得还不够，这可能是由于它们太难/太昂贵了。 对于他们来说，退还您的钱要容易得多（或更糟糕的是，请您重新开始工作）而无需支付巨额罚款。