【淘宝技术这十年】，读后总结篇

一看就是一天，晚饭忘了吃了。

由于里面涉及的技术确实颇有传奇色彩。

突然认为，没有时间看书，并且须要补充技术营养的技术宅来说，勤奋的渣渣我来提供福利了，萃取一些精华分享给大家吧

--------start----------------------------------------

1.2007年分布式文件系统TFS（TaoBao File System）---->解决淘宝文件图片资源载入慢的问题

2Tair（淘宝自行研发的分布式KV存储方案）---->宝贝快照

3.淘宝研发了TimeTunnel，用于进行实时的传输数据---->为了高速、及时、同步地传输日志数据

4.云梯的基于Hadoop的由3000多台server组成的超大规模数据系统。ODPS系统的数据系统--->不断地进行分析和挖掘用户数据(交易，浏览，操作日志等)

5.MVC框架是阿里的WebX，控制层用了EJB，持久层是ibatis。

6.淘宝网将图片处理与缓存编写成基于Nginx的模块

7.淘宝网使用GraphicsMagick进行图片处理，採用了面向小对象的缓存文件系统。前端有LVS+Haproxy将原图和其全部的缩略图请求都调度到同一台Image Server（图片server）。

8.在文件定位上。内存用Hash算法做索引，最多一次读盘。

另外会有非常多同样的图片反复上传上来，去除反复文件也是採用Hash算法来做

9.ESI是一种数据缓冲/缓存server，它提供将Web网页的部分（这里指页面的片段）进行缓冲/缓存的技术及服务

10.ESI是一种数据缓冲/缓存server，它提供将Web网页的部分（这里指页面的片段）进行缓冲/缓存的技术及服务

11.UIC的一个缓存系统，取名叫做TDBM。TDBM抛弃了Berkeley DB的持久功能，数据所有存放在内存中。

12.因为TDBM、TBstore的数据接口和用途都非常相似，开发团队把二者合并。推出了淘宝自创的Key-Value缓存系统——Tair（TaoBao Pair的意思。Pair即Key-Value数据对）。Tair包含缓

存和持久化两种存储功能。

Tair作为一个分布式系统，由一个中心控制节点和一系列的服务节点组成。我们称中心控制节点为Config Server。服务节点是Data Server。Config Server 负责管理所

有的Data Server。维护Data Server的状态信息。

Data Server 对外提供各种数据服务，并以心跳的形式将自身的状况汇报给ConfigServer。Config Server是控制点，并且是单点。眼下採用一主一备

的形式来保证其可靠性。

全部的Data Server 地位都是等价的。

13.在商品分类方面。从系统的角度来看。建立了“属性”这样一个数据结构，因为除了类目的子节点有属性外。父节点也可能有属性。于是类目属性合起来也是一个结构化的数据对象。

把它独立出来作为一个服务，叫做Catserver（Category Server）。跟类目属性密切关联的商品搜索功能独立出来，叫做Hesper（金星）。Catserver和Hesper供淘宝的前后台系统调用。

14.因为季节不同，商品文件夹在前台须要依据运营者制定，后台还是自然文件夹存储。改造后的类目属性服务取名为Forest（森林，与类目属性有点神似。Catserver还用于提供卖家授权、品牌服务、关键词等相关的服务）。

类目属性的服务化是淘宝在系统服务化方面做的第一个探索。

15.中间件系统，一种是实时调用的中间件（淘宝的HSF，高性能服务框架），一种是异步消息通知的中间件（淘宝的Notify）

16.HSF

这就是HSF的设计思想。服务的提供者启动时通过HSF框架向ConfigServer（类似超市的电视机）注冊服务信息（接口、版本号、超时时间、序列化方式等），这样ConfigServer上面就定义了全部可供调用的服务（同一个服务也可能有不同的版本号）；服务调用者启动的时候向ConfigServer注冊对哪些服务感兴趣（接口、版本号），当服务提供者的信息变化时，ConfigServer向对应的感兴趣的服务调用者推送新的服务信息列表；调用者在调用时则依据服务信息的列表直接訪问对应的服务提供者，而无须经过ConfigServer。我们注意到ConfigServer并不会把服务提供者的IP地址推送给服务的调用者，HSF框架会依据负载状况来选择详细的server，返回结果给调用者。这不仅统一了服务调用的方式，也

实现了“软负载均衡”。平时ConfigServer通过和服务提供者的心跳来感应服务提供者的存活状态。

17.Notify

NotifyServer在ConfigServer上面注冊消息服务。消息的client通过ConfigServer订阅消息服务。某个client调用NotifyServer发送一条消息，NotifyServer负责把消息发送到全部订阅这个消息的client（这个过程參照HSF一节，原理是一样的）。为了保证消息一定能发出。且对方也一定能收到，消息数据本身就须要记录下来，这些信息存放在数据库中（能够是各种数据库）。因为消息具有中间状态（已发送、未发送等），应用系统通过Notify能够实现分布式事物——BASE（基本可用（Basically Available）、软状态（Soft State）、终于一致（Eventually Consistent））。

NotifyServer能够水平扩展，NotifyClient也能够水平扩展，数据库也能够水平扩展，从理论上讲，这个消息系统的吞吐量是没有上限的。如今Notify系统每天承载了淘宝10亿次以上的消息通知。

18.TDDL

TDDL实现了以下三个基本的特性：

yy数据訪问路由——将针对数据的读写请求发送到最合适的

地方。

yy数据的多向非对称复制——一次写入，多点读取。

yy数据存储的自由扩展——不再受限于单台机器的容量瓶颈

与速度瓶颈。平滑迁移。

下图展示了TDDL所处的位置。