P.Linux Laboratory

本文内容遵从CC版权协议, 可以随意转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://www.penglixun.com/database/ebay_database_arch_analyze.html

(荣耀属于Fenng和F5)

一、 eBay的数据量^[]

作为电子商务领头羊的eBay公司，数据量究竟有多大？eWeek的报道中，eBay的存储主管Paul Strong对数据量做了一些介绍，这些数据可以作为参考。

1. 站点处理能力

A. 平均每天的PV超过10亿

B. 每秒钟交易大约1700美元的商品

C. 每分钟卖出一辆车

D. 每秒钟卖出一件汽车饰品或者配件

E. 每两分钟卖出一件钻石首饰

F. 6亿商品，2亿多注册用户

G. 超过130万人把在eBay上做生意看作是生活的一部分

在这样高的压力下，可靠性达到了99.94%，也就是说每年只有5个小时多一点的时间服务不可用。从业界消息来看，核心业务的可用性要比这个还要高。

数据存储工程组控制着 eBay的2PB (1Petabyte=1000Terabytes) 可用空间。这是一个什么概念，对比一下 Google 的存储就知道了。每周就要分配 10T 数据出去，稍微算一下，一分钟大约使用 1G 的数据空间。

2. 计算能力

eBay使用一套传统的网格计算系统。该系统的一些特征数据：

A. 170 台 Win2000/Win2003 服务器；、

B. 170 台 Linux (RHES3) 服务器；、

C. 三个 Solaris 服务器：

为QA构建与部署 eBay.com；、

编译优化 Java / C++ 以及其他 Web 元素；、

D. Build整个站点的时间：

过去是10个小时，现在是30分钟；、

E. 在过去的2年半，有200万次Build，很可怕的数字

3. 存储硬件与软件

每个供货商都必须通过严格的测试才有被选中的可能，这些厂家或产品如下：

A. 交换机：Brocade

B. 网管软件：IBM Tivoli

C. NAS：Netapp（占总数据量的5%，2P*0.05，大约100T）

D. 阵列存储：HDS （95%，EMC在eBay是出局者）

E. 负载均衡与Failover：Resonate

F. 搜索功能：Thunderstone indexing system

G. 数据库软件：Oracle，大多数DB都有4份拷贝

H. 数据库服务器：Sun E10000

I. 数据备份：Share Plex，购买的全球Licence用于数据复制

4. 架构

A. 高分布式

B. 拍卖站点是基于Java的，搜索的架构是用C++写的

C. 数百名工程师进行开发，所有的工作都在同样的代码环境下进行

5. 其他信息

A. 集中化存储应用程序日志

B. 全局计费：实时的与第三方应用集成（eBay的PayPal）

C. 业务事件流：使用统一的高效可靠消息队列，并且使用Cookie-cutter模式用于优化用户体验

二、 eBay 的应用服务器规模

从Oracle的一份白皮书《The eBay Global Platform and Oracle 10g JDBC》^[]中可以了解到，在2004年的时候，eBay的应用服务器采用了IBM Web Sphere，部署在WinNT上，硬件是Intel双CPU奔腾服务器。服务器数量是2400台。在第一部分中可以知道，eBay 的是集中式处理Log的，每天会有2T的Log数据产生，现在只会更多。这些应用服务器分成不同的组，通过一个统一的DAL(Database Access Layer)逻辑层访问135个数据库节点。

这篇白皮书已经发布了两年，相信在这两年的时间里，服务器规模又会扩大了许多。

eBay的SOA架构V3示意图如下：

三、 eBay的数据库分布扩展架构^[]

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

大约为如下结构：

由F5公司设计的方案，通过Quest公司的Share Plex^[]近乎实时的复制数据到其他数据库节点，通过特定的模块检查数据库状态，并进行负载均衡，I/O 成功的做到了分布，读写分离，而且极大的提高了可用性。虽然整个方案技术并无高深之处，但方法巧妙，效果极好。

当然，这个技术架构不算便宜。Quest的Share Plex License很贵，而且对于每个结点来说，都需要数据库License与硬件费用。但优点也很多：节省了维护成本，数据库层面的访问也能做到SOA，高可用性。

国内的一些厂商比较喜欢给客户推存储级别的解决方案。通过存储底层复制来解决数据分布以及灾备问题。这个思路似乎太传统了，对于大型集群多少有点过时。

四、 Share Plex数据库负载均衡方案^[]

1. 需求及挑战

eBay拥有30套生产数据库，全部采用Oracle数据库：

A. 12个数据库支持“live”项目（Sun 480/4500）

B. 1个数据库支持存档项目（Sun 4800）

C. 4个数据库支持客户数据（Sun 4800）

D. 2个数据库支持eBay的反馈系统（Sun 480）

E. 1个数据库支持非正常的 “cache”数据（Sun 4800）

F. 10个其他的数据库（大部分Sun 480 class）

同时，采用Hitachi SAN建立存储架构，建立了两个远程备份数据库，并实施实时复制数据到远程数据库实现冗灾，同时每24小时实施针对数据块的数据备份。

因此，通过eBay数据库读写的比率分析，可以发现，eBay在数据库提供服务时，读和查询的操作达到530亿次，而数据库写和更新的操作达到2亿次。“读和查询”操作与“写和更新”的比率达到265:1。可见查询和数据库读的操作给数据库管理系统带来巨大的压力。而更为严峻的是，eBay年增长率达到50%，这意味着，来自读和查询的操作压力将持续增大，要保证数据库服务的响应能力和效率，稳定性和安全性，eBay 必须采用数据库服务器的负载均衡解决方案。

