《淘宝技术这十年》精华笔记，好的架构是进化来的，不是设计来的。

（未完成）

以下只是我个人感想及其对书内容部分总结，看看就好。

这本书一共分了三部分：

第一部分是淘宝从开始到现在的历程，中间都经历了什么坎，用到了什么技术，用什么来解决的，这部分挺有研究价值的，技术方面很多东西到现在都很受用。第二部分写了作者的工作经历。第三部分则是对阿里几位牛P工程师的采访。包含了他们对一些事物的观点及一些对其他人的建议。

这本书相当不错，围绕着淘宝等产品的发展，从技术上、业务上逐一进行分析。我喜欢这种“打怪升级”的书。阿里从简单点LAMP（linux+apache+mysql+php）架构到租用购买oracle的数据库，IBM的小型机，再到最先进的东西已经满足不了然后自己创造技术，这一路走来是经历了相当的波折，通过这本书让我理解了阿里做大、做好到底走的多艰苦。但是在技术发展中的很多难点书中没有仔细说明，让我略感遗憾。

我是从开发的角度看的，所以我会主要关注一些技术方面的问题，然后做做记录，在这里跟大家分享一下。

1.技术和业务相互竭力推动，业务满足不了的时候，技术必须创新，技术创新之后，业务有了更大的发展空间。

2.oracle的性能和并发访问能力之所以如此强大，有一个关键性的设计---连接池，连接池中放的是长连接，是进程级别的，在创建进程的时候，他就要独占一部分内存空间。也就是说，这些链接数在固定内存的oracle server上是有限的，任何一个请求只需要从连接池中取得一个连接即可，用完后释放，这不需要频繁的创建和断开连接。而连接的创建和断开的开销是非常大的。但对pph语言来说，她对数据库的访问都是很直接的，每一个请求都要一个连接。如果是长连接，应用服务器增多时连接数就多了，就会把数据库拖挂，如果是短连接，频繁的连接后再断开，性能会非常差。

3.其实在任何时候，开发语言本身都不是系统的瓶颈，业务带来的压力更多的存在于数据和存储方面。

技术升级路线：

1.一个数据库进行所有的读写

2.一个主库、两个从库，并且读写分离。存储容量增加了，有了备份，使得安全性增加了，读写分离使得读写效率得以提升（写要比读更加消耗资源，分开后互不干扰）。2003.4.7~2003.5.10

3.服务器由一台变成三台，一台发email，一台负责运行数据库、一台负责运行WebApp。

4.商品搜索占用数据库资源太大（用like搜索的，很慢），使用iSearch搜索引擎，2003.7

（第四版mysql，MyISAM存储引擎，写数据会锁表。Master同步数据到Slave时，会引起Slave写，这样在Slave读操作都要等待。还有会发生Slave上的主键冲突，会导致同步停止）

5.mysql替换为oracle。

6.开源连接池代理服务  SQL Relay（http://sqlrelay.sourceforge.net）

7.数据量增多，本地存储无法满足，买了NetApp（network appliance,美国网域存储技术有限公司）的NAS（network attached storage,网络附属存储）作为数据库的存储设备，加上oracle TAC（real application clusters,实时应用集群）来实现负载均衡。七公说这实际走了一段弯路，NAS的NFS（network file system）协议传输的延迟很严重。

8.采购了dell和emc合作的SAN低端存储

9.存储的节点一拆二、二拆四

10.更换开发语言，换的过程中不能拖慢业务的发展，边换边跑。php--->java 

方案是：给业务分模块，一个模块一个模块地渐进式替换， 

11.EMC低端CX存储到Sun oem hds高端存储，再到EMC dmx高端存储。IBM小型机。

12.分库分表。用户的信息按照id来存放到两个数据库中（DB1和DB2），吧商品的信息和卖家信息放到两个对应的数据库中，吧商品类目等通用信息放到第三个库中。新增自己写的数据库路由的框架DBRoute，统一处理了数据的合并，排序，分页等操作，让程序员像使用一个数据库一样操作多个数据库。

13.CDN。商用系统---->淘宝自己的CDN

14.开发了自己的文件储存系统TFS。因为每笔交易生成一个快照，所以存储成本大幅度上升 。2007年6月，TFS正式上线运营。生产环境中应用的集群规模达到200台PC Server（146GB*6 SAS 15KB Raid5）,文件数量达到上亿级别；系统部署容量存储为140TB；实际使用存储容量为50TB；单台支持随机IOPS200+，流量为3MB/s。

