淘宝网技术发展回顾（五） Java时代：坚若磐石

上一篇：淘宝网技术发展回顾（四）：Java时代 脱胎换骨

　　已经有读者在迫不及待的问怎么去掉了IOE，别急，在去掉IOE之前还有很长的路要走。行癫他们买回来小型机之后，我们用上了Oracle，七公带着一帮DBA在优化SQL和存储，行癫带着几个架构师在研究数据库的扩展性。Oracle本身是一个封闭的系统，用Oracle怎么做扩展?用现在一个时髦的说法就是做“分库分表”。

　　我们知道一台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年的时候，我把商品详情放在数据库的另外一张表里面，再往后这个大字段被从数据库里面请了出来，这也让数据库再一次感激涕零。

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

　　CDN这个工作相对比较独立，跟别的系统一样，一开始我们也是采用的商用系统。后来随着流量的增加，商用的系统已经撑不住了，LVS的创始人章文嵩博士带人搭建了淘宝自己的CDN网络。在本文的引言中我说过淘宝的CDN系统支撑了800Gbps以上的流量，作为对比我们可以看一下国内专业做CDN的上市公司ChinaCache的介绍——“ChinaCache……是中国第一的专业CDN服务提供商，向客户提供全方位网络内容快速分布解决方案。作为首家获信产部许可的CDN服务提供商，目前ChinaCache在全国50多个大中城市拥有