但是，由于系统庞大，出于投资保护等考虑，eBay对数据库服务器的负载均衡解决方案的需求有如下几个特点：

A. 不改变eBay的数据库体系结构

B. 可用性目标达到99.9%

C. 需承载eBay每年50%的高成长

D. 简单管理等等

这意味着在不对系统大动干戈的同时，却革命性地提高其性能，其挑战不言而喻。

2. 解决方案

针对eBay数据库服务器负载均衡的需求特点，eBay考虑了三种解决方案：

A. 将数据库垂直分割，划分成多层数据库处理，减轻原来单层数据库处理数据而形成的瓶颈与可用性问题。

问题：这种方案很难部署，而且也没有从根本上解决单点故障问题。

B. 采用Oracle OPS/RAC机群解决方案。

问题：要求给便数据库编程代码，非常难以管理与维护。

C. 采用F5与SharePlex 联合解决方案。

优点：简单管理，不需要改变整个体系结构。

在最初，eBay采用Oracle OPS/RAC解决问题。但是后来经过充分论证和探讨，最终eBay采用了基于F5/SharePlex的解决方案。

F5解决方案是应用类似OPS/RAC，但是却相对简单的解决方案，不用改变数据库体系结构，管理和维护简单得多。

F5解决方案得主要思路是：通过应用将数据库“读与查询”的操作与”写和更新”的操作导向到分开的 “逻辑” 数据库，这些数据库服务器都单独配备数据存储，而没有采用共享存储的方式。这样，F5 应用交换机动态的将所有的数据库”读与查询”请求导向到查询数据库服务器群中，并智能负载均衡到最佳的数据库服务器上。所有的”写和更新”请求都指向到一个单一的数据库服务器上，由Share Plex动态实时将数据记录复制到”读与查询”数据库服务器群的数据库中。

这样，一方面，数据库服务器群被F5应用交换机虚拟化和集群，变成了一个“池”；另一方面，“读与查询”的操作，可以根据需要，选择更高效率得数据库服务器，从而使“读与查询”的操作压力得到解决。同时，随着业务的增长，还可以随时根据客户业务的压力在线扩展新的服务器在这个群之中。

由于根据以上分析，数据库读写的比例超过260倍，采用这样的方法，有效解决了数据库性能和高可用性要求。

3. 方案特点

F5解决方案具有以下特点：

A. 运用分离读和写操作，使读和写操作进入分别的逻辑数据库 而不是共享磁盘

B. 数据库服务器均衡可以使所有的读操作交叉分配到Available Hosts，所有的写操作都指定到单一的DOR(Database-Of-Record)

C. 应用类似OPS/RAC，但是却相对简单的的解决方案

D. 发挥F5产品灵敏的量测性和显著的增强可用性。

采用F5的BIG-IP负载均衡器后，对于eBay应用系统有独到的优势：

A. 高可用性：BIG-IP动态分配每一个流量请求到后台的四台Oracle 9i Database数据库服务器，并动态检查各个服务器的健康状态，将下一个请求分配给最有效率的服务器，任何服务起死机时，BIG-IP即刻将流量请求分配给其他的三台服务器，从而达到99.999%系统有效性。特别是针对Oracle 9i 数据库服务器，F5公司专门为Oracle 9i数据库开发了专用的健康检查模块，通过调用F5专有的扩展应用校验（EAV）进程，F5能够随时得到Oracle 9i数据库的应用层服务能力而不是其他的负载均衡设备所采用的ICMP/TCP层进行健康检查。

B. 高安全性： BIG-IP支持地址翻译技术和安全地址翻译，这样一来客户不可能知道真正提供服务的服务器的IP地址与端口，从而保护数据库服务器不受到诸如SYN Flood、DOS及DDOS进攻。

C. 高效率：采用BIG-IP 负载均衡之后。BIG-IP可以智能寻找最佳状态的数据库服务器从而保证客户得到响应最快的数据库服务器以提供最佳的查询数据库服务。

D. 高可扩展性：BIG-IP可以支持动态增加或删除其负载均衡的数据库服务器群组的任何数量的服务器,而不需要对前端或后台做任何改变从而使得系统扩展轻松方便、透明。

E. 高可管理性：BIG-IP有专门的管理软件可以实时监控整个数据库服务器群组的流量状态,并分析发展趋势帮助客户及时根据流量增长增加服务器。

4. 客户价值

F5解决方案具有低成本、低维修，以及保护投资，高效率的特点，并方便在线拓展，面向未来。在2001年第二季度，F5公司与Quest公司合作成功帮助客户实现了以上解决方案，初期布署了两台”读与查询”数据库服务器和一台”写和更新”数据库服务器。在2001年第三季度成功通过了99.9%高可用性。并真正实现了在线高可扩展性，在2002年增加另外两台读与查询”数据库服务器，并于2002年第三季度增加部署了冗灾备份的功能。

F5提供的eBay数据库服务器负载均衡解决方案对行业也具有相当的借鉴意义。电子商务应用同样有着数据库查询的压力，如果能够有效将查询的压力分解到单独的服务器群来处理，将有效提高电子商务的应用效率。 对于电子商务类应用系统数据库扩展解决方案，只需要在Web Portal上将数据库请求分成两个不同模块，问题便迎刃而解。

对于公众服务行业类的数据库服务器的负载均衡，如银行，电信，税务等系统，每月和每季度的都会有报表生成汇总，这些报表既包括用户的月结单数据信息，也需要产生总体业务的业绩报告。这样就必须对数据库系统进行检索和查询。如果这些业务工作与实际生产环境是一个数据库的情况下，将造成系统的巨大压力。采用F5类似方法，同样能够有效达到高可用性预告可扩展性能的需要。