Tag Archives: Arch

eBay 的数据层扩展经验

对于 eBay ，我盲人摸象一样写了好几篇 Blog ，暂列一下：

今天又重新读了一下这篇《The eBay Architecture –Striking a balance between site stablility, feature velocity, performance, and cost》，觉得数据层的扩展经验也很有意思。

通过功能划分不同数据库，然后根据主要访问路径水平分割数据库。这句话太空了，类似 MySQL DB 大家常采用的 Shard 思路。

减小 DB 资源开销

数据库上没有业务逻辑。这包括：不用存储过程; 只有少量比较简单的触发器。
把CPU 开销比较高的工作迁移到应用上。这包扩：参考完整性检查(嗯，检查一下你的 DB 是否再用外键? ); 连接(Join), 排序。
应用服务器尽量 Prepared 语句以及绑定变量的广泛使用。

最小化 DB 事务

自动提交(Commit)大多数主要的数据库写操作。
客户端绝对没有事务(业务逻辑) 。这包括: 单个数据库通过匿名 PL/SQL 块进行事务管理; 没有分布式事务。对于”事务”, 相关信息可以从 eBay 首席架构师 Dan Pritchett 的访谈得到确认。没有事务更没有分布式事务这一点比较关键，这也是因为 eBay 的商业逻辑天然性质(否则也不容易做)，所以可以做到 Scale Out，而最近了解到 Paypal 则因为交易逻辑比较复杂，只能是 Scale Up. Paypal 的技术信息一向比较封闭，谁能告诉我一点额外的信息呢?

–EOF–

Twitter 的架构扩展: 100 倍性能提升

Twitter 是我最近一段时间用的最多的网络服务之一.还记得刚开始有段时间发消息速度那叫一个慢. 难得的是 Twitter 的开发者在用户激增的情况下性能提升的不错, 据说,相比当初有 100 倍的性能提升, 那我们就来看看他们都做了什么.(发现我这个 Blog 快成了 High Scalability 的中文镜像站了.)

是否真的是 100 倍性能提升, 大可不必较真, 但 Twitter 的一些经验是足以借鉴的.

Ruby on rails

似乎 Twitter 是用 RoR 开发的流量最大的站点(有待于求证). 开始使用DRb (“Distributed Ruby”.), 该库可以通过 TCP/IP 从远程 Ruby 对象发送接收消息, 其缺点是不那么好用,并且没有冗余, 于是转向 Rinda , Rinda 基于 DRb 开发, 使用简单. Twitter 也证明了 Ror 应用同样可以支撑比较繁忙的站点, 工具没有对于错,关键是否能运用好.

图片来源. (这里面我非常疑惑的一点是据说只有两台DB(Master/Slave),可要支撑这么大的并发更新似乎有些难度.)

ETag

Twitter 对于Etag 的态度让不少人疑惑. 这恰恰是因技术制宜的一个体现, 因为 Etag 不是万能药. 另外一点比较重要的原因是 Twitter 有超过 90% 的流量来自 API, 而多数 API 客户端不支持 Etag.

数据库方面的经验

尽可能的索引(Fenng补充:不要过度索引). 因为 RoR 应用的特殊性, 索引是在代码中向 DB 提交的. 另外一个值得议题的是, 反范式. 严格遵守范式是要吃苦头的.建立可行的测试方法,明确的知道你的SQL都在用什么方式运行.(另外,我有个疑问是 rails 不支持 2 阶段提交的吧?)

避免资源过度被占用

哪个站点都不避免的有“水葫芦用户”,对于这样的 Spam 类型用户, 肯定会影响原有的应用处理资源. 该处理就要处理掉. 另一个方面,对于间歇性占用系统资源过多的进程用 Monit 处理.

另外一个很重要的环节是 Cache, 不废话了,没有好的Cache机制怕这样的站点不会成功的. (建议阅读车东辛苦翻译的这篇面向站长和网站管理员的Web缓存加速指南[翻译]). Twitter 运营的一个可取之处是能够积极听取社区的意见并改进, 同时社区上也有很多用户给他们提供了不少技术支持. 这也是开放而带来的好处吧.

–EOF–

WikiPedia 技术架构学习分享

维基百科(WikiPedia.org)位列世界十大网站，目前排名第八位。这是开放的力量。

来点直接的数据：

