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

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

注：本文内容来自互联网，旨在为开发者提供分享、交流的平台。如有涉及文章版权等事宜，请你联系站长进行处理。