完全门外汉，开始有一些理解了

## 《淘宝技术这十年》
这本在豆瓣上被评论为简单死了的书，我看了三遍才看下去，才勉强读完。如果不是上了阳老师的课，我觉得这本书属于永远的烂尾工程。因为里面讲的东西我没有懂的。但用高阶思维来看，渐渐有些明白了。

读书笔记先摘抄一下：
#####问题1:你的浏览器在同一个域名下并发加载的资源数量是有限的，例如IE6和IE7是2个，IE8是6个，chrome各版本不大一样，一般是4-6个。淘宝网首页大概要加载126个资源。那么如此小的并发连接数自然会加载很久。
解决方法：前端开发人员会将这些资源文件分布在多个域名下，变相地绕过浏览器的这个限制。

#####问题2:搜索进行分词（因为中文以字为单位，而不是以词为单位）后，还需要判断购物意图。用户进行搜索时往往有以下几类意图：浏览型，查询型（有一定购物意图，对属性有要求），对比型，确定型。
解决方法：通过对你的购物意图的分析，主搜索会呈现完全不同的结果。

#####问题3:商业存储设备的不足。1）对小文件存储和读取的环境没有有针对性的优化；2）文件数量大，网络存储设备无法支撑；3）整个系统所链接的服务器越来越多，网络连接数已经达到网络存储设备的极限；4）商用存储系统扩容成本高，10TB的存储容量需要几百万，而且存在单点故障，容灾和安全性无法得到很好的保证
解决方法：TFS（淘宝 file system）。核心设计的最大讨巧指出在于，传统的集群系统中元数据只有一份，通常由管理节点来管理，因此很容易成为瓶颈。而对于淘宝网的用户来说，图片文件究竟用什么名字来保存他们并不关心，因此，TFS在设计规划上考虑在图片的保存文件名上暗藏了一些元数据信息，例如，图片的大小，时间，访问频次等信息，包括所在的逻辑块号。而在实际的元数据上，保存的信息很少。因此，元数据结构非常简单，仅仅只需要一个fileID就能够准确定位文件在什么地方。由于大量的文件信息都隐藏在文件名中，整个系统完全抛弃了传统的**目录树**结构。因为目录树开销最大。拿到后，整个集群的高可扩展性可极大地提高。实际上，这一设计理念和目前业界的“对象存储”较类似。
去掉IOE的成功，这对淘宝来说是一个标志性的事件。我们最核心的系统已经摆脱了商用软件，完全基于开源软件和自主开发的软件系统。


#####问题4：硬盘读取的问题，导致响应速度较慢
解决方法：缩减元数据大小，将更多的元数据加载入内存，提升访问速度。重要的是，让图片尽量在缓存中命中。传递到后端TFS的流量就已经非常均衡和分散了，对前端的响应性能也大大提高。如果缓存没有命中，则在本地服务器上查找是否有原图，并根据原图生成缩略图。如果仍未命中，则会考虑到后台TFS集群文件存储系统上调取。因此，最终反馈到TFS集群文件存储系统上的流量已经被大大优化了。

#####问题5：为什么网页端软件会替代客户端软件？
解决方案：蘑菇街网站的设计者是从淘宝出来的。当时他们的前端交互技术，就是Gmail上那种AJAX的交互方式，可以拖动，可以鼠标右键，也可以用组合键。操作完毕后还不刷新页面，管理商品有如神助。可惜由于当时卖家水平低，接受新技术能力不足，后放弃该项目。
HTML5不是HTML4的简单升级，通常我们把CSS3和很多新的JavaScript（简称JS）的API都合起来称为H5.原来的Html4并没有让Web成为一个很好的开发平台，它只能让web作为一个界面展现一些内容，做些简单的交互。而H5的目的是让整个web真正成为一个开发平台，或者说是让浏览器成为一个适合开发大型应用的平台。
未来的方向是前后端的界线越来越模糊，未来前后端的开发会融合起来，这样的岗位叫做web开发工程师。

#####问题6：为什么要把用户信息独立出来？
解决方案：因为淘宝所有的功能都要依赖于用户信息，所以必须要把这个模块单独拿出来，否则以后的系统无法扩展。每天要取几十亿条的用户信息，若直接查询数据库，数据库肯定会崩溃，这里必须要用缓存。所以多隆专门为User Information Center做了一个缓存系统，命名为TDBM。

### tag化
在系统发展得过程中，架构师的眼光至关重要。作为程序员只要把功能实现即可，而作为架构师，要考虑系统的扩展性，重用性。06年之前的三年时间，商品的分类都是按照树形结构一级一级来分的，而随着商品数量的增长，类目也变得越来越深，且越来越复杂。这样，买家如果要查找一件商品，就要逐级打开类目，找商品之前要弄清商品的分类。

一灯大侠的做法改变了这一进程。他说品牌、款式、材质等都可以叫做属性。属性是类似tag（标签）的一个概念。与类目相比更加离散，灵活。这样也缩减了类目的深度。这个思想的提出一举解决了分类的难题！从系统的角度讲，我们建立了属性这样一个数据结构，由于除了类目的子节点有属性外，父亲点也可能有属性，于是类目属性合起来也是一个结构化的数据对象。这个做出来后，我们把它独立出来做了一个服务，叫做Catserver（category server）。跟类目属性密切关联的商品搜索功能独立出来，叫做Hesper（金星）。Cateserver和Hesper供淘宝的前后台系统调用。

最初的类目属性改造完之后，我们很缺乏属性数据，于是找到中关村在线，在属性信息后标注。有了类目属性，给运营工作带来和很大便利。比如什么季节推什么样的商品。什么流行，就要把什么商品往更高级的类目上调整。这样类目和属性要经常调整（tag的问题浮现了）。随着商品量的增长，卖家的工作量越来越大。前后台显示不一致。后来决定，后台仓库要按照自然类目来存储，而前台显示可以随着季节和关联来调整摆放场景（例如著名的啤酒和尿布的关联）。两者密切关联，却又相互分开。这样，淘宝前台展示的是根据运营需要摆放商品的类目和属性。

### 模块化
08年初，主站系统容量达到了瓶颈，即使上层系统加机器也无法继续扩容，只能把底层基础数据拆分，从底层开始扩容，上层才能扩展，才能容纳以后3-5年的增长。
于是，我们把交易这个核心业务拆分开来。原来的淘宝交易除了要跟商品管理耦合在一起，还在支付宝和淘宝之间转换。交易中心和用户中心也拆分出来后。到了2008年年底，就是把淘宝所有的业务都模块化。
拆分之后的问题，系统之间的相互关系变得非常复杂。
系统这么拆分的好处显而易见，拆分之后的每个系统都可以单独部署，业务简单，方便扩容，有大量可重用的模块便于开发新的业务；能够专人专事，让技术人员更加专注于某一个领域。
这样要解决的问题也很明显，分拆之后，系统之间还是必须要打交道。越往底层的系统，调用它的客户越多（小世界模型中的联络点）。这就要求底层的系统必须具有超大规模的容量和非常高的可用性。
另外，拆分之后系统如何通信？这里需要两种中间件系统。一种是实时调用的。一种是异步消息通知。

### 智能不应该在中心
当时AT&T的一个研究人员研究了十几年的智能网，但后来他把自己的理论颠覆了，认为智能不应该在中心，智能应该在终端。

### 数据库本质上是一个单机系统
数据库本质上是一个单机系统，即便是做了分库分表，这也没有改变是单机系统的本质。打破这个瓶颈， **分布式系统** 是一个选择。这方面的大规模应用最早是由google开始做的。但淘宝和google的需求有一个不同的地方：搜索引擎可能索引不到一些页面，也可能索引到一些页面的速度较慢，但淘宝是从事电子商务的，用户的商品、交易都不能遗漏和出错，页面的展示要尽可能快，我们需要更高的数据一致性，也需要存取速度更快的数据库。因此我们要解决的问题时，提供高容量、低成本、高一致性、高可靠的数据存储和访问服务。
和Google、Amazon的相同之处在于，这个级别的公司做数据，从宏观上看都是分布式的。分布式的理念是相同的。但数据不同。Amazon只有B2C的数据，google没有商业数据。而淘宝的数据从质和量上都非常高。