元数据
元数据
[!abstract] 淘宝技术这十年
淘宝技术这十年|200 - 书名： 淘宝技术这十年
- 作者： 子柳
- 简介： 本书从工程师的角度讲述淘宝这个超大规模互联网系统的成长历程，及其所有主动和被动的技术变革的前因后果。书中有幕后故事、产品经验、架构演进、技术启蒙，也有大牛成长、业内八卦、失败案例、励志故事。全书文风流畅，有技术人员特有的幽默感；内容积极正面，有现场感，全部是作者亲身经历。
- 出版时间： 2013-05-01 00:00:00
- ISBN： 9787121201912
- 分类： 经济理财-商业
- 出版社： 电子工业出版社
- PC地址：https://weread.qq.com/web/reader/016324b05a617e01617778f
高亮划线
第0章 引言：光棍节的狂欢
📌 涉及负载均衡的第一步，通过DNS解析域名时，将你的访问分配到不同的入口，同时尽可能保证你所访问的入口是所有入口中可能较快的一个
⏱ 2024-05-14 08:50:26 ^680318-4-2817-2880
📌 些资源文件分布在多个域名下，变相地绕过浏览器的这个限制
⏱ 2024-05-14 08:50:58 ^680318-4-3745-3772
📌 这便是CDN （Content Delivery Network，即内容分发网络的作用）。淘宝在全国各地建立了数十个甚至上百个CDN节点，利用一些手段保证你访问的（这里主要指JS、CSS、图片等）站点是离你最近的CDN节点，这样便保证了大流量的分散以及在各地访问的加速。
⏱ 2024-05-14 08:59:54 ^680318-4-3989-4124
📌 淘宝上拥有海量的宝贝图片等静态文件，这些文件的总容量也达到了数PB （1PB=1024TB=1048576GB），为了快速存取这些文件，淘宝开发了分布式文件系统TFS（TaoBao File System）来处理这类问题。
⏱ 2024-05-14 09:00:36 ^680318-4-4259-4370
📌 这是为了防止商家对在商品详情中承诺过的东西赖账不认
⏱ 2024-05-14 09:03:41 ^680318-4-5576-5601
📌 淘宝自行研发的分布式KV存储方案
⏱ 2024-05-14 09:03:32 ^680318-4-5675-5691
📌 为了快速、及时、同步地传输这些日志数据，淘宝研发了TimeTunnel，用于进行实时的数据传输，然后交给后端系统进行计算报表等操作。
⏱ 2024-05-14 09:04:35 ^680318-4-5871-5937
📌 并且其中有些数据使用了压缩比高达1∶120的极限存储技术。之后这些数据会通过一个叫做云梯的基于Hadoop的由3000多台服务器组成的超大规模数据系统，以及一个基于阿里巴巴集团自主研发的ODPS系统的数据系统，
⏱ 2024-05-14 09:05:27 ^680318-4-6053-6158
📌 任何网站的发展都不是一蹴而就的，通常是在什么阶段采用什么技术。在发展的过程中，网站会遇到各种各样的问题，正是这些原因才推动着技术的进步和发展，而技术的发展反过来又会促进业务的更大提升。
⏱ 2024-05-14 18:35:38 ^680318-4-6929-7021
📌 所有主动和被动的技术变革的前因后果，这由很多有趣的故事组成。
⏱ 2024-05-14 18:35:38 ^680318-4-7141-7171
数据库从mySQL到Oracle
📌 Oracle的性能和并发访问能力之所以如此强大，有一个关键性的设计——连接池，连接池中放的是长连接，是进程级别的，在创建进程的时候，它就要独占一部分内存空间
⏱ 2024-05-20 09:46:22 ^680318-9-890-968
📌 把数据的连接放在SQL Relay之后就噩梦不断，这个代理服务经常会死锁，如同之前的MySQL死锁一样。虽然多隆做了很多修改，但当时那个版本内部处理的逻辑不对，问题很多，最快的解决办法就是“重启”它的服务。
⏱ 2024-08-09 09:30:08 ^680318-9-2050-2153
支付手段的创新——支付宝
📌 好的架构是进化来的，不是设计来的
⏱ 2024-05-18 08:46:26 ^680318-10-443-459
📌 好的功能也是进化来的，不是设计来的
⏱ 2024-08-08 09:13:33 ^680318-10-477-494
交流方式的创新——淘宝旺旺
📌 在那个野蛮生长的阶段，其实很多产品都是想到什么就做什么
⏱ 2024-08-08 09:15:56 ^680318-11-1372-1399
第3章 企业级Java网站
📌 我的师父黄裳曾经说过“好的架构图充满美感”。一个架构好不好，从审美的角度就能看出来。后来我看了很多系统的架构，发现这个言论基本成立。
⏱ 2024-08-08 09:16:21 ^680318-12-981-1047
📌 Java是当时最成熟的网站开发语言，它有比较良好的企业开发框架，被世界上主流的大规模网站普遍采用。另外，有Java开发经验的人才也比较多，后续维护成本会比较低。
⏱ 2024-05-20 09:37:13 ^680318-12-1224-1304
脱胎换骨的升级——更换开发语言
📌 他们的大致方案是给业务分模块，一个模块一个模块地渐进式替换
⏱ 2024-08-08 09:43:34 ^680318-13-1459-1488
📌 如用户模块，老的member.taobao.com继续维护，不添加新功能，新功能在新的模块上开发，跟老的模块共用一个数据库，开发完毕之后放到不同的应用集群上
⏱ 2024-08-08 09:46:02 ^680318-13-1489-1567
坚若磐石——围绕性能、容量和成本的进化
📌 我把商品详情放在数据库的另外一张表中，再往后，这个大字段被从数据库中请了出来，先是放入了缓存系统，到现在是放进了文件系统TFS中。
⏱ 2024-05-20 09:59:24 ^680318-14-2300-2365
淘宝文件系统——TFS
📌 对于大多数系统来说，最头疼的就是大规模的小文件存储与读取，因为磁头需要频繁寻道和换道，因此，在读取上容易带来较长的延时。
⏱ 2024-05-24 09:11:37 ^680318-16-764-824
📌 随着淘宝网的图片文件数量以每年3倍的速度增长，淘宝网后端NetApp公司的存储系统也从低端到高端不断迁移，直至2006年，即使是NetApp公司最高端的产品也不能满足淘宝网存储的要求。
⏱ 2024-05-24 09:14:10 ^680318-16-997-1089
📌 从2006年开始，我们决定自己开发一套针对海量小文件存储的文件系统，用于解决自身图片存储的难题。这标志着淘宝网从使用技术到了创造技术的阶段。
⏱ 2024-05-24 09:14:23 ^680318-16-1089-1188
📌 第一，商用存储系统没有对小文件存储和读取的环境进行有针对性的优化；第二，文件数量大，网络存储设备无法支撑；第三，整个系统所连接的服务器越来越多，网络连接数已经达到网络存储设备的极限；第四，商用存储系统扩容成本高，10TB的存储容量需要几百万元，而且存在单点故障，容灾和安全性无法得到很好的保证。
⏱ 2024-05-24 09:17:57 ^680318-16-1483-1630
📌 第三，在一定规模效应的基础上，研发的投入都是值得的。 ^680318-16-1908-1934
- 💭 商业系统和自研系统，随着规模越来越大，自研系统的投入会有优势。 - ⏱ 2024-05-24 09:19:37
📌 文件比较小；并发量高；读操作远大于写操作；访问随机；没有文件修改的操作；要求存储成本低；能容灾，能备份。显然，应对这种需求时要用分布式存储系统；由于文件大小比较统一，可以采用专有文件系统；由于并发量高，读写随机性强，需要更少的I/O操作；考虑到成本和备份，需要用廉价的存储设备；考虑到容灾，需要能平滑扩容。
⏱ 2024-05-24 09:26:47 ^680318-16-2830-2983
📌 仅仅只需要一个FileID就能够准确定位文件在什么地方
⏱ 2024-05-24 09:41:03 ^680318-16-3972-3999
📌 技术和业务就是这么互相借力推动着的，业务满足不了的时候，技术必须创新，技术创新之后，业务有了更大的发展空间。
⏱ 2024-05-24 09:42:34 ^680318-16-4343-4397
📌 整个图片存储系统就像一个庞大的服务器，有处理单元、缓存单元和存储单元。前面已经介绍过后台的TFS集群文件存储系统，在TFS前端，还部署着200多台图片文件服务器，用Apache实现，用于生成缩略图的运算。
⏱ 2024-05-24 09:49:42 ^680318-16-5933-6035
📌 图片文件服务器的前端则是一级缓存和二级缓存，前面还有全局负载均衡的设置，用于解决图片的访问热点问题。
⏱ 2024-05-24 09:52:08 ^680318-16-6261-6311
📌 根据淘宝的缓存策略，大部分图片都尽量在缓存中命中，如果缓存中无法命中，则会在本地服务器上查找是否存有原图，并根据原图生成缩略图，如果都没有命中，则会考虑去后台TFS集群文件存储系统上调取。
⏱ 2024-05-24 09:52:55 ^680318-16-6422-6516
淘宝KV缓存系统——Tair
📌 这个产品带给我们的是新技术（AJAX、prototype框架）的尝试，以及新技术对用户操作习惯的改变，一定要慎之又慎。另外，还有一点没有总结好的教训，就是应对群体事件的时候，我们手足无措，在后来“招财进宝”和淘宝商城出现群体性事件的时候，我发现悲剧在重演 ^680318-17-2162-2289
- 💭 这个产品带给我们的是新技术（AJAX、prototype框架）的尝试，以及新技术对用户操作习惯的改变，一定要慎之又慎。另外，还有一点没有总结好的教训，就是应对群体事件的时候，我们手足无措，在后来“招财进宝”和淘宝商城出现群体性事件的时候，我发现悲剧在重演
- ⏱ 2024-05-27 09:46:49
📌 TBstore的分布式算法实现：根据保存的Key（关键字），对key进行Hash算法，取得Hash值，再对Hash值与总Cache服务器数据取模。然后根据取模后的值，找到服务器列表中下标为此值的Cache服务器。由Java Client API封装实现，应用无须关心。 ^680318-17-4705-4839
- 💭 一致性hash - ⏱ 2024-05-27 09:54:55
📌 由于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地位都是等价的。
⏱ 2024-05-27 09:59:31 ^680318-17-5673-6036
第5章 分布式电子商务操作系统
📌 在飞速发展的背后，隐患已经埋下。在技术架构的制约下，团队协作越来越艰难，代码越来越臃肿，开发的效率越来越低，新业务的需求越来越多，老业务的压力眼看就要超过系统的容量了。这时候，架构该做怎样的调整？又一次的脱胎换骨，欲火重生。
⏱ 2024-05-27 10:02:04 ^680318-18-438-550
服务化
📌 业务方总在后面催，开发人员不够就继续招人，招来的人根本看不懂原来的业务，只好摸索着在“合适的地方”加一些“合适的代码”，看看运行起来像那么回事后，就发布上线。在这样的恶性循环中，系统越来越臃肿，业务的耦合性越来越高，开发的效率越来越低。
⏱ 2024-06-26 09:20:15 ^680318-19-1738-1856
📌 ，这些中心级别的服务只提供原子级的业务逻辑，如根据ID查找商品、创建交易、减少库存等操作
⏱ 2024-06-26 09:27:47 ^680318-19-4876-4920
📌 系统这么拆分的好处显而易见，拆分之后的每个系统可以单独部署，业务简单，方便扩容；有大量可重用的模块便于开发新的业务；能够做到专人专事，让技术人员更加专注于某一个领域。这样要解决的问题也很明显，分拆之后，系统之间还是必须要打交道的，越往底层的系统，调用它的客户越多，这就要求底层的系统必须具有超大规模的容量和非常高的可用性。
⏱ 2024-06-26 09:29:28 ^680318-19-4961-5464
📌 拆分之后的系统如何通信？这里需要两种中间件系统，一种是实时调用的中间件（淘宝的HSF，高性能服务框架），一种是异步消息通知的中间件（淘宝的Notify）
⏱ 2024-06-26 09:29:41 ^680318-19-5467-5543
📌 Session框架
⏱ 2024-06-26 09:30:00 ^680318-19-5593-5602
📌 软件工程方面
⏱ 2024-06-26 09:30:15 ^680318-19-5610-5616
📌 测试
⏱ 2024-06-26 09:30:17 ^680318-19-5633-5635
中间件
📌 互联网系统的发展看似非常专业，其实在生活中也存在类似的“系统”，正如一位哲学家说“太阳底下无新事”
⏱ 2024-07-02 09:25:10 ^680318-20-432-481
📌 但我们发现消息数量上来之后，常常造成拥堵，消息的顺序也会出错，在系统挂掉的时候，消息也会丢掉，这样非常不保险。然后鲁肃提出做一个系统框架上的解决方案，把要发出的通知存放到数据库中，如果实时发送失败，再用一个时间程序来周期性地发送这些通知，系统记录下消息的中间状态和时间戳，这样保证消息一定能发出，也一定能通知到，且通知带有时间顺序，
⏱ 2024-07-10 09:32:21 ^680318-20-5532-5715
📌 Notify是一个分布式的消息中间件系统，支持消息的订阅、发送和消费
⏱ 2024-07-10 09:32:34 ^680318-20-6039-6073
📌 TDDL实现了下面三个主要的特性：● 数据访问路由——将针对数据的读写请求发送到最合适的地方；● 数据的多向非对称复制——一次写入，多点读取；● 数据存储的自由扩展——不再受限于单台机器的容量瓶颈与速度瓶颈，平滑迁移。
⏱ 2024-07-10 09:36:37 ^680318-20-7628-7839
📌 使用高端存储和小型机的Oracle存储的成本将难以控制，于是降低成本就成了必然。
⏱ 2024-07-10 19:42:23 ^680318-20-8941-8981
📌 容量规划做得不到位
⏱ 2024-07-10 19:47:37 ^680318-20-10835-10844
📌 历史遗留问题
⏱ 2024-07-10 19:47:42 ^680318-20-10916-10922
📌 数据层代码被业务代码侵染
⏱ 2024-07-10 19:47:46 ^680318-20-11032-11044
📌 “愚公”数据迁移平台
⏱ 2024-07-10 19:51:58 ^680318-20-12331-12341
📌 “精卫”数据增量复制平台
⏱ 2024-07-10 19:52:05 ^680318-20-12541-12553
开放平台
📌 SOA盛行的年代，内部架构服务化成为开放的第一步，内部服务不做好隔离，开放就意味着风险不可控。
⏱ 2024-07-10 20:17:30 ^680318-22-1137-1184
📌 服务单元Bundle的粒度控制，服务之间依赖管理，性能与规范的冲突，调试与隔离的平衡。这些都使得一线开发者和平台框架实现者出现非常多的矛盾，而这个过程能活下来的框架最后都是摒弃了很多企业级的设计思路，因为SOA架构从企业级产品演变而来，而服务化后的内部平台要面对的开放平台天生就是互联网的产物。
⏱ 2024-07-10 20:17:24 ^680318-22-1308-1455
📌 开放平台建设初期要解决的就是三个问题：
● 服务路由。（外部可以获取内部信息）
⏱ 2024-07-10 20:17:46 ^680318-22-1565-1637
📌 ● 服务接口标准化。（统一方式的获得各种标准化信息）
● 授权。（外部合法的获取内部信息）
⏱ 2024-07-10 20:18:03 ^680318-22-1671-1749
📌 授权解决了开放最大的一个问题：用户安全的对应用访问其数据受信。用户从此不用赤裸裸地将用户名和密码交给一个应用软件，应用也可以在允许的范围内（操作、数据、授权时长）充分利用用户授权来玩转创意。
⏱ 2024-07-12 09:18:05 ^680318-22-2034-2129
📌 从访问日志分析中可以看到很多无效的请求也占用了非常多的处理时间，这也意味着无效请求和有效请求一样在消耗着有限的容器线程资源。于是我们开始尝试自己封装字节流解析模块，按需解析上行数据，一来可以提升数据分析的性能（并行业务和数据增量分析操作），二来可以用最小代价处理异常请求（当发现不满足业务规范时，则立刻丢弃后续所有的数据），这块实现被叫做LazyParser，主要的实现重点就是最小化数据缓存来进行并行业务和数据解析操作，上线后效果不错，整个系统平均处理时间从10ms降低到了4ms。（包含了异常处理的优化和解析性能的提升）
⏱ 2024-07-10 20:26:33 ^680318-22-3350-3612
📌 异步批量数据外写的设计（多线程守护各自的一块Buffer页，定时外刷或者满页外刷），这样在双写的情况下，单机的Load也没有超过0.7。
⏱ 2024-07-12 09:26:25 ^680318-22-4354-4422
📌 开放平台稳定性受制于任何一个业务方，这是不可接受的
⏱ 2024-07-12 09:27:15 ^680318-22-4771-4796
📌 考虑集群拆分，即将重要业务和不重要业务拆分，但考虑到实施成本（不同服务的利用率差异很大）和业务隔离是否彻底（重点业务也会相互影响
⏱ 2024-07-12 09:27:37 ^680318-22-4806-4870
📌 花了两个月时间断断续续地优化集群结构设计和单机处理能力
⏱ 2024-07-15 14:54:32 ^680318-22-8165-8192
📌 简单地说，包括四个方面：充分利用多核能力用计算换内存；磁盘换内存，用并行设计来保证整体业务时间消耗不变甚至减少；Slave Shuffle来减少Mater的合并压力；数据压缩减少数据传输消耗和内存占用。
⏱ 2024-07-15 14:54:36 ^680318-22-8251-8352
📌 后端通过事件驱动的模式主动推送内部消息给外部，避免外部轮询业务接口。这个设计最重要的一点就是如何用最有效且最少的线程来守护多个长连接，支持到后端事件驱动的数据下行，如果给每一个长连接支持一个数据推送守护线程，即时性自然最高，但代价就是消耗众多空置连接的守护线程（详细内容见Blog）。
⏱ 2024-07-15 14:56:36 ^680318-22-8665-8807
📌 另一方面，开放平台安全体系的构建成为2012年的重点，从两个角度对安全做了全方位的控制。第一，用户。用户授权更细化了授权操作范围（细粒度到了数据范畴），授权时长。所有的信息可监控、归档、快速定位，我们内部叫做Top Ocean，简单说来就是对所有的访问日志做归档，归档的载体是块状文件，归档时对块状文件的所有记录按照需求建立索引，然后保留索引，上传本地文件到远端分布式文件系统备份。实时的监控服务调用和应用访问，授权异动
⏱ 2024-07-15 15:05:15 ^680318-22-10420-10663
📌 第二，第三方应用。采用监控集群对所有ISV的服务器做安全扫描，对普通的Web安全漏洞做扫描，对应用的可用性和响应时间做监控。同时，正式启动“聚石塔”项目，提供弹性计算和存储能力及可靠的安全网络环境给ISV，帮助ISV提供自身应用的安全性。
⏱ 2024-07-15 15:05:26 ^680318-22-10697-10816
第6章 我在淘宝这八年
📌 用户在银行付款后，未必能通知到支付宝，支付宝收到通知后，未必能通知到淘宝，于是用户的钱没了，淘宝的系统上却显示未付款
⏱ 2024-07-16 09:11:29 ^680318-23-3142-3200
📌 接连两个项目都挂了，我反倒不怎么悲伤了，心态反倒轻松了许多，明白了一个道理：很多东西，不是你努力就能成功的，也许应了那句话“谋事在人，成事在天”。
⏱ 2024-07-16 09:22:58 ^680318-23-6970-7043
📌 于是商品表中增加了这样一个字段，每增加一个PV，这个字段就要更新一次，发布上去一个小时后，数据库就挂掉了，撑不住这么高的更新。数据库撑不住怎么办？一般的缓存策略是不支持实时更新的，这时候多隆大神想了个办法，在Apache上面写了一个模块，这个数字根本不经过下层的Web容器（只经过Apache）就写入一个集中式的缓存区了，这个缓存区的数据再异步更新到数据库
⏱ 2024-07-16 09:26:28 ^680318-23-7927-8105
📌 接口测试的思路很简单，就是用测试代码来验证系统代码的逻辑是否正确。但做起来很难，最大的困难就是被测代码太“拥抱变化”了，三天两头地变，测试代码经常会失效；另一个问题就是要验证一个业务逻辑，也许要用10倍的测试代码才能覆盖
⏱ 2024-07-16 09:40:30 ^680318-23-12304-12414
📌 接口测试白皮书
⏱ 2024-07-16 09:41:34 ^680318-23-12669-12676
📌 我认为团队的成长是M的第二等大事（第一等是干好活），
⏱ 2024-07-16 09:44:35 ^680318-23-13987-14013
📌 在线学习大概有四种模式：视频、文档、直播、问答
⏱ 2024-07-19 11:30:54 ^680318-23-20102-20125
📌 在线文档的难度不在于产生内容，而在于内容的吸引力，PPT很难承载有实质内容的东西，PDF太长的话又没有人看
⏱ 2024-07-19 11:31:00 ^680318-23-20292-20345
📌 早期种子用户的培养和优质内容的推送
⏱ 2024-07-19 11:31:08 ^680318-23-20456-20473
📌 在传统行业，知识或许可以管理，但在互联网企业里，知识的更新迭代非常频繁，等你理出来刚要管的时候，它已经失效了。我认为互联网行
⏱ 2024-07-19 11:31:58 ^680318-23-20948-21010
📌 业的知识不是要去管理的，而是要让隐性的知识显性化，在它的生命周期里迅速传播出去。我们不需要等它沉淀，只需要让足够多的知识流动起来，就能创造巨大的价值。
⏱ 2024-07-19 11:32:01 ^680318-23-21010-21085
📌 我们这些大学之间有些“民间”的沟通，但从来没有打通过资源，也没有公用过一个平台，可以说是各自为战，现在都“One Company”了，自然也要打通一下。于是在老板来了三个月后，我们启动了一个“小三通”和一个“大三通”项目，“小三通”就是培训资源的打通，包括课程、讲师、解决方案的互通有无；“大三通”是培训平台的打通，培训的资源放进同一个平台里
⏱ 2024-07-19 11:32:35 ^680318-23-21227-21398
📌 常春藤计划
⏱ 2024-07-19 11:32:56 ^680318-23-21917-21922
📌 有想法没用，要有产品出来，甚至有产品还不够，要能够迅速推向市场
⏱ 2024-07-19 11:33:17 ^680318-23-22115-22146
第7章 牛P列传
📌 ，企业和个人也是这样一个关系：一个水平很高的人，找不到合适的平台，就难以发挥自己的价值；一个蓬勃发展的企业，找不到合适的人才，其前景也会堪忧
⏱ 2024-07-19 11:34:44 ^680318-24-452-522
正明——集团核心系统高级研究员
📌 几年工作的整体规划思路就是为淘宝网打造一个高性能、高可扩展、高可用、低成
⏱ 2024-07-19 13:33:41 ^680318-25-4636-4672
📌 本的基础平台，基本上是在这四个维度上不断深入优化
⏱ 2024-07-19 13:33:48 ^680318-25-4672-4696
📌 淘宝的CDN用的是商用的调度负载均衡器Citrix NetScaler，这是当时业界最好的负载均衡器
⏱ 2024-07-19 13:33:59 ^680318-25-4700-4750
📌 小图片造成的请求数特别多，万兆网卡的流量只能到3GB/s，一旦流量超过3GB/s，若到了4GB/s，系统就会崩溃。在CDN系统中，图片处理的挑战最大，相比视频那种连续的数据，图片这种很小的、比较离散的数据对硬盘的访问要求很高
⏱ 2024-07-19 13:34:25 ^680318-25-4795-4907
📌 。所以这就是商用系统的问题：在特别的负载情况下，它是不适用的。
⏱ 2024-07-19 13:36:37 ^680318-25-5100-5131
📌 。这个项目我们以后还会持续优化，因为优化无止境嘛，我们追求的目标是更好的用户体验，更短的响应时间，同时还要花更少的钱
⏱ 2024-07-19 13:37:15 ^680318-25-5371-5429
📌 在规模上来之后，这些架构都要重新思考
⏱ 2024-07-19 13:44:20 ^680318-25-6684-6702
📌 找到自己感兴趣的，花时间投进去，通过实践后的知识积累比只看书本有用得多。我看过一本操作系统方面的英文书，其中引用了一段中国人的格言：“I hear and I forget.Isee and I remember. I do and I understand”，这句话给我留下非常深刻的印象。是荀子说的“不闻不若闻之，闻之不若见之，见之不若知之，知之不若行之。” ^680318-25-7780-7962
- 💭 知行合一
- ⏱ 2024-07-19 13:47:17
正祥——淘宝高级研究员，OceanBase项目负责人
📌 需求是在一直变化的，今天的数据规模对关系数据库提出了严峻的挑战
⏱ 2024-07-19 13:56:35 ^680318-26-2060-2091
📌 ，其实这个NoSQL可以说“No SQL”或者“Not Only SQL”，我更倾向于叫后者，咱不能否定SQL。我们要解决的问题是数据规模的问题，数据库本质上是一个单机系统，即便是做了分库分表，这些也没有改变的是单机系统的本质。单机系统导致它的数据规模和处理能力都会有一定的限制
⏱ 2024-07-19 13:56:49 ^680318-26-2110-2249
📌 因此，我们要解决的问题就是在淘宝的数据规模不断增长的情况下，提供高容量、低成本、高一致性、高可靠的数据存储和访问服务。
⏱ 2024-07-22 09:35:58 ^680318-26-2546-2605
📌 关系数据库的数据规模受限的根本原因是目前的关系数据库尽管有各种方式的扩展，但本质上是单机系统。
⏱ 2024-07-22 09:36:08 ^680318-26-2710-2757
📌 OceanBase最好的地方就是具备事务，数据一致性很好
⏱ 2024-07-22 09:39:03 ^680318-26-3202-3230
📌 成本最高的其实还不止是这些设备，而是网络带宽和机房机架等的成本。若减少机器的数量，会降低这方面的成本。淘宝的业务在高速增长，数据量和访问量在加速增长，但电力和机房资源不可能同步高速增长，从现在起，我们就必须在提升服务能力和性能的同时，降低服务器的使用量，否则不仅是成本令我们无法承受，机房和机架也无法找到。此外，从节省能源的角度来说，我们也必须要低碳环保。
⏱ 2024-07-22 09:41:38 ^680318-26-3898-4076
📌 站在巨人的肩上做事，把手上事情做好就成
⏱ 2024-07-22 09:42:13 ^680318-26-4278-4297
📌 在这点上，我特别喜欢马总的理念——做公司要赚钱，但阿里从不把赚钱作为第一目标，我们服务好了客户，客户赚了钱，我们一定会得到自己应得的一份。在个人成长问题上也是类似的道理，这就是，一个人如果把做事、做成事作为主要目标，该他得到的东西，一定会顺理成章的、水到渠成地得到，但是，如果把上升作为主要目标，做同样的事，结果就会完全不一样。一句话，你的心态会最终决定你的成就
⏱ 2024-07-22 09:43:15 ^680318-26-4471-4652
📌 而那种朴素的只想把一件事情做好的感觉，也深受他的影响。
⏱ 2024-07-22 09:45:54 ^680318-26-4890-4917
📌 我觉得百度其实不如淘宝重视技术，KPI导向的文化很重，各部门之间的协作和配合比较难（这一点淘宝要好不少），不同部门、不同项目的开发人员做了不少有差别但其实比较类似的东西，看起来个体效率高，但整体效率未必高，这可能是百度加班很严重的原因之一。
⏱ 2024-07-22 09:49:15 ^680318-26-5700-5820
放翁——淘宝开放平台项目负责人
📌 为一个架构师，经常会有一种失落感，
⏱ 2024-07-22 13:57:17 ^680318-28-2443-2460
📌 在公司里做事，很多人是自己做还好，但要跟别人一起做，跟各个部门协作的时候，就遇到麻烦了。对于技术人员来说，这也是需要成长的。
⏱ 2024-07-22 13:56:56 ^680318-28-2703-2765
📌 ，跟其他公司做开放平台一样碰到的问题，就是每个部门都希望去做开放，这个时候开放平台响应够不够快，服务够不够好，会使得别人愿不愿意通过你的开放平台来做。我们发现百度、腾讯、盛大也都这样，开放平台希望自己是全公司统一的开放平台，但事实上是每个部门都在做开放平台。现在我们的思想也放开了，与其是通过行政的手段去堵，去要求别人，还不如自己把产品做好，这样这些部门自然而然会去想他要不要花这么大代价去做这个事情。我在想，做技术产品需要转变一个思路，靠行政和强制措施要求别人用你的东西，短期有效，但长期来看，还是要看技术过不过硬，有没有站在用户的角度考虑问题，产品做得够不够好。
⏱ 2024-07-22 13:59:04 ^680318-28-2796-3079
📌 技术委员会在级别P7～P9的定义中，要求P7级的人员要对一个小的产品或团队有方向性的指导，P8级就要求在一个大部门或公司级的产品上有方向性的指导，P9级要求除了考虑自身的产品之外，还要站在公司的角度考虑自身的产品对公司的发展有什么帮助
⏱ 2024-07-22 14:00:03 ^680318-28-3217-3334
📌 在开放平台不能只考虑开放平台本身发展得好不好，要看它对其他部门或整个公司的发展有什么帮助
⏱ 2024-07-22 14:00:49 ^680318-28-3340-3384
📌 从技术上看，我都是贴近实际的问题来找突破点，解决了问题，技术就掌握了。说实在的，现在也会遇到一些瓶颈，到一定阶段，我的技术已经足够快了，但是业务上还没有跟上，这时很多技术人员会觉得困惑
⏱ 2024-07-22 14:01:08 ^680318-28-3535-3627
📌 有两点，技术人员首先会关心技术好不好，若技术不好，讲得再好都会感觉有些浮
⏱ 2024-07-22 14:03:01 ^680318-28-4657-4693
📌 所以每次我都会讲些技术方面的内容，不是具体的实现细节的技术，而是通用的一些思想和方法。另外一点就是我对开放平台的一种信仰和思想，我能通过开放平台为淘宝做什么。这样其他人会感受到听这个课是有帮助的。
⏱ 2024-07-22 14:03:15 ^680318-28-4694-4792
📌 第一个是做事要自己思考后再去问别人，而不是一遇到问题就找人求助。第二个是不断地打破自己的一些想法，你不要担心自己今天已经做了50%的工作，要是推倒重来，前面的事情都白干了。
⏱ 2024-07-22 14:04:24 ^680318-28-4869-4955
📌 任何一个公司，不管用什么手段，都做不到绝对公平，最终只会有小部分人得到机会。这个时候去抱怨、愤怒都没有用的，只有自己不断地努力争取机会才行。
⏱ 2024-07-22 14:05:01 ^680318-28-5323-5393
吴翰清——阿里云集团信息安全中心高级安全专家
📌 这个圈子里的人就几个去向，要么去大一点的互联网企业，要么去安全厂商，要么被国家队招去做国家安全方面的工作
⏱ 2024-07-29 10:58:03 ^680318-29-2884-2936
云铮——数据平台与产品部资深技术专家
📌 说到我对变动的看法，我一直是一个喜欢挑战的人，我认为有变动是好事，这会让人经历更多，而且应该主动创造变化，比如平台稳定了，系统理顺了，是不是就应该刀枪入库，马放南山了？不是的，应该从更深、更全的角度去提出新的要求和新的梦想，并进一步去实现。
⏱ 2024-08-12 09:47:20 ^680318-30-4568-4688
📌 兴趣是最好的老师，坚持是达到梦想的唯一途径，当然，在个人发展的不同阶段寻找到合适的导师很重要，看准方向会事半功倍。在刚刚参加工作还没有形成自己的判断时，方向有两个来源，一个是个人的兴趣，一个是找一个你非常佩服且能掌握未来方向的人，当然，如果这两者正好重合，那么剩下的就是脚踏实地坚持。
⏱ 2024-08-12 09:48:15 ^680318-30-4772-4914
淘宝传奇工程师多隆的程序世界
📌 多隆说他知识经验的积累主要归功于在淘宝业务发展的过程中，他遇到了各种各样的问题。这些问题促使他不断学习解决问题的各种技术，他和淘宝一起成长。
⏱ 2024-08-13 19:47:31 ^680318-32-863-933
📌 一个计算机工程师该以怎样的态度和方式来工作和学习？多隆的一条朴素的建议或许可以很好地解答：“发现问题，解决问题，不要绕开问题的本身；多做事情，不会吃亏，即使不是你的事情。”
⏱ 2024-08-13 19:51:39 ^680318-32-1886-1972
📌 始终保持对代码的那份单纯的热爱，保持对技术的专注和钻研；别人把工作当工作，他把工作当事业——这就是多隆的程序世界。
⏱ 2024-08-13 19:51:46 ^680318-32-2053-2110
读书笔记
淘宝文件系统——TFS
划线评论
📌 第三，在一定规模效应的基础上，研发的投入都是值得的。 ^37992928-7RqbtAxRN
- 💭 商业系统和自研系统，随着规模越来越大，自研系统的投入会有优势。
- ⏱ 2024-05-24 09:20:34
划线评论
📌 TFS，太神奇了！（猜猜是哪家） ^37992928-7RqbLx7jL
- 💭 很明显是腾讯，Tencent，大写字母也是 T。
TFS(Tencent File System)是腾讯架构平台部自研海量文件系统，自2006年平台上线，经过多年不断技术演进，目前TFS承载了包括QZone相册、微信朋友圈图片、QQ邮件、微云、腾讯云COS等公司重要产品的数据存储，截止到2017年年初，TFS承载的数据突破1EB。（来源腾讯云开发者社区）
- ⏱ 2024-05-24 09:24:59
划线评论
📌 我们计算过，采用实时生成缩略图的模式比提前全部生成好缩略图的模式节约90%的存储空间。 ^37992928-7Rqdwbjb2
- 💭 如果不采用全部生成缩略图，不应该是节省 100% 的存储空间吗，都不用存储缩略图了。
- ⏱ 2024-05-24 09:51:44
淘宝KV缓存系统——Tair
划线评论
📌 这个产品带给我们的是新技术（AJAX、prototype框架）的尝试，以及新技术对用户操作习惯的改变，一定要慎之又慎。另外，还有一点没有总结好的教训，就是应对群体事件的时候，我们手足无措，在后来“招财进宝”和淘宝商城出现群体性事件的时候，我发现悲剧在重演 ^37992928-7RuM8RHNW
- 💭 这个产品带给我们的是新技术（AJAX、prototype框架）的尝试，以及新技术对用户操作习惯的改变，一定要慎之又慎。另外，还有一点没有总结好的教训，就是应对群体事件的时候，我们手足无措，在后来“招财进宝”和淘宝商城出现群体性事件的时候，我发现悲剧在重演
- ⏱ 2024-05-27 09:47:05
划线评论
📌 TBstore的分布式算法实现：根据保存的Key（关键字），对key进行Hash算法，取得Hash值，再对Hash值与总Cache服务器数据取模。然后根据取模后的值，找到服务器列表中下标为此值的Cache服务器。由Java Client API封装实现，应用无须关心。 ^37992928-7RuMFfmzA
- 💭 一致性hash
- ⏱ 2024-05-27 09:55:04
正明——集团核心系统高级研究员
划线评论
📌 找到自己感兴趣的，花时间投进去，通过实践后的知识积累比只看书本有用得多。我看过一本操作系统方面的英文书，其中引用了一段中国人的格言：“I hear and I forget.Isee and I remember. I do and I understand”，这句话给我留下非常深刻的印象。是荀子说的“不闻不若闻之，闻之不若见之，见之不若知之，知之不若行之。” ^37992928-7SNEhxApi
- 💭 知行合一
- ⏱ 2024-07-19 13:47:24