其实这是一本2012年的老书，5年的时间对于互联网技术来说，已经可以是另一个纪元了。但是当我重新翻看这本小书的时候，发现作者对概念的梳理，是很有借鉴之处的。去年有一段时间有事没事就会在youtube上看system design的视频，怎么设计short url，怎么设计Twitter，怎么设计Uber。现在重读这本书的时候我翻出那些视频，发现这本5年前的“老”书里，其实就有几乎所有这类问题的答案和思路。考虑到成书需要的时间，也许我可以很有把握的做结论，中国互联网企业的技术应用、解决一线问题的能力，其实是非常优秀的。
在这里把这本书的笔记写一写，与各位同仁共勉。为了理顺逻辑，我调整了一下知识点的顺序。
另：本文中使用的图片均为原书截图，如果你喜欢请购买原版图书支持作者。我买的就是正版！
关于大型网站
大型网站是相当于企业级应用来说的，特点有
- 高并发，大流量
- Google每天需要处理35亿条搜索
- 淘宝双十一第一分钟的独立访问用户就是千万级别
- 高可用
- 海量数据
- 用户分布广泛，网络情况复杂
- 安全环境恶劣
大型网站追求的性能指标
可用性 availability
在服务器宕机时，服务和应用是否依旧可用。网站使用的商用服务器硬件的设计目标本身并不保证高可用性。必须在系统设计层面予以考虑。
伸缩性 scalability
定义：往集群中加入服务器的手段，缓解并发访问压力的难易程度
负载均衡
- 技术
- HTTP重定向负载均衡：需要两次请求才能完成一次访问，性能较差。
- DNS域名解析负载均衡：DNS缓存不受网站控制，可能会解析到某个已经下线的服务器，导致网站无法访问。一般作为一级负载均衡，就是说解析得到的服务器是提供负载均衡的内部服务器，而不是直接提供服务的应用服务器。
- 反向代理负载均衡：可能会成为单点瓶颈
- IP层
- 数据链路层
- 算法
- Round Robin, RR
- Weighted Round Robin, WRR
- Random
- Least Connection
- Source Hashing
不同的服务器集群的伸缩性
- 对于无状态的应用服务器集群一般较容易
- 缓存服务器集群加入新服务器后可能会导致缓存路由失效，导致大部分缓存数据都无法访问
- 余数Hash算法可能会导致加入新缓存服务器时，有N/(N+1)的缓存无法被再次命中
- 使用一致性Hash算法
- 关系型数据库很难做到大规模集群的伸缩性
- Cobar：将应用层提交的查询分解为多条SQL给不同的数据库服务器执行。最后合并结果。
- GreenPlum：支持跨服务器的Join操作。但延时比较长。
- NoSQL数据库一般先天就是为伸缩性设计的
扩展性 extensibility
满足功能需求的难易程度。一般使用事件驱动的架构或分布式服务实现。
安全性 security
大型网站的演化发展历程
任何大型网站都是从小网站进化出来的：
阶段 1
应用程序、文件、数据库都在同一台服务器上
阶段 2
应用和文件、数据分离。使用三台专职服务器：
- 文件服务器：执行大量业务逻辑，需要CPU优化的硬件
- 数据库服务器：磁盘读写和缓存读写，需要快速的硬盘和内存
-
文件服务器：大硬盘
阶段 2
阶段 3
数据库成为瓶颈。加入对最hot的20%的数据缓存：
- 应用服务器上的本地缓存（大小受限）
-
专门的分布式缓存服务器集群上的远程缓存
阶段 3
阶段 4
应用服务器成为瓶颈。将应用服务器扩展为集群。
此时的问题：
- Session管理：4种方式
- 复制：服务器之间同步所有session。资源利用率太低。
- 绑定：利用load balancer的源地址Hash，确保同一IP的请求被分发到同一服务器。可用性目标很难达到，一旦某台服务器宕机，它维护的所有session就会丢失
- Cookie记录：不少网站采用。但受限cookie的大小，并且如果用户关闭浏览器的cookie功能，session就将无法工作。
-
专用session服务器：将应用服务器分为有状态和无状态部分。有状态的部分用专门的session服务器来维护。一般来说redis是一个很好的选择。
阶段 4
阶段 5
对数据看的写操作和未命中缓存的读操作，在用户达到一定规模后使得数据库再次成为瓶颈。这时启用主从备份功能：
- 写数据直接写到主数据库
- 主数据库通过主从备份机制把写数据更新到从数据库
-
读操作读取从数据库
阶段 5
阶段 6
随着网站用户群扩散，特定地区的用户访问网站会遇到性能问题。此时开始对前端性能进行优化，启用CDN和反向代理
阶段 7
单机数据库和文件系统不能满足性能和高可用性需求，启用分布式数据库和分布式文件服务器：
- 分布式存储系统的三类故障：
- 瞬时鼓掌：网络中断、服务器GC等，可重试后自行恢复
- 临时故障：交换机宕机、网卡松动、内存损坏、CPU过热等，需要人工干预，持续几十分钟到几个小时
- 永久故障：硬盘损坏
- 使用备份和冗余
- 服务器宕机下的失效转移：确认失效 -> 访问转移 -> 数据恢复
- CAP原理：可用性、某种程度上的数据一致性、伸缩性之间的权衡
- 强一致：各个副本数据总是一致的，对更新和读操作的响应也是一致的
- 用户一致：各个副本的数据可能是不一致的，但是用户一旦访问数据，就会通过纠错和校验机制确保用户得到的数据是一致正确的
-
最终一致：各个副本的数据可能是不一致的，用户得到的数据也可能是不一致的（同一个用户连续访问，或者多个用户同时访问，结果不同）。但是系统经过一段时间的自我恢复和修正，数据最终达到一致。
阶段 7
阶段 8
网站业务越来越复杂，对搜索和存储的需求也越来越复杂。此时引入NoSQL和非数据库查询技术，如搜索引擎。
阶段 9
业务场景复杂度与日俱增，此时开始采取分而治之的手段把网站业务拆分成不同的产品线。技术上网站被拆分成多个独立维护的应用。应用之间通过如消息队列等手段通信。
阶段 10
随着业务拆分越来越小，应用系统的整体复杂程度急剧上升，部署和维护越来越困难。此时采取分布式服务架构，把公共的可复用业务提取出来独立部署
