“淘宝”，这个早就渗入我们生活中的名词，对于绝大多数中国人来说，就是“网购”的代名词。
当初马老板是怎么把这个标志着中国电商行业发展的网站一步步做起来的，它面临着什么样的技术挑战，淘宝大神们是如何一步步解决问题的，书中都有详尽的描述（技术从07-11）：
首先买了个轻量的网站，架构是LAMP（linux+apache+mysql+php）的，php可以做从页面渲染到数据访问的所有事情，技术开源且免费（当面用mysql是潮流，用不起oracle，也没有分布式）。当时恰逢非典，大家都只想在家里买东西，可谓天时地利人和。
随着用户需求和流量的增长，服务器由一台变三台，一台发送Email，一台运行数据库，一台运行webapp，网站搜索用了阿里巴巴的isearch。
流量继续增大，mysql扛不住，换成了oracle：容量大、稳定、安全、性能高，主要还是自己有这方面的人才。
用户信息和网站信息增多，数据量变大后，本地的不够用了（还没买服务器），就去买了NAS（network attachedstorage 网络附属存储）作为数据库的存储设备（它的NFS协议传输延迟很严重）。
“好的架构师进化来的，不是设计来的。”功能也一样，这句话说得特别好，没有一步登天的完美架构，随着流量增大，存储和搜索方面的压力会越来越大，与一般的小集群相比，面临的问题也会越来越多。
旺旺完全就是为了满足国人的“砍价”心理设计的。。。
在网站开发语言的过程中，sun公司的人使用了“给业务分模块，一个模块一个模块地渐进式替换”的方案。即老的模块继续维护，新功能在新模块上开发，跟老的模块公用一个数据库，开发完毕后放到不同应用集群上，另开一个域名，同时再替换老的功能，逐渐把用户引导到新域名说，最后替换完成关闭老域名。
买了IBM的服务器，存储方面也是从EMC（美国信息存储咨询科技公司）低端CX存储到Sun oem hds高端存储，再到EMC dmx高端存储，一级级往上跳。但很多问题不是花钱能解决的，就开始了自主研发的道路。
在优化SQL和存储方面，对oracle进行了分库分表，做法是把用户的信息按照ID存放在两个数据库中（DB1和DB2），把商品信息和卖家信息放在两个对应的数据库中（DB3，DB4），把商品类目等通用信息放在第三个库中（DMcommon），这样既增加了数据库的容量，还能做容灾。出现的问题是，当要查询DB1和DB2的数据库时，比如要看“放进购物车里的商品、评价、投诉、举报、收藏、我的淘宝等应用”（有1也有2的），就需要对两个表进行Join。行癫搞了个数据库路由的框架DBRoute，统一处理了数据的合并、排序、分页等操作，让程序员像操作一个数据库一样操作多个数据库里的数据。
出了搜索引擎（isearch）、分库分表，还要怎么提升系统性能？缓存和CDN（内容分发网络，国内比较好的是ChinaCache）。
把那些不常修改的只读数据放到缓存里面（卖家信息，商品属性，店铺信息），商品详情字段太大了，不敢放进去，而且还要单独放在一个表里，与商品的价格、运费等信息区分开。章文嵩博士开发了淘宝自己的CDN。
存储方面，有大量的图片需要存储，而商用的存储系统有这些不足（章文嵩）：
1.商用存储系统没有对小文件存储和读取的环境优化
2.文件数量大，网络存储设备无法支撑
3.整个系统连接的服务器越来越多，网络连接数已经达到网络存储设备的极限
4.商用存储系统扩容成本高，10TB就几百万，而且存在单点故障
于是借鉴了GFS，开始研发TFS（taobao file system）.淘宝对图片存储的需求描述：文件比较小；并发量高；读操作远大于写操作；访问随机；没有文件修改的操作；要求存储成本低；能容灾，能备份。其实TFS和GFS没有什么区别吧。。。核心设计在于：图像文件名。保存文件名包括“图片的大小、时间、访问、频次和所在的逻辑块号”，因此，只需要一个fileid就能够准确定位文件在什么地方。
在图片存储系统的前面还有图片文件服务器，用于生成缩略图的运算，这个是怎么做的，缩略图可根据需要实时生成？
文件的定位用hash算法做索引，去重也是用hash，写盘用的append。
作者吐槽了一下几款悲剧的产品：“团购”，卖家设置团购价，买家达到一定数量后成交，底牌都亮出来了。。谁还会去买明码标价的货啊？所以，卖家提高原价，拿团购来做促销...“我的淘宝”，当然现在的版本看起来舒服多了。。“招财进宝”，也就是允许卖家购买广告位（类似于百度的竞价排名，当然还要看信用、成交量、被收藏数量等），没竞价上的人就喷了，你们不是说免费的么，这样搞我们还怎么浑水摸鱼啊！
2007年，淘宝的用户信息独立出来，形成了一个中心系统UIC（user information center），淘宝所有功能都要依赖用户信息，所以这个模块单独拿出来，每天要取几十亿条的用户信息，若直接查询数据库肯定会崩溃，这里必须要用缓存，于是多隆写了一个TDBM，数据全放在内存中，命中率高达99.2%。。。把TDBM、TBStore合并，就得到了Tair（taobao pair,pair 即 key/value数据对），包括缓存和持久化两种功能，tair支撑了淘宝几乎所有系统的缓存信息，开源了code.taobao.org。
（3）终于进入分布式时代了！
先解决一个分类的问题：先分男女装，再分款式、品牌和材质呢，还是反过来？商品的属性分类太复杂了。一灯说：品牌、款式、材质等都可以叫做“属性”，属性是类似tag的一个概念，与类目相比更加离散、灵活。淘宝的运行主要就是类目的运营，什么季节推什么商品，都要在类目属性上做调整，让买家更容易找到。
再来一个分模块的问题，把交易这个核心业务模块拆分。原来的淘宝交易除了跟商品管理耦合在一起，还在支付宝和淘宝之间转换，跟支付宝耦合在一起，这会导致系统很复杂，用户体验也很不好。我们把交易的底层业务拆分出来，叫交易中心（Trade Center，TC），所谓底层业务，就如创建订单、减库存、修改订单状态等原子型的操作；交易的上层业务叫交易管理（Trade Manager，TM），例如，拍下一件普通商品要对订单、库存、物流进行操作，拍下虚拟商品不需要对物流进行操作，这些在TM中完成。把淘宝的所有业务都模块化，这真的是脱胎换骨的操作了，项目名“五彩石”，女娲炼石补天之意：
其中，UIC和Forest在上文已说过，TC、IC、SC分别是交易中心（Trade Center）、商品中心（Item Center）、店铺中心（Shop Center），这些中心级别的服务只提供原子级的业务逻辑，如根据ID查找商品、创建交易、减少库存等操作。再往上一层是业务系统TM（Trade Manager，交易业务）、IM（ItemManager，商品业务）、SM（Shop Manager，后来改名叫SS，即Shop System，店铺业务）、Detail（商品详情）
几个大框架：
（一）至此，我们就需要一个HSF框架来完成对各种服务的调用：
HSF旨在为淘宝的应用提供一个分布式的服务框架，是一个分布式的标准service方式的RPC框架，定义基于OSGI方式，通讯层采用TCP/IP协议。
反正就是，你直接通过HSF框架调用服务，HSF会自动给你找到相应的服务的提供者，达到“软负载均衡”，服务集群对调用者来说是一个“云”的概念。
和以前采用的方式对比一下吧：打包JAR包装载到内存中运行，webservice,socket,http请求调用，每种调用方式都涉及各种超时、信息加密、参数定义等问题。
（二）另外一个是--消息通知的问题。
Notify系统：
银行付款后要给支付宝通知，支付宝完成支付后和淘宝也要有通信，淘宝的各个系统间也也要通信，比如拍下一件商品，交易管理系统要减库存，付款成功后，通知旺旺服务系统发送旺旺提醒，通知物流系统取货复活，通知SNS系统分享订单，通知公安局系统这个卖家是骗子。。。用户一个请求，底层系统有几十次的消息请求，于是，就诞生了这么一个消息中间件系统，支持消息的订阅、发送和消费。
（三）TDDL
拆分数据库。顶替了以前的DBRoute，特性：
1.数据访问路由——将针对数据的读写请求发送到最合适的
地方；
2.数据的多向非对称复制——一次写入，多点读取；
3.数据存储的自由扩展——不再受限于单台机器的容量瓶颈
与速度瓶颈，平滑迁移
工具平台时代:
愚公：数据迁移平台。能够在异构的数据库中进行数据平滑移动，对业务影响小，可插入自己的业务逻辑
精卫：数据增量复制平台，在数据的一对多分发及异步通知给DW和搜索等场景中发挥了重要作用。
Session框架：
因为HTTP协议本身是无状态的，所以经常需要通过Session来解决服务端和浏览器的保持状态的解决方案。用户向服务器发送第一个请求时，服务器为其建立一个sessiong，并为此session创建一个标识，用户随后的所有请求都应该包括这个标识号。服务器会校对这个标识号以判断请求属于哪个session。会话保持有效，默认状况下，直到浏览器关闭，会话才结束。
session包括的用户信息：昵称、用户ID、登陆状态
纯粹就当做是了解淘宝技术的软文看了...涉及的知识面很广，大部分也就只能是蜻蜓点水地了解一下，写代码查故障累了来看看就好- -
毕竟，在实际的应用场景中，很多公司都用不到这样的技术，流量不足，成本不够，技术不精等等问题。如果在发展过程中遇到相似的问题倒是可以参考解决一下，毕竟能够满足自己需求、解决自己问题的工具才是好工具。