第0章 引言：光棍节的狂欢
第1章 个人网站
第2章 个人网站的升级
第3章 企业级Java网站
第4章 创造技术
1、raid5做数据冗余
2、元数据结构很简单，而在图片的保存文件名上暗藏一些元数据信息，例如，图片的大小、时间、访问频次等，包括所在的逻辑块号
3、对象存储是指什么？
4、（“我的淘宝”的复杂的前端交互，看似很炫，结果很糟。说明）新技术（AJAX、prototype框架）的尝试，以及新技术对用户操作习惯的改变，一定要慎之又慎。
5、在决定采用ESI（Edge Side Includes）之前，多隆试用了Java的很多Cache，但都比较重，后来用了Oracle Web Cache，也经常挂掉，Oracle Web Cache也支持ESI，由此多隆发现了ESI这好东东。ESI是一种数据缓冲/缓存服务器，它提供将Web网页的部分（这里指页面的片段）进行缓冲/缓存的技术及服务。ESI使用基于 XML的标记语言，指定想要缓冲的页面部分，从而区分页面中的动态部分和静态部分，针对其特点，可以制定不同的缓存策略。
6、（“招财进宝”）我们的商品表里增加了这样一个字段，每增加一个PV，该字段就要更新一次。发布一个小时后，数据库就挂了。数据库撑不住怎么办？一般的缓存策略是不支持实时更新的，这时候多隆大神想了个办法，在Apache上写了一个模块，这个数字根本不经过下层的WebApp容器（只经过Apache）就写入一个集中式的缓存区了，这个缓存区的数据再异步更新到数据库。
第5章 分布式电子商务操作系统
1、类目的分类问题
⑴、先分男女装，再分款式、品牌和材质呢？还是先分品牌，再分款式、材质和男女装呢？弄得很乱。这时候，一位大侠出来了----一灯，他说品牌、款式、材质等都可以叫做“属性”，“属性”是类似Tag（标签）的一个概念，与类目相比更加离散、灵活，这样也缩减了类目的深度。从系统的角度来看，我们建立了“属性”这样一个数据结构，由于除了类目的子节点有属性外，父节点也可能有属性，于是类目属性合起来也是一个结构化的数据对象。
⑵、淘宝的运营主要就是类目的运营，什么季节推什么商品，都要在类目属性上调整。调整到哪个类目，所属商品的专家就要编辑一次自己的商品，随着商品量的增长，他们肯定
受不了。到了2008年，我们研究了超市里前后台商品的分类，发现超市前台商品可以随着季节和关联来调整摆放场景，后台仓库里要按照自然类目来存储，二者密切关联，却又相互分开。这样专家发布商品选择的是自然类目和属性，淘宝前台展示的是根据运营需要摆放商品的类目和属性。
2、高性能服务框架HSF（High-speed Server Framework）---解决服务调用问题
服务的提供者启动时通过HSF框架向ConfigServer注册服务信息（接口、版本、超时时间、序列化方式等），这样ConfigServer上面就定义了所有可供调用的服务（同一个服务
可能有不同的版本）；服务调用者启动的时候向ConfigServer注册对哪些服务感兴趣（接口、版本），当服务提供者的信息变化时，ConfigServer向相应的感兴趣的服务调用者推送新的服务信息列表；调用者在调用时则根据服务信息列表直接访问相应的服务提供者。
3、消息中间件Notify
2005年，支付宝的架构师鲁肃提出用MQ（Message Queue）的方式来解决不同系统的通信问题。但是发现消息数量上来之后，常常造成拥堵，消息的顺序也会出错，在系统挂掉的时候，消息也会丢掉，这样非常不保险。然后鲁肃提出做一个系统框架上的解决方案，把要发出的通知存放在数据库中，如果实时发送失败，再用一个时间程序来周期性地发送这些通知，系统记录下消息的中间状态和时间戳，这样保证消息一定能发出，也一定能通知到，而且通知带有时间顺序，这些通知甚至可以实现事务性的操作。
4、分布式数据访问层TDDL（位于Hibernate与Oracle数据库之间）
⑴、三个主要特性：
①、数据访问路由---将针对数据的读写请求发送到最合适的地方；
②、数据的多向非对称复制----一次写入，多点读取；
③、数据存储的自由扩展---不再受限于单台机器的容量瓶颈与速度瓶颈，平滑迁移。
⑵、TDDL1.0（Taobao Distributed Data Layer）
①、对外统一数据访问；
②、支持缓存、文件存储系统；
③、能够在Oracle和MySQL之间自由切换；
④、支持搜索引擎。
涉及到相关的开源软件：Amoeba Porxy和Cobar。
⑶、TDDL2.0
数据层代码被业务层侵染；
⑷、TDDL3.0~4.0
①、功能可以做得不那么“漂亮”，但必须减少中间环节，真正做到了实用、干净、简洁；
②、不需要的功能为什么要放到流程里？增加的复杂度会导致更多的问题；
③、规则引擎/切分规则可以用配置的方式帮助业务隔离具体的数据库地址与用户的业务逻辑。将代码做了逻辑切分，将单机主备切换和数据源管理独立了出来，这样，可以针对不同的业务需求，给予不同的逻辑分层；
Rtools/JADE作为数据库运维平台的组件被提了出来，极大地提升了用户在使用单机数据源和多机数据源时的效率。
5、Session框架
⑴Session概述
Session可提供客户端和服务系统之间必要的交互。因为HTTP协议本身是无状态的，而Session就是用来解决服务端和浏览器的保持状态的解决方案。用户向服务器发送第一个请求，服务器为其建立一个Session，并为此Session创建一个标识，用户随后的所有请求都应包括这个标识，服务器会校对这个标识号以判断请求属于哪个Session。Session在默认情况下，直到浏览器关闭，才会结束。
Session中存储的内容包括用户信息：昵称、用户ID、登录状态等。
⑵、问题及常见解决方式：
当网站是一个集群的时候，同一个用户的两次请求可能被分配到两台不同的服务器上，怎样保证两次请求中存取的Session值一致呢？还有一个问题：对于一个具有上亿个访问用户的系统来说，当大部分用户的Session信息都存储在服务端时，要在服务端检索出用户的信息效率就非常低了，如何解决服务端Session信息的管理？
常见的两种解决方案：
①、硬件负载，将用户请求分发到特定的服务器----成本较高；
②、Session复制，就用户的Session复制到集群内所有的服务器---性能差，难扩展。
⑶、TSession框架的解决方案：
要么用客户端Cookie来解决问题（访问量较小），要么用服务器端的集中缓存区（Tair）的Session来解决登录问题（当有上亿个请求时，即使每个Cookie只有2KB，其带来的流量也非常可观）。
6、开放平台(http://blog.csdn.net/cenwenchu79)
⑴、第一步：内部架构服务化。
内部服务不好做隔离，开放就意味着风险不可控。服务单元Bundle的粒度控制，服务之间的依赖管理，性能与规范的冲突，调试与的平衡。
⑵、初期要解决的三个问题：①、服务路由。（外部可以获取内部信息）-----写一个高效的HttpAgent；②、服务接口标准化。（统一方式地获得各种标准化信）----就是对象文本化（JSON，XML）；③、授权。（外部合法地获取内部信息）----OAuth协议。
⑶、后台应用不稳定导致平台整体不稳定的问题（某一个业务出问题会导致整个平台出问题）：HTTP服务异步化 + 事件驱动 + 虚拟线程池隔离。
①、将前端容器线程和业务处理隔离。（类似NIO和BIO的设计差异）
②、业务处理如果依赖于外部系统，则采用事件驱动的方式来减少线程等待，同时提高线程占用资源的利用率。（在实现的时候必须根据依赖系统水泵时间占总时间的比例看是否需要事件驱动，事件驱动带来的切换水泵是比较大的）。
③、通过一个大的线程池虚拟设置不同的业务可消耗的最大资源数，来充分共享资源在异常情况下限制业务占用过多的资源（任务处理开始排除，而非无度地占用资源）。
⑷、comet技术
Comet原先主要用于CS结构的应用搬到互联网上，因为不能用TCP的长连接，所以不得不用HTTP的长连接来替代原来的模式，可以通过HTTP长连接方式推送消息到外部ISV（独立软件开发商）的模式引起了我们的注意。因此，我们决定将Jetty7上的封装近一步升级，支持comet长连接方式，后端通过事件驱动的模式主动推送内部消息给外部，避免外部轮询业务接口。这个设计最重要的一点就是如何用最有效且最少的线程来守护多个长连接，支持到后端事件驱动的数据下行。每个长连接支持一个数据推送守护线程，即时性自然最高，但是却消耗众多空置连接的守护线程（可参考blog）
第6章 我在淘宝这八年
1、问题：系统分层多了，出错的概率大了，但功能测试无法探测到下层。很难深入到代码级别去做测试。
解决方案：做单元测试，但单元测试让工程师自己去做，我们做再往上一层接口的测试。
挑战：①、被测代码变化很快，测试代码经常失效； ②、验证一个业务逻辑，也许要用10倍的测试代码才能覆盖。
第7章 牛P列传
1、放翁：
有些业务会要求开一些白名单、黑名单、特殊通道之类的东西，而作为基础服务，我又要保证它的完整性和统一性。作为一个架构师，经常会有一种失落感，有时候发现我们做出来的东西有可能没有办法实施。后来我有一些感悟，真的需要找到一个业务点，把技术做深，去解决一个个的问题，然后这个平台的效果才能体现出来。即既做技术架构师，也做业务架构师。
从技术上看，我都是贴近实际的问题来找突破点，解决了问题，技术就掌握了。
2、我认为有变动是好事，这会让人经历更多，而且应该主动创造变化，比如平台稳定了，系统理顺了，是不是就应该刀枪入库，马放南山了？不是的，应该从更深、更全的角度去提出新的要求和新的梦想，交进一步去实现。