登录模块加载中...
会员投稿 投稿指南 今天是:
打印本页 | 关闭窗口 | 双击滚屏 您的位置首页>>网页制作学习园地>>网页制作>>网站设计原则>>商用存储系统的局限
商用存储系统的局限
来源: ‖ 作者: ‖ 点击: ‖ 时间:12-04-11 11:07:47 ‖ 【 】‖ 我要投稿
。1.0版的PHP系统运行了将近一年的时间(2003.05-2004.01);后来数据库变成Oracle之后(2004.01-2004.05,叫1.1版本吧),不到半年就把开发语言转换为Java系统了(2004.02-2005.03,叫2.0版本);进行分库、加入缓存、CDN之后我们叫它2.1版本(2004.10-2007.01)。这中间有些时间的重合,因为很多架构的演化并没有明显的时间点,它是逐步进化而来的。

在描述2.1版本的时候我写的副标题是“坚若磐石”,这个“坚若磐石”是因为这个版本终于稳定下来了,在这个版本的系统上,淘宝网运行了两年多的时间。这期间有很多优秀的人才加入,也开发了很多优秀的产品,例如支付宝认证系统、招财进宝项目、淘宝旅行、淘宝彩票、淘宝论坛等等。甚至在团购网站风起云涌之前,淘宝网在2006年就推出了团购的功能,只是淘宝网最初的团购功能是买家发起的,达到卖家指定的数量之后,享受比一口价更低的价格,这个功能看起来是结合了淘宝一口价和荷兰拍的另一种交易模式,但不幸没有支撑下去。

在这些产品和功能的最底层,其实还是商品的管理和交易的管理这两大功能。这两大功能在2.1版本里面都有很大的变化。商品的管理起初是要求卖家选择7天到期还是14天到期,到期之后就要下架,必须重新发布才能上架,上架之后就变成了新的商品信息(ID变过了)。另外如果这个期间内成交了,之后再有新货,必须发布一个新的商品信息。这么做有几个原因,一是参照拍卖商品的时间设置,要在某日期前结束挂牌;二是搜索引擎不知道同样的商品哪个排前面,那就把挂牌时间长的排前面,这样就必须在某个时间把老的商品下架掉,不然它老排在前面;第三是成交信息和商品ID关联,这个商品如果多次编辑还是同一个ID的话,成交记录里面的商品信息会变来变去;还有一个不为人知的原因,我们的存储有限,不能让所有的商品老存放在主库里面。这种处理方式简单粗暴,但还算是公平。不过这样很多需求都无法满足,例如同样的商品,我上一次销售的时候很多好评都没法在下一个商品上体现出来;再例如我买过的商品结束后只看到交易的信息,不知道卖家还有没有再卖了。后来基于这些需求,我们在2006年下半年把商品和交易拆开。一个商家的一种商品有个唯一的ID,上下架都是同一个商品。那么如果卖家改价格、库存什么的话,已成交的信息怎么处理?那就在买家每交易一次的时候,都记录下商品的快照信息,有多少次交易就有多少个快照。这样买卖双方比较爽了,给系统带来了什么?存储的成本大幅度上升了!

存储的成本高到什么程度呢?数据库方面提到过用了IOE,一套下来就是千万级别的,那几套下来就是⋯⋯。另外淘宝网还有很多文件需要存储,我们有哪些文件呢?最主要的就是图片、商品描述、交易快照,一个商品要包含几张图片和一长串的描述信息,而每一张图片都要生成几张规格不同的缩略图。在2010年,淘宝网的后端系统上保存着286亿个图片文件。图片在交易系统中非常重要,俗话说“一张好图胜千言”、“无图无真相”,淘宝网的商品照片,尤其是热门商品,图片的访问流量是非常大的。淘宝网整体流量中,图片的访问流量要占到90%以上。且这些图片平均大小为17.45KB,小于8K的图片占整体图片数量61%,占整体系统容量的11%。这么多的图片数据、这么大的访问流量,给淘宝网的系统带来了巨大的挑战。众所周知,对于大多数系统来说,最头疼的就是大规模的小文件存储与读取,因为磁头需要频繁的寻道和换道,因此在读取上容易带来较长的延时。在大量高并发访问量的情况下,简直就是系统的噩梦。我们该怎么办?

同样的套路,在某个规模以下,采用现有的商业解决方案,达到某种规模之后,商业的解决方案无法满足,只有自己创造解决方案了。对于淘宝的图片存储来说,转折点在2007年。

|<< << < 1 2 3 > >> >>|
加入收藏:  加入收藏夹  | 发送给好友:  发送给好友
责任编辑:admin
相关文章列表
请文明参与讨论,禁止漫骂攻击。  
网友评论