登录模块加载中...
会员投稿 投稿指南 今天是:
打印本页 | 关闭窗口 | 双击滚屏 您的位置首页>>网页制作学习园地>>建站指南>>建站技巧文集>>淘宝技术发展
淘宝技术发展
来源: ‖ 作者: ‖ 点击: ‖ 时间:12-03-31 13:59:23 ‖ 【 】‖ 我要投稿

我们知道一台Oracle的处理能力是有上限的,它的连接池有数量限制,查询速度跟容量成反比。简单的说,在数据量上亿、查询量上亿的时候,就到它的极限了。要突破这种极限,最简单的方式就是多用几个Oracle数据库。但一个封闭的系统做扩展,不像分布式系统那样轻松。我们把用户的信息按照ID来放到两个数据库里面(DB1/DB2),把商品的信息跟着卖家放在两个对应的数据库里面,把商品类目等通用信息放在第三个库里面(DBcommon)。这么做的目的除了增加了数据库的容量之外,还有一个就是做容灾,万一一个数据库挂了,整个网站上还有一半的数据能操作。

数据库这么分了之后,应用程序有麻烦了,如果我是一个买家,买的商品有DB1的也有DB2的,要查看“我已买到的宝贝”的时候,应用程序怎么办?必须到两个数据库里面分别查询出来对应的商品。要按时间排序怎么办?两个库里面“我已买到的宝贝”全部查出来在应用程序里面做合并。还有分页怎么处理?关键字查询怎么处理?这些东西交给程序员来做的话会很悲催,于是行癫在淘宝的第一个架构上的作品就来解决了这个问题,他写了一个数据库路由的框架DBRoute,这个框架在淘宝的Oracle时代一直在使用。后来随着业务的发展,这种分库的第二个目的——容灾的效果就没有达到。像评价、投诉、举报、收藏、我的淘宝等很多地方,都必须同时连接DB1和DB2,哪个库挂了都会导致整个网站挂掉。

上一篇说过,采用EJB其实是和Sun的工程师妥协的结果,在他们走了之后,EJB也逐渐被冷落了下来。在05、06年的时候,spring大放异彩,正好利用spring的反射(IoC)模式替代了EJB的工厂模式,给整个系统精简了很多代码。

上一篇还说过,为了减少数据库的压力,提高搜索的效率,我们引入了搜索引擎。随着数据量的继续增长,到了2005年,商品数有1663万,PV有8931万,注册会员有1390万,这给数据和存储带来的压力依然山大,数据量大,性能就慢。亲,还有什么办法能提升系统的性能?一定还有招数可以用,这就是缓存和CDN(内容分发网络)。

你可以想象,九千万的访问量,有多少是在商品详情页面?访问这个页面的时候,数据全都是只读的(全部从数据库里面读出来,不写入数据库),如果把这些读操作从数据库里面移到内存里,数据库将会多么的感激涕零。在那个时候我们的架构师多隆大神,找到了一个基于 Berkeley DB 的开源的缓存系统,把很多不太变动的只读信息放了进去。其实最初这个缓存系统还比较弱,我们并没有把整个商品详情都放在里面,一开始把卖家的信息放里面,然后把商品属性放里面,商品详情这个字段太大,放进去受不了。说到商品详情,这个字段比较恐怖,有人统计过,淘宝商品详情打印出来平均有5米长,在系统里面其实放在哪里都不招人待见。笔者清楚的记得,我来淘宝之后担任项目经理做的第一个项目就是把商品详情从商品表里面给移出来。这个字段太大了,查询商品信息的时候很多都不需要查看详情,它跟商品的价格、运费这些放在一个表里面,拖慢了整个表的查询速度。在05年的时候,我把商品详情放在数据库的另外一张表里面,再往后这个大字段被从数据库里面请了出来,这也让数据库再一次感激涕零。

到现在为止,整个商品详情的页面都在缓存里面了,眼尖的读者可能会发现现在的商品详情不全是“只读”的信息了,这个页面上有个信息叫“浏览量”,这个数字每刷新一次页面就要“写入”数据库一次,这种高频度实时更新的数据能用缓存吗?如果不用缓存,一天几十亿的写入,数据库会怎么样?一定会挂掉。那怎么办?亲……先不回答你(下图不是广告,让你看看浏览量这个数据在哪里)

淘宝技术发展(Java时代:坚若磐石)

CDN这个工作相对比较独立,跟别的系统一样,一开始我们也是采用的商用系统。后来随着流量的增加,商用的系统已经撑不住

|<< << < 1 2 > >> >>|
加入收藏:  加入收藏夹  | 发送给好友:  发送给好友
责任编辑:admin
  • 上一篇:对Pinterest的一些反思
  • 下一篇:无
  • 相关文章列表
    请文明参与讨论,禁止漫骂攻击。  
    网友评论