15.开发了自己的缓存系统TBstore。基于Berkeley DB的缓存系统，把很多不太变动的只读信息放进去。TBstore的分布式算法实现：根据保存的key，对key进行hash算法，取得hash值，再对hash只与从Cache服务器数据取模。然后根据取模后的值，找到服务器列表中下标为此值的Cache服务器。由Java Client API实现，应用无需关心。（2005年吧商品详情从商品表中移出来，，再往后，这个大字段被从数据库中请了出来，先是放入了缓存系统，现在是放进了文件系统TFS中）

16.开发了TDBM，抛弃了Berkeley DB的持久功能，数据全部存在内存中。2009年又参考memcached的内存结构，改进了TDBM的集群分布方式，在内存利用率和吞吐量方面又做了大幅提升，推出了TDBM 2.0。2007年把淘宝的用户信息独立出来，形成一个中心系统UIC（User Information Center），用为淘宝所有功能都要依赖于用户信息，所以必须吧这个模块单独拿出来，否则以后的系统无法扩展。粗算一下，每天要取几十亿条用户信息，若直接查数据库，数据库肯定崩溃，所以又单独建立的缓存系统。

17.由于TDBM、TBstore的数据接口和用途都很相似，开发团队把二者合并，推出了淘宝自创的Key-Value缓存系统---Tair（TaoBao Pair的意思，Pair即Key-Value数据对）。Tair包括缓存和持久化两种存储功能。Tair作为一个分布式系统，由一个中心控制节点和一系列的服务节点组成，我们称中心控制节点为Config Server，服务节点是Data Server。Config Server负责管理所有的Data Server，维护Data Server 的状态信息。Data Server对外提供各种数据服务，并以心跳的形式将自身的状况汇报给Config Server。Config Server是控制节点，而且是单点，目前采用一主一备的形式来保证其可靠性。所有的Data Server地位都是等价的。

18.升级iSearch。之前的搜索引擎是把数据分到多台机器上，但是每份数据只有一份，现在是每份数据变成多份，整个系统从一个单行的部署变成了矩阵，能够支撑更大的访问量，并且做到很高的可用性。

19.服务化。把公共模块单独达成JAR包。

20.每做一个日常修改，都必须对整个系统回归测试一遍；多个日常修改如果放在一个版本中，要是一个功能没有测试通过，整个系统都不能发布。

21.交易的底层业务拆分出来，叫交易中心（Trade Center，TC），所谓底层业务，就如创建订单，减库存，修改订单状态等原子型操作；交易的上层业务叫交易管理（Trade Manager，TM），例如，拍下一件普通商品要对订单，库存，物流进行操作，拍下虚拟商品不需要对物流进行操作，这些在TM中完成。

22.2008年底，把淘宝所有的业务都模块化。

23.开发了高性能服务框架HSF。服务的提供者启动时通过HSF框架向ConfigServer注册服务信息（接口、版本、超时时间、序列号方式等），这样ConfigServer上面就定义了所有可供调用的服务（同一个服务也可能有不同的版本）；服务调用者启动的时候向ConfigServer注册对哪些服务感兴趣（接口、版本），当服务提供者的信息变化时，ConfigServer向相关的感兴趣的服务调用者推送新的服务信息列表；调用者在调用时则根据服务信息的列表直接访问相应的服务提供者，而无需经过ConfigServer。HSF会根据负载状况来选择具体的服务器，返回结果给调用者。

24.开发了消息中间件Notify。分布式消息中间件系统，支持消息的订阅、发送和消费。

25.开发了分布式数据访问层TDDL。数据访问路由---将针对数据的读写请求发送到最合适的地方；数据的多向非对称复制---一次写入，多点读取；数据存储的自由扩展---不再受限于单台机器的容量瓶颈与速度瓶颈，平滑迁移。

26.开发了TBsession框架。Session的客户端存储，将Session信息存储到客户端浏览器Cookie中；实现服务端存储，减少Cookie使用，增强用户信息的安全性，避免浏览器对Cookie数量和大小的限制。Session配置统一管理，集中管理服务端Session和客户端Cookie的使用情况，对Cookie的使用做有效的监管。只吃动态更新，Session的配置动态更新。

TFS所要解决的问题：

文件比较小；并发量高；读操作远大于写操作；访问随机；没有文件修改的操作；要求存储成本低；能容灾，能备份。显然，应对这种需求时要用分布式存储系统；由于文件大小比较统一，可以采用专有文件系统；由于并发量高，读写操作性强，需要更少的I/O操作；考虑到成本和备份，需要用廉价的存储设备；考虑到容灾，需要能平滑扩容。