Java时代：坚若磐石.pdfVIP

Java Java JJaavvaa时代：坚若磐石 文章整理：刘明晋，徐发亮 杨苏鹏（成都夜场招聘） 已经有读者在迫不及待的问怎么去掉了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的创始人章文嵩博士带人搭建了