eBay 的数据库分布扩展架构

在过去的 Blog 中, 我(插一嘴:这里的”我” 如果替换成 “Fenng” 似乎有些自恋, 也不是我喜欢的行文语气, 可发现转贴不留名的行为太多了,他大爷的)曾经介绍过 《eBay 的应用服务器规模》 , 也介绍过 《eBay 的数据量》,在这篇文章中提到过 “eBay 购买了 Quest Share Plex 全球 Licence 用于数据复制”,这个地方其实没有说开来。

对于 eBay 这样超大规模的站点来说,瓶颈往往最容易在数据库服务器上产生,必定有一部分数据(比如交易记录这样不容易水平分割的数据)容易带来大量的读操作,而不管用什么存储,能承担的 IO 能力是有限的。所以,如果有效的分散 IO 的承载能力就是一个很有意义的事情。

经过互联网考古学不断挖掘,路路续续又现了一些蛛丝马迹能够多少说明一些问题。客观事实加上主观想象,简单的描述一下。见下图:

ebay_shareplex_F5.jpg

通过 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 的存储架构非常感兴趣,谁/哪里能提供点线索呢?

EOF


18 thoughts on “eBay 的数据库分布扩展架构

  1. Fenng

    bixuan: nginx 不过是个 http proxy ,对于eBay这样的数据库端的负载均衡作用不大

    Reply
  2. Fwolf

    这种读写分离在mysql应用中非常多把
    直接把binlog灌到slave服务器中就成了
    每个slave带n个web。。。规模不太大的情况下一般就够用了

    Reply
  3. Fwolf

    恩,期待着
    另外能否介绍或者想像一下多master的情况?
    简单的mysql双向复制不好用的
    sybase的复制服务器没用过,也没见过太详细的分析
    pgsql好像也有同步的工具,不知好用不

    Reply
  4. cauherk

    我有个问题。
    一个业务系统往往先生成一个订单,然后调用不同模块的应用,这个应用查询这个订单,加入销售信息,最后事务提交。
    如果采用这样的方案,查询和写入分离,那么如何保证session的未提交读的问题?

    Reply
  5. cauherk

    不是我想钻牛角尖,只是我想了解除了本地事务以为,作为SOA的典范的eBuy,想请你更加详细的介绍这种架构如何处理分布式事务。国内现在的特大型应用,特别是移动和电信,都存在单个或者单个RAC的压力过大的问题。

    Reply
  6. Fenng

    把单个事务拆开不是自寻死路麽,逆向思维一把,难道有一个未完成的事务会有N个读取需求麽 ?
    国内的应用不说也罢

    Reply
  7. 代码罐头

    #比如交易记录这样不容易水平分割的数据
    相反,我个人觉得交易记录最容易水平分割
    因为交易单号是唯一性而且可以自定义格式的内容
    完全可以在交易单号中加入数据分片所在组的信息
    或者直接对交易单号进行CRC得出所在分片的数据库组
    BTW:前两天刚仔细看您的blog,这么多关于架构的文章对我来说简直就是蜜罐对蜜蜂的诱惑.
    基本上相关的我都搜集到我的blog了
    如果有幸,希望能和您交换链接.

    Reply
  8. https://me.yahoo.com/a/Vg.6qY1nvIif1gpw1eJfp6vUSkLddw--#4d17f

    这个图是我画的。。。。对于一件在传说中的事情,如果一定要写一篇东西来讲解,只能是这样了。

    Reply
  9. https://me.yahoo.com/a/Vg.6qY1nvIif1gpw1eJfp6vUSkLddw--#4d17f

    是的,我是F5的迷土,那篇文章都是很早以前写的了,是在听说了故事,然后咨询了一些当时参与的人员,然后编出来的。数据库的负载均衡远比想象中的要复杂,需要很多方面来进行配合,F5只是其中的一个环节而已了,重点还是在应用系统的设计和数据库的规划。最近在研究多中心并行处理的相关问题,因此数据库部分又变得非常重要了,希望能多交流。

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *