子柳 - 经济理财榜-商业
本书从工程师的角度讲述淘宝这个超大规模互联网系统的成长历程，及其所有主动和被动的技术变革的前因后果。书中有幕后故事、产品经验、架构演进、技术启蒙，也有大牛成长、业内八卦、失败案例、励志故事。全书文风流畅，有技术人员特有的幽默感；内容积极正面，有现场感，全部是作者亲身经历。
其实技术书很容易写成催眠的读物，对于这本书，我一开始就没有当作技术书来写，最早是我写给自己看的。 c:11
书中主要围绕网站的业务和系统架构之间的关系展开论述。 c:28
我意识到自己经历了一场伟大的变革，这个时代把电子商务推到了一个浪潮之巅，我是这个浪潮中的一滴水珠，我无意描述这场伟大的浪潮，只希望通过一滴水珠映射出浪潮底下的故事。 c:37
铁打的营盘，流水的兵， c:19
至2011年年底，淘宝网拥有全国最大的Hadoop分布式计算集群之一（2000多个节点，CPU：24000 core，Memory：48000GB，Disk：24000块），日新增数据50TB，有40PB海量数据存储，分布在全国各地80多个节点的CDN网络，支撑的流量超过800Gbps。 c:150
你的浏览器在同一个域名下并发加载的资源数量是有限的，例如IE 6和IE 7是两个，IE 8是6个，chrome各版本不大一样，一般是4～6个。我刚刚看了一下，我访问淘宝网首页需要加载126个资源，那么如此小的并发连接数自然会加载很久。所以前端开发人员往往会将上述这些资源文件分布在多个域名下，变相地绕过浏览器的这个限制，同时也为下文的CDN工作做准备。 c:261
其中最有技术含量的是对数据库进行了一个修改，原来是从一个数据库进行所有的读写操作，现在把它拆分成一个主库、两个从库，并且读写分离。这么做的好处有几点：存储容量增加了，有了备份，使得安全性增加了，读写分离使得读写效率得以提升（写要比读更加消耗资源，分开后互不干扰）。 c:122
淘宝贝，而她本人也非常热爱逛街，享受“淘”的乐趣，她觉得“淘宝”两个字特别符合网站的定位（阿珂说想到这个名字的时候，脑子里一道闪电劈过，真的是“灵光一闪”。后来“支付宝”的名字也是阿珂取的）。于是这个大名就定了下来，淘宝网横空出世了。 c:33
一个“个人网站”。由于这个创业团队强大的市场开拓和运营能力，淘宝网的发展非常迅猛，2003年年底就吸引了注册用户23万个，每日31万个PV，从2003年5月到同年年底成交额达3371万元。这没有引起eBay的注意，却引起了阿里巴巴内部很多员工的注意，他们觉得这个网站以后会成为阿里巴巴强劲的对手，甚至有人在内网发帖，忠告管理层要警惕这个刚刚起步的网站，但管理层似乎无动于衷。（这个团队的保密工作做得真好！） c:33
好的架构是进化来的，不是设计来的 c:71
现在我们再一次知道，任何牛B的人物，都必须有一段苦B的经历。 c:40
在那个野蛮生长的阶段，其实很多产品都是想到什么就做什么，例如，我们还搭建过一个聊天室，但似乎淘宝网不是一个闲聊的地方，这个聊天室门可罗雀，一段时间后就关闭掉了。 c:28
我的师父黄裳曾经说过“好的架构图充满美感”。一个架构好不好，从审美的角度就能看出来。 c:48
黄裳曾经说过“好的架构图充满美感”。一个架构好不好，从审美的角度就能看出来。 c:82
我刚才说到Java被世界上主流的大规模网站普遍采用，其中有一个网站就是eBay，那时eBay的系统刚刚从C++改到Java，而且就是请Sun的工程师给改造成Java架构的，这下你懂了吧？他们不仅更懂Java，而且更懂eBay。 c:33
他们的大致方案是给业务分模块，一个模块一个模块地渐进式替换。 c:30
其实这个搜索引擎的原理很简单，就是把数据库里的数据dump（倾倒）成结构化的文本文件后，放在硬盘上，提供Web应用以约定的参数和语法来查询这些数据。 c:13
其实在任何时候，开发语言本身都不是系统的瓶颈，业务带来的压力更多的存在于数据和存储方面。 c:179
除了搜索引擎、分库分表，还有什么办法能提升系统的性能？一定还有招数可以用，这就是缓存和CDN（内容分发网络）。 c:46
它最早与商品的价格、运费等信息放在一个表中，拖慢了整张表的查询速度，而很多时候查询商品信息是不需要查看详情的。 c:120
于是在2005年的时候，我把商品详情放在数据库的另外一张表中，再往后，这个大字段被从数据库中请了出来，先是放入了缓存系统，到现在是放进了文件系统TFS中。 c:39
消耗多少？在前两年我们算过一笔账，淘宝上产生一个交易，消耗的电量足以煮熟4个鸡蛋 c:26
我们对数据分库、放弃EJB、引入Spring、加入缓存、加入CDN等工作，看起来没有章法可循，其实都是围绕着提高容量、提高性能、节约成本来做的 c:31
到2006年，淘宝网已经有了1.5亿个的日均PV，商品数达5千多万个，注册用户3千多万个，全网成交额达169亿元。 c:22
用钱能解决的问题都不是问题，我们花钱可以购买更好的机器和更好的服务。但当你变成业内最强之后，你的问题就会独特到没有人碰到过，这就意味着你必须自己动手解决问题。 c:102
淘宝文件系统——TFS[插图]淘宝KV缓存系统——Tair c:17
回顾一下上面几个版本，1.0版的PHP系统运行了将近一年的时间（2003年5月—2004年1月），服务器由一台发展到多台；后来数据库撑不住了，将MySQL换成了Oracle，引入了搜索引擎（2004年1月—2004年5月，叫1.1版本）；然后不到半年的时间又把开发语言换成了Java（2004年2月—2005年3月，叫2.0版本），数据服务逐步采用了IOE；随着数据量和访问量的增长，我们进行数据分库、加入缓存、使用CDN（2004年10月—2007年1月，叫2.1版本）。这几个版本中间有些时间上的重合，因为很多架构的演化并没有明显的时间点，它是逐步进化而来的。 c:17
对于大多数系统来说，最头疼的就是大规模的小文件存储与读取，因为磁头需要频繁寻道和换道，因此，在读取上容易带来较长的延时 c:42
从2006年开始，我们决定自己开发一套针对海量小文件存储的文件系统，用于解决自身图片存储的难题。这标志着淘宝网从使用技术到了创造技术的阶段。 c:37
商用存储系统的局限和不足。 第一，商用存储系统没有对小文件存储和读取的环境进行有针对性的优化；第二，文件数量大，网络存储设备无法支撑；第三，整个系统所连接的服务器越来越多，网络连接数已经达到网络存储设备的极限；第四，商用存储系统扩容成本高，10TB的存储容量需要几百万元，而且存在单点故障，容灾和安全性无法得到很好的保证。 c:81
文件比较小；并发量高；读操作远大于写操作；访问随机；没有文件修改的操作；要求存储成本低；能容灾，能备份。显然，应对这种需求时要用分布式存储系统；由于文件大小比较统一，可以采用专有文件系统；由于并发量高，读写随机性强，需要更少的I/O操作；考虑到成本和备份，需要用廉价的存储设备；考虑到容灾，需要能平滑扩容。 c:27
由于大量的文件信息都隐藏在文件名中，整个系统完全抛弃了传统的目录树结构，因为目录树开销最大。 c:29
这个产品带给我们的是新技术（AJAX、prototype框架）的尝试，以及新技术对用户操作习惯的改变，一定要慎之又慎。 c:33
一般的缓存策略是不支持实时更新的，这时候多隆大神想了个办法，在Apache上面写了一个模块，这个数字根本不经过下层的WebApp容器（只经过Apache）就写入一个集中式的缓存区了，这个缓存区的数据再异步更新到数据库。这就是我前面提到的，整个商品详情的页面都在缓存中了，把缓存用到了极致。 c:57
ESI是一种数据缓冲/缓存服务器，它提供将Web网页的部分（这里指页面的片段）进行缓冲/缓存的技术及服务 c:19
TBstore的分布式算法实现：根据保存的Key（关键字），对key进行Hash算法，取得Hash值，再对Hash值与总Cache服务器数据取模。然后根据取模后的值，找到服务器列表中下标为此值的Cache服务器。由Java Client API封装实现，应用无须关心。 c:42
目前，Tair支撑了淘宝几乎所有系统的缓存信息。Tair已开源，地址为code.taobao.org。 c:53
在系统发展的过程中，架构师的眼光至关重要，作为程序员，只要把功能实现即可，但作为架构师，要考虑系统的扩展性、重用性，对于这种敏锐的感觉，有人说是一种“代码洁癖”。 c:75
这时候，一位大侠出来了——一灯，他说品牌、款式、材质等都可以叫做“属性”，属性是类似Tag（标签）的一个概念，与类目相比更加离散、灵活，这样也缩减了类目的深度。这个思想的提出一举解决了分类的难题！从系统的角度来看，我们建立了“属性”这样一个数据结构，由于除了类目的子节点有属性外，父节点也可能有属性，于是类目属性合起来也是一个结构化的数据对象。 c:27
拆分之后的系统如何通信？这里需要两种中间件系统，一种是实时调用的中间件（淘宝的HSF，高性能服务框架），一种是异步消息通知的中间件（淘宝的Notify）。 c:126
互联网系统的发展看似非常专业，其实在生活中也存在类似的“系统”，正如一位哲学家说“太阳底下无新事”。我们可以从生活中的一个小例子来看网站系统的发展 c:19
HSF的作者毕玄写了一篇博文（http∶//www.blogjava.net/BlueDavy/archive/2008/01/24/177533.html），有关基于OSGI的分布式服务框架，也有一系列的博文（http∶//www.blogjava.net/BlueDavy/archive/2008/01/14/175054.html）。 c:30
然后鲁肃提出做一个系统框架上的解决方案，把要发出的通知存放到数据库中，如果实时发送失败，再用一个时间程序来周期性地发送这些通知，系统记录下消息的中间状态和时间戳，这样保证消息一定能发出，也一定能通知到，且通知带有时间顺序，这些通知甚至可以实现事务性的操作。 c:35
然后鲁肃提出做一个系统框架上的解决方案，把要发出的通知存放到数据库中，如果实时发送失败，再用一个时间程序来周期性地发送这些通知，系统记录下消息的中间状态和时间戳，这样保证消息一定能发出，也一定能通知到，且通知带有时间顺序，这些通知甚至可以实现事务性的操作。 c:46
Notify是一个分布式的消息中间件系统，支持消息的订阅、发送和消费 c:26
TDDL实现了下面三个主要的特性： ● 数据访问路由——将针对数据的读写请求发送到最合适的地方； ● 数据的多向非对称复制——一次写入，多点读取； ● 数据存储的自由扩展——不再受限于单台机器的容量瓶颈与速度瓶颈，平滑迁移。 c:19
TDDL实现了下面三个主要的特性：● 数据访问路由——将针对数据的读写请求发送到最合适的地方；● 数据的多向非对称复制——一次写入，多点读取；● 数据存储的自由扩展——不再受限于单台机器的容量瓶颈与速度瓶颈，平滑迁移。 c:16
● 对外统一一切数据访问； ● 支持缓存、文件存储系统； ● 能够在Oracle和MySQL之间自由切换； ● 支持搜索引擎。 c:12
● 对外统一一切数据访问；● 支持缓存、文件存储系统；● 能够在Oracle和MySQL之间自由切换；● 支持搜索引擎。 c:13
Taobao Distributed Data layer（TDDL，后来有人对它取了个外号 ∶“头都大了”⊙﹏⊙b） c:19
“评价”是第一个重要的应用，评价最重要的问题还是在于双向查询、评价、被评价。于是我们的异构数据源增量复制就派上了用场。 c:13
功能可以做得不那么“漂亮”，但必须减少中间环节，真正做到了实用、干净、简洁。 c:17
解决集群Session共享的问题，通常有以下两种办法。● 硬件负载，将用户请求分发到特定的服务器。● Session复制，就是将用户的Session复制到集群内所有的服务器。 c:14
到此为止，应用服务切分了（TM、IM）、核心服务切分了（TC、IC）、基础服务切分了（UIC、Forest）、数据存储切分了（DB、TFS、Tair），通过高性能服务框架（HSF）、分布式数据层（TDDL）、消息中间件（Notify）和Session框架支持了这些切分。一个美好的时代到来了，高度稳定、可扩展、低成本、快速迭代、产品化管理，淘宝的3.0系统走上了历史的舞台。 c:82
开放平台建设初期要解决的就是三个问题： ● 服务路由。（外部可以获取内部信息） ● 服务接口标准化。（统一方式的获得各种标准化信息） ● 授权。（外部合法的获取内部信息） c:48
自己封装字节流解析模块，按需解析上行数据，一来可以提升数据分析的性能（并行业务和数据增量分析操作），二来可以用最小代价处理异常请求（当发现不满足业务规范时，则立刻丢弃后续所有的数据），这块实现被叫做LazyParser，主要的实现重点就是最小化数据缓存来进行并行业务和数据解析操作 c:12
回顾SQL的理念时，发现其实所有的统计在切割成为KV作为输入/输出时，所涵盖的需求无非是Max、Min、Average、Sum、Count、Distinct（这个是2012年实现的，用了bloomfilter和AtomicLong），再复杂一些无非就是上述几个操作结果的数学表达式运算 c:39
开放平台稳定性受制于任何一个业务方，这是不可接受的。 c:16
参看Blog，地址为http∶//blog.csdn.net/cenwenchu79，根据时间轴可以看到各种结构优化和性能优化的过程 c:56
充分利用多核能力用计算换内存；磁盘换内存，用并行设计来保证整体业务时间消耗不变甚至减少；Slave Shuffle来减少Mater的合并压力；数据压缩减少数据传输消耗和内存占用。 c:33
支持Comet长连接方式，后端通过事件驱动的模式主动推送内部消息给外部，避免外部轮询业务接口 c:17
技术要敢想，代码要敢写，细节要敢专，没什么不可能 c:80
前5年是技术变革带动开放平台发展，而接下去的5年将会是业务变革和理解带动开放平台的阶段，对业务的理解直接决定了开放平台的价值所在 c:11
淘宝的格局为：集市（C2C）、天猫（B2C）、一淘（电商搜索返利入口）、无线、新业务、O2O（本地生活）、团购平台（聚划算），这些平台的价值是什么？如何找到自身定位？如何借助外力发展？如何面对流量入口的兴起、传统互联网企业的电商化、电商平台的竞争？这些才是开放平台2012 c:20
当时除了Sun公司的人和淘宝的人，还来了一位标志性的人物@fenng，他是这个项目的DBA，记得他刚来杭州时，家里要装宽带，运营商服务不周到，被他骂了好久。后来（2010年）他在微博上大战中国电信已经相当有经验了。 c:13
当时那热火朝天的岁月令我至今难忘，我三天三夜没回家的时候，我老婆还打电话过来问“你到底还爱不爱我了？”我说：“怎么会不爱呢？” c:35
我和鲁肃尝试了很多种办法，一开始用MQ，但并发量上来之后老丢消息，消息的时间顺序也会错，后来他做了一个消息中间件系统，这个就是淘宝的Notify的雏形，现在Notify一天能发送几亿条消息通知，能保证通知到，也能保证不重复通知，还能保证消息有次序，相当不容易。 c:30
于是我新建了一张表来存储商品详情，普通的商品查询不会用到这张表，只在商品详情（Detail）页面才会用到，做完之后，性能一下子好了很多，我又骄傲了很久。再后来我知道商品的详情已经不能存放数据库了，放到了文件系统上。 c:14
所以支付宝认证的原理就是：用户提交身份信息和银行账户，我们往这个账户里存钱，存进去之后，用户填写收到了多少钱（我们号称存过去的是1元钱以内的金额，实际上只有几分钱），如果用户填写的与我们向里面存的是一致的，那么这个人的身份就是对的。这不仅降低了认证的成本，也使认证的效率由原来的一周左右变成一天以内 c:60
很多东西，不是你努力就能成功的，也许应了那句话“谋事在人，成事在天”。 c:69
普通工程师跟着业务跑，来啥需求做啥事；文艺工程师专注于自己的领域，研究得非常精深；2B工程师跳来跳去，啥都干，啥都浅尝辄止；还有一种工程师叫牛B工程师，啥都能干，啥都精通（这种人在工程师心中叫“神”） c:46
那时候从一位大侠那里听到一个理论，作为M，就不可能做到让所有的人都喜欢你。这对于一贯喜欢做好人的我来说，很有难度。但做了两年M之后，有人说我是个“老好人”，这真是一个很大的打击，说明我这个M没有做好。 c:14
我们认为培训的本质是：“通过知识的流转，促进员工的成长，进而推动公司业绩的提升。” c:58
在线学习大概有四种模式：视频、文档、直播、问答 c:16
我认为互联网行业的知识不是要去管理的，而是要让隐性的知识显性化，在它的生命周期里迅速传播出去。我们不需要等它沉淀，只需要让足够多的知识流动起来，就能创造巨大的价值。 c:79
未来我们只招最优秀的学生，这些学生要培养成技术上的“高富帅 c:13
跟进了三个月之后有一些感受，不管是外部创业还是内部创新，都面临着九死一生的压力，有想法没用，要有产品出来，甚至有产品还不够，要能够迅速推向市场。内部创新也面临着被抄袭的危险，同时还面临着“官方”产品的竞争。 c:20
不管是外部创业还是内部创新，都面临着九死一生的压力，有想法没用，要有产品出来，甚至有产品还不够，要能够迅速推向市场。 c:37
企业和个人也是这样一个关系：一个水平很高的人，找不到合适的平台，就难以发挥自己的价值；一个蓬勃发展的企业，找不到合适的人才，其前景也会堪忧。 c:64
“I hear and I forget.I see and I remember. I do and I understand”，这句话给我留下非常深刻的印象。是荀子说的“不闻不若闻之，闻之不若见之，见之不若知之，知之不若行之。” c:137
数据库本质上是一个单机系统，即便是做了分库分表，这些也没有改变的是单机系统的本质 c:12
关系数据库的数据规模受限的根本原因是目前的关系数据库尽管有各种方式的扩展，但本质上是单机系统。 c:24
OceanBase最好的地方就是具备事务，数据一致性很好。HBase在数据容量上会有优势，几千万亿字节都有可能，但它没有解决事务的问题 c:12
在这点上，我特别喜欢马总的理念——做公司要赚钱，但阿里从不把赚钱作为第一目标，我们服务好了客户，客户赚了钱，我们一定会得到自己应得的一份。在个人成长问题上也是类似的道理，这就是，一个人如果把做事、做成事作为主要目标，该他得到的东西，一定会顺理成章的、水到渠成地得到，但是，如果把上升作为主要目标，做同样的事，结果就会完全不一样。一句话，你的心态会最终决定你的成就。 c:58
我觉得百度其实不如淘宝重视技术，KPI导向的文化很重，各部门之间的协作和配合比较难（这一点淘宝要好不少），不同部门、不同项目的开发人员做了不少有差别但其实比较类似的东西，看起来个体效率高，但整体效率未必高，这可能是百度加班很严重的原因之一。 c:33
分布式Java应用：基础与实践 c:18
现在如果没有什么特殊情况的话，我会花很多时间看技术方面的文章或者图书，写代码的时间可能每天只有两三个小时。每隔一段时间会去想一想将来干什么比较好，因为写代码时间会过得很快，要经常跳出来想一想。 c:22
我觉得最重要的是看那个人对公司做了多少贡献，你可以说你的技术确实很强，但事实是你对公司没有做出任何贡献。 c:11
如果你是向技术方向发展的人员，我们要看技术方面的专业性；然后看你的技术对公司的业务发展有多少贡献。还有一点，我比较看重的是，也许你不在其位，但能够跳出自己的范围，想到公司未来到底会面临什么问题，用什么方法来解决。当然，仅想是不够的，如果你能够落实就最好了，我们不管你落实的技术含量有多高，关键是你解决了什么样的问题。如果你能够做到这些，你这个人对公司就非常重要。 c:57
技术委员会在级别P7～P9的定义中，要求P7级的人员要对一个小的产品或团队有方向性的指导，P8级就要求在一个大部门或公司级的产品上有方向性的指导，P9级要求除了考虑自身的产品之外，还要站在公司的角度考虑自身的产品对公司的发展有什么帮助。 c:60
第一个是做事要自己思考后再去问别人，而不是一遇到问题就找人求助。第二个是不断地打破自己的一些想法，你不要担心自己今天已经做了50%的工作，要是推倒重来，前面的事情都白干了。我现在带的两个新人成长很快，但是都有类似的经历，就是一个东西被我反复推翻重做，在这个过程中就是不断地成长，要思考我为什么让你推倒重做，若想不清楚，下次重做的概率会更大，这样慢慢地就会学会了思考。 c:121
任何一个公司，不管用什么手段，都做不到绝对公平，最终只会有小部分人得到机会。这个时候去抱怨、愤怒都没有用的，只有自己不断地努力争取机会才行。 c:32
放翁：在杭州，如果你不出去玩玩，就太可惜了。我推荐大家去走走云栖竹径、虎跑后山、江洋畈，这些地方的人比较少，很安静，能够让你放松身心。长一点的路线是从古荡上去到北高峰，然后到宋城。 c:21
创业团队，把一个东西从小做到大。这样什么都经历过了，事业方面就满足了。然后我希望能到世界各地走走，这辈子也比较完整了 c:11
首先要有职业道德，然后要假设一切都是邪恶的，我们自己的人也不能完全相信，要通过技术手段来保证，所有人的操作都有记录，做审计，然后收权限，我们自己也只有很少几个人有服务器的权限，保证我们自己也黑不掉公司。 c:21
《白帽子讲Web安全》 c:20
吴翰清：从基本功做起，研究常见的漏洞，把它查出来，并去分析它，不要用它来做坏事。另外，去看看公开的漏洞，研究一下漏洞的利用技巧。 c:42
最终是成功整合了，前端形成了量子统计和数据魔方两个产品，后面数据的系统整合成Hadoop的一个集群。 c:15
我们的数据每日新增长达到100TB左右，通过极限存储等创新的技术手段，控制净增量快速增长的势头。 c:12
理想主义，兴趣+执著，看准一个方向后，无论是顺境还是逆境，都要不断地努力，不浪费时间和机会。 c:31
兴趣是最好的老师，坚持是达到梦想的唯一途径，当然，在个人发展的不同阶段寻找到合适的导师很重要，看准方向会事半功倍。在刚刚参加工作还没有形成自己的判断时，方向有两个来源，一个是个人的兴趣，一个是找一个你非常佩服且能掌握未来方向的人，当然，如果这两者正好重合，那么剩下的就是脚踏实地坚持。 c:77
JavaScript语言精粹 c:12
我个人认为传统的开发人员更多的是面向机器来开发的，更多的是考虑CPU的问题、内存的问题、数据库的问题。实际上需要一些开发人员对“用户”有更敏锐的感觉，他们来完成“界面”的问题，界面是互联网与用户交互的地方，他需要对体验有一些认识，对“人”更关注。 c:27
这个阶段前端的团队迅速成长，你可以理解为，第一阶段就是让页面动起来，第二阶段是前端和后端合作，让页面的体验更加友好。 c:14
我认为，未来的方向是前后端的界线越来越模糊，即未来要求开发工程师能够把前后端的工作衔接起来。我个人比较认可一种说法：经过这几年开发模式的渐渐发展，未来前后端的开发会融合起来，这样的岗位叫做“Web开发工程师”。 c:43
关于团队一起写书，我发现这是一个很好的团队建设的方式，在写书的过程中，大家要有很多交流，能够互相学习，互相督促，也增进了彼此的感情。 c:12
现在回过头来看，其实成长最快的一段时间是刚进淘宝的那几年，那个时候很单纯，就想着把工作做好，做完一个做下一个，不管这个业务是不是重要，需求方是不是好打交道。有个“一万个小时理论”，我觉得很正确，说的就是一个人必须经过不断地练习，不断地遇到问题才能成长起来。当然，做的时候要不断总结，写博客是一个很好的途径。 c:54
他把自己当成海绵一样去吸收新知识——在他的字典里，没有不值得去解决的问题，也没有不值得去学习的技术。而且每学一个知识点，多隆都会写一段代码去验证，一方面是练习，另一方面也让他加深理解，直到真正掌握这个技术。 c:17
发现问题，解决问题，不要绕开问题的本身；多做事情，不会吃亏，即使不是你的事情。 c:184