其实这是一本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

应用程序、文件、数据库都在同一台服务器上

阶段 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

对数据看的写操作和未命中缓存的读操作，在用户达到一定规模后使得数据库再次成为瓶颈。这时启用主从备份功能：

1. 写数据直接写到主数据库
2. 主数据库通过主从备份机制把写数据更新到从数据库

3. 读操作读取从数据库

   
   阶段 5

阶段 6

随着网站用户群扩散，特定地区的用户访问网站会遇到性能问题。此时开始对前端性能进行优化，启用CDN和反向代理

阶段 6

阶段 7

单机数据库和文件系统不能满足性能和高可用性需求，启用分布式数据库和分布式文件服务器：

• 分布式存储系统的三类故障：
  • 瞬时鼓掌：网络中断、服务器GC等，可重试后自行恢复
  • 临时故障：交换机宕机、网卡松动、内存损坏、CPU过热等，需要人工干预，持续几十分钟到几个小时
  • 永久故障：硬盘损坏
• 使用备份和冗余
• 服务器宕机下的失效转移：确认失效 -> 访问转移 -> 数据恢复
• CAP原理：可用性、某种程度上的数据一致性、伸缩性之间的权衡
  • 强一致：各个副本数据总是一致的，对更新和读操作的响应也是一致的
  • 用户一致：各个副本的数据可能是不一致的，但是用户一旦访问数据，就会通过纠错和校验机制确保用户得到的数据是一致正确的

  • 最终一致：各个副本的数据可能是不一致的，用户得到的数据也可能是不一致的（同一个用户连续访问，或者多个用户同时访问，结果不同）。但是系统经过一段时间的自我恢复和修正，数据最终达到一致。

    
    阶段 7

阶段 8

网站业务越来越复杂，对搜索和存储的需求也越来越复杂。此时引入NoSQL和非数据库查询技术，如搜索引擎。

阶段 8

阶段 9

业务场景复杂度与日俱增，此时开始采取分而治之的手段把网站业务拆分成不同的产品线。技术上网站被拆分成多个独立维护的应用。应用之间通过如消息队列等手段通信。

阶段 9

阶段 10

随着业务拆分越来越小，应用系统的整体复杂程度急剧上升，部署和维护越来越困难。此时采取分布式服务架构，把公共的可复用业务提取出来独立部署

阶段 10