峰值每秒钟3万个 HTTP 请求
每秒钟 3Gbit 流量, 近乎375MB
350 台 PC 服务器

(数据来源)

架构示意图如下：
Copy @Mark Bergsma

GeoDNS

在我写的这些网站架构的 Blog 中，GeoDNS 第一次出现，这东西是啥? “A 40-line patch for BIND to add geographical filters support to the existent views in BIND”, 把用户带到最近的服务器。GeoDNS 在 WikiPedia 架构中担当重任当然是由 WikiPedia 的内容性质决定的–面向各个国家，各个地域。

负载均衡：LVS

WikiPedia 用 LVS 做负载均衡, 是章文嵩博士发起的项目,也算中国人为数不多的在开源领域的骄傲啦。LVS 维护的一个老问题就是监控了，维基百科的技术人员用的是 pybal.

图片服务器:Lighttpd

Lighttpd 现在成了准标准图片服务器配置了。不多说。

Wiki 软件: MediaWiki

对 MediaWiki 的应用层优化细化得快到极致了。用开销相对比较小的方法定位代码热点，参见实时性能报告，瓶颈在哪里，看这样的图树展示一目了然。另外一个十分值得重视的经验是，尽可能抛弃复杂的算法、代价昂贵的查询，以及可能带来过度开销的 MediaWiki 特性。

Cache! Cache! Cache!

维基百科网站成功的第一关键要素就是 Cache 了。CDN(其实也算是 Cache) 做内容分发到不同的大洲、Squid 作为反向代理. 数据库 Cache 用 Memcached，30 台，每台 2G 。对所有可能的数据尽可能的Cache，但他们也提醒了 Cache 的开销并非永远都是最小的，尽可能使用，但不能过度使用。

数据库: MySQL

MediaWiki 用的DB 是 MySQL. MySQL 在 Web 2.0 技术上的常见的一些扩展方案他们也在使用。复制、读写分离……应用在 DB 上的负载均衡通过 LoadBalancer.php 来做到的，可以给我们一个很好的参考。

运营这样的站点，WikiPedia 每年的开支是 200 万美元，技术人员只有 6 个，惊人的高效。

参考文档：

Wikimedia architecture （PDF)
Todd Hoff 的文章

–EOF–

说说北京奥运购票系统瘫痪这事儿

奥运购票网站据说刚上线就瘫痪了，听说而已，没有亲见。奥运会这种”钱多人傻”的项目，自是财大气粗，听说购票系统所用的存储都是花费人民币千万级别的，即使花了大钱还是没办好事，遭到批评也是活该。

开始说是因为网络负载导致瘫痪，后来又辟谣说，“主要还是系统后台的数据库的处理能力，在设计、规划方面，还有待于改进”

那我们实际看一下具体数据。“票务系统已经做了多次压力测试，票务系统每小时将能处理3万张门票的销售(另外又说：三个售票渠道共同能够处理的售票能力是每小时15万张），以及承担每小时100万次以上的网上浏览量。”，这算下来，也就是每秒钟处理不到 9 个交易请求，平均每秒钟 278 个点击(这也难怪百度李彦宏唏嘘一把: 不要说800万次，就是每小时8000万次，对百度来说，也只是a piece of cake)，这真是一个非常业务指标非常低的系统了。整个系统启动后，系统一个小时涌进来 20 万订单，其实平均每秒钟不过 56 个交易请求罢了。如果把问题推到数据库身上，还不如把问题推到开发人员数据库水平上。

抛开技术限制，门票的销售策略也让人觉得很傻，难道就不能一次只售一种项目的票麽? 先售那些比较冷门的项目分流一下访问压力，是很简单方便的真实压力测试。这只是奥运 IT 体系建设的第一次公共亮相，不由得让人担心其他方面的健壮性。

回头说李彦宏的自大。每小时 8000 万次，一天就是 19 亿的 PV，百度能有多少? 雅虎也不过是 40 亿PV而已。就别小菜一碟了，再说这只是 PV，如果加上事务量，那是更难搞的。

对比一下国内比较大的交易网站，中国彩票协会的数据：

营收35,000,000元/日(博彩业钱真好赚）, 目前系统每天交易笔数50,000,000笔,峰值处理4000笔/秒

这种压力估计还有的一搞。

–EOF–
Updated: 有人说其实是临时工的错，很有道理