http://blog.csdn.net/starxu85/archive/2008/02/28/2126222.aspx
在過去的 Blog 中, 我(插一嘴：這裏的"我" 如果替換成 "Fenng" 似乎有些自戀, 也不是我喜歡的行文語氣, 可發現轉貼不留名的行爲太多了,他大爺的)曾經介紹過 《eBay 的應用服務器規模》 , 也介紹過 《eBay 的數據量》，在這篇文章中提到過 "eBay 購買了 Quest Share Plex 全球 Licence 用於數據複製"，這個地方其實沒有說開來。
對於 eBay 這樣超大規模的站點來說，瓶頸往往最容易在數據庫服務器上產生，必定有一部分數據(比如交易記錄這樣不容易水平分割的數據)容易帶來大量的讀操作，而不管用什麼存儲，能承擔的 IO 能力是有限的。所以，如果有效的分散 IO 的承載能力就是一個很有意義的事情。
經過互聯網考古學不斷挖掘，路路續續又現了一些蛛絲馬跡能夠多少說明一些問題。客觀事實加上主觀想象，簡單的描述一下。見下圖：
通過 Quest 公司的 Share Plex 近乎實時的複製數據到其他數據庫節點，F5 通過特定的模塊檢查數據庫狀態，並進行負載均衡，IO 成功的做到了分佈，讀寫分離，而且極大的提高了可用性。F5 真是一家很有創新性的公司，雖然從這個案例來說，技術並無高深之處，但方法巧妙，整個方案渾然一體。
F5公司專門爲Oracle 9i 數據庫開發了專用的健康檢查模塊，通過調用F5專有的擴展應用校驗(EAV)進程，F5能夠隨時得到Oracle 9i數據庫的應用層服務能力而不是其他的負載均衡設備所採用的 ICMP/TCP 層進行健康檢查。
這個圖來自一篇《F5助力eBay數據庫服務器負載均衡》的軟文，真是一篇很好的軟文，國外恐怕不會出現這樣"含金量"極高的東西。
當然，這個技術架構可不算便宜。Quest 的 Share Plex License 很貴，而且，對於每個結點來說，都需要數據庫 License 與硬件費用。但優點也很多：節省了維護成本; 數據庫層面的訪問也能做到 SOA; 高可用性。
國內的一些廠商比較喜歡給客戶推存儲級別的解決方案。通過存儲底層複製來解決數據分佈以及災備問題。這個思路似乎太傳統了，對於互聯網企業來說多少有點過時。
BTW: 對 Amazon 的存儲架構非常感興趣，誰/哪裏能提供點線索呢?