本文共 3810 字，大约阅读时间需要 12 分钟。
原贴：http://www.dbanotes.net/database/ebay_database_scale_out.html在过去的 Blog 中, 我(插一嘴：这里的"我" 如果替换成 "Fenng" 似乎有些自恋, 也不是我喜欢的行文语气, 可发现转贴不留名的行为太多了,他大爷的)曾经介绍过 , 也介绍过 ，在这篇文章中提到过 "eBay 购买了 Quest Share Plex 全球 Licence 用于数据复制"，这个地方其实没有说开来。
对于 eBay 这样超大规模的站点来说，瓶颈往往最容易在数据库服务器上产生，必定有一部分数据(比如交易记录这样不容易水平分割的数据)容易带来大量的读操作，而不管用什么存储，能承担的 IO 能力是有限的。所以，如果有效的分散 IO 的承载能力就是一个很有意义的事情。
经过互联网考古学不断挖掘，路路续续又现了一些蛛丝马迹能够多少说明一些问题。客观事实加上主观想象，简单的描述一下。见下图：
通过 Quest 公司的 Share Plex 近乎实时的复制数据到其他数据库节点， 通过特定的模块检查数据库状态，并进行负载均衡，IO 成功的做到了分布，读写分离，而且极大的提高了可用性。F5 真是一家很有创新性的公司，虽然从这个案例来说，技术并无高深之处，但方法巧妙，整个方案浑然一体。
F5公司专门为Oracle 9i 数据库开发了专用的健康检查模块，通过调用F5专有的扩展应用校验(EAV)进程，F5能够随时得到Oracle 9i数据库的应用层服务能力而不是其他的负载均衡设备所采用的 ICMP/TCP 层进行健康检查。
这个图来自一篇《F5助力eBay数据库服务器负载均衡》的软文，真是一篇很好的软文，国外恐怕不会出现这样"含金量"极高的东西。
当然，这个技术架构可不算便宜。Quest 的 Share Plex License 很贵，而且，对于每个结点来说，都需要数据库 License 与硬件费用。但优点也很多：节省了维护成本; 数据库层面的访问也能做到 SOA; 高可用性。
国内的一些厂商比较喜欢给客户推存储级别的解决方案。通过存储底层复制来解决数据分布以及灾备问题。这个思路似乎太传统了，对于互联网企业来说多少有点过时。
BTW: 对 Amazon 的存储架构非常感兴趣，谁/哪里能提供点线索呢?
--EOF--
好文，BTW: 但“有”点也很多...SQL不能有错，语文也不能出错哦！
如果可以试试nginx做代理,采用读写分离~~
ambitear: 已经更正了，谢谢。
bixuan: nginx 不过是个 http proxy ，对于eBay这样的数据库端的负载均衡作用不大
这种读写分离在mysql应用中非常多把
直接把binlog灌到slave服务器中就成了 每个slave带n个web。。。规模不太大的情况下一般就够用了Fwolf, 你说的对
我下一篇 Blog 就是关于 MySQL 的
恩，期待着
另外能否介绍或者想像一下多master的情况？ 简单的mysql双向复制不好用的sybase的复制服务器没用过，也没见过太详细的分析
pgsql好像也有同步的工具，不知好用不
binlog支持不了多少事务的, 别以为mysql有多快.
我有个问题。
一个业务系统往往先生成一个订单，然后调用不同模块的应用，这个应用查询这个订单，加入销售信息，最后事务提交。 如果采用这样的方案，查询和写入分离，那么如何保证session的未提交读的问题？把事务硬生生的拆开 ?
钻这种牛角尖有什么用 ？
不是我想钻牛角尖，只是我想了解除了本地事务以为，作为SOA的典范的eBuy，想请你更加详细的介绍这种架构如何处理分布式事务。国内现在的特大型应用，特别是移动和电信，都存在单个或者单个RAC的压力过大的问题。
把单个事务拆开不是自寻死路麽，逆向思维一把，难道有一个未完成的事务会有N个读取需求麽 ?
国内的应用不说也罢国内也有做的好的，不过，一般都是被厂商忽悠，存储层容灾的比较多。
哈哈，这句"他大爷的”真叫过瘾啊