试读章节：第2章 大型网站及其架构演进过程
大型网站的特质
海量数据、高并发的访问量、本身业务和系统的复杂度
作者（淘宝技术总监）精炼地诠释了大型网站的特质，很到位
Session共享解决方案
这是分布式系统的第一个坑，作者给出了4种解决方案，听过和做过的区别就是后者可以回忆式地娓娓道来
1. Session Sticky：负载均衡器能够根据每次请求的会话标识来进行请求转发
缺点：
如果有一台 Web 服务器宕机或者重启，那么这台机器上的会话数据会丢失。如果会话中有登录状态数据，那么用户就要重新登录了。
会话标识是应用层的信息，那么负载均衡器要将同一个会话的请求都保存到同一个 Web服务器上的话，就需要进行应用层（第 7 层）的解析，这个开销比第 4 层的交换要大。
负载均衡器变为了一个有状态的节点，要将会话保存到具体 Web 服务器的映射。和无状态的节点相比，内存消耗会更大，容灾方面会更麻烦。
2. Session Replication：Web服务器之间则增加了会话数据的同步
缺点：
同步 Session 数据造成了网络带宽的开销。只要 Session 数据有变化，就需要将数据同步到所有其他机器上，机器数越多，同步带来的网络带宽开销就越大。
每台 Web 服务器都要保存所有的 Session 数据，如果整个集群的 Session 数很多（很多人在同时访问网站）的话，每台机器用于保存 Session 数据的内容占用会很严重。
3. Session 数据集中存储：把 Session 数据集中存储起来，然后不同 Web 服务器从同样的地方来获取 Session
缺点：
读写 Session 数据引入了网络操作，这相对于本机的数据读取来说，问题就在于存在时延和不稳定性，不过我们的通信基本都是发生在内网，问题不大。
如果集中存储 Session 的机器或者集群有问题，就会影响我们的应用。
4. Cookie Based：通过 Cookie 来传递 Session 数据
Cookie 长度的限制。我们知道 Cookie是有长度限制的，而这也会限制 Session 数据的长度。
安全性。Session 数据本来都是服务端数据，而这个方案是让这些服务端数据到了外部网络及客户端，因此存在安全性上的问题。我们可以对写入 Cookie 的 Session 数据做加密，不过对于安全来说，物理上不能接触才是安全的。
带宽消耗。这里指的不是内部 Web 服务器之间的带宽消耗，而是我们数据中心的整体外部带宽的消耗。
性能影响。每次 HTTP请求和响应都带有 Session 数据，对 Web 服务器来说，在同样的处理情况下，响应的结果输出越少，支持的并发请求就会越多。
环节数据读压力
读写分离、索引、缓存，都不陌生，倒要看看此书里是怎个实现
采用数据库作为读库：读写分离、主从复制：主库写、从库读
搜索集群（Search Cluster）：一种是按照全量/增量划分，一种是按照实时/非实时划分
全量方式用于第一次建立索引（可能是新建，也可能是重建），而增量方式用于在全量的基础上持续更新索引。当然，增量构建索引的挑战非常大，一般会加入每日的全量作为补充。
这个办法确实不错 应该是不断实践和群体智慧
数据缓存 Key-Value
页面缓存 把渲染与缓存的工作结合在一起
讲到页面缓存，我很疑惑为什么作者没有提到varnish
数据库分离
这项淘宝的人总分享 烂大街了 不过确实是淘宝的法宝
专库专用，数据垂直拆分：把数据库中不同的业务数据拆分到不同的数据库中
不同业务的数据从原来的一个数据库中拆分到了多个数据库中，那么就需要考虑如何处理原来单机中跨业务的事务。一种办法是使用分布式事务，其性能要明显低于之前的单机事务；而另一种办法就是去掉事务或者不去追求强事务支持，则原来在单库中可以使用的表关联的查询也就需要改变实现了。
垂直拆分后的单机遇到瓶颈，数据水平拆分：把同一个表的数据拆到两个数据库中
应用系统需要解决 SQL 路由的问题
主键的处理
一些查询需要从两个数据库中取数据，如果数据量太大而需要分页，就会比较难处理了
又一套淘宝特色的分布式道路
服务化和消息中间件解决分布式系统的通信问题