# 全球范圍擴展的 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 在管理可用性方面做得還不夠，這可能是由于它們太難/太昂貴了。 對于他們來說，退還您的錢要容易得多（或更糟糕的是，請您重新開始工作）而無需支付巨額罰款。