指标
可扩展性 Scalability
关键在于当工作量大幅增加时，尽量减少系统性能的损失。
水平扩展 Horizontal Scaling
添加更多的机器。
垂直扩展 Vertical Scaling
提高已有机器的性能（CPU、内存）。
可靠性 Reliability
尽量减少系统宕机的概率，保证系统的良好运转。这个是分布式系统最核心的概念之一。我个人感觉有一点类似数据库中耐久性设计。
可用性 Availability
保证系统正常执行功能。
可用性和可靠性有一定差别。可靠性保证了可用性，但是反过来不成立。高可用的系统有可能暴露在某种风险中，在短期内未显现出来，用户体验良好，但殊不知在未来可能会导致灾难。
功效性 Efficiency
主要的评价标准是延迟(latency)和吞吐量(throughput)。
可管理性 Manageability
能够有效维护和管理。
负载均衡 Load Balancing
简介
负载均衡器能提高系统的响应能力和可用性，通常位于客户端和服务器之间，将输入分配给不同后端服务器。
优点
- 提升吞吐量
- 便于管理员分析瓶颈
- 减少宕机的组件，确保系统整体运转
健康检测 Health Checks
负载均衡器只把数据传输给正常运转的后端服务器。
平衡算法
最小连接法 Least Connection Method
发送给拥有最少活跃连接的服务器。适用场景是大量客户使用长连接，且连接不均衡的分布在不同服务器。
最短响应法 Least Response Time Method
发送给拥有最少活跃连接且最短响应时间的服务器。
最小带宽法 Least Bandwidth Method
发送给当前服务带宽最小的服务器。
循环法 Round Robin
按顺序分配。当然也可以给不同服务器加权。
IP哈希法 IP Hash
计算客户机IP地址的散列以将请求重定向到服务器。
冗余
为防止单个负载均衡器的宕机导致系统的宕机，需要有冗余。
缓存 Caching
应用程序服务器缓存 Application Server Cache
如果后端服务器有多个节点，相同的请求有可能会被分配给不同的服务器。这个时候，全局缓存和分布式缓存就有用武之地了。
内容分发网络 Content Distribution Network (CDN)
应用场景是网站有大量静态媒体。
缓存失效 Cache Invalidation
Write-through
同时更新缓存和后端DB。缺点是延时长。
Write-around
只写入后端DB。缺点是如果随后的读操作读的正好就是本次的写入，从后端再拿数据，会导致更高的延时。
Write-back
只写入缓存。缺点是无法保证可靠性，如果宕机，数据丢失。
缓存替换原则 Cache Eviction Policy
FIFO
LIFO
LRU
MRU
most recently used，与LRU正相反。
LFU
RR
random replacement。
数据分片 Sharding
划分方法 Partitioning Methods
水平划分
也被称为基于范围的分片(range based sharding)。把不同范围的数据以行为单位放到不同表里面。
缺点是容易导致不平衡。
垂直划分
将不同特征/字段放到不同地方。比如把所有用户的个人简介放到一个DB，把所有照片放到一个DB。
缺点是某个部分的DB可能需要更精细的划分。比如放照片的DB估计承受不了所有用户的访问。
基于目录的分区
创建一个查询功能的分片架构，类似做了一个映射。优势就是我们可以添加新的服务器进DB池而不让整个应用受到影响。
划分条件
基于键或散列的分区 Key or Hash-based Partitioning
将任意字段（一般是id）进行hash。
缺点是其固定了DB的总数（除非在增加DB时将所有数据重新进行hash）。解决办法是一致性哈希。
表分区 List Partitioning
每个分区都被分配了一组值，出现其中包含的值的数据就被存放在那个分区。
顺序分区 Round Robin
组合分区 Composite Partitioning
我们可以先使用表分区，再使用散列分区。
常见问题
Join和去范式 Denormalization
不支持多库做join。只能在采用去范式的方法，将数据放在一张表里面。但是这样容易带来数据不一致的问题。
引用完整性 Referential Integrity
在一个分片数据库中，外键这种约束很难被实施。只能在应用端的代码中检查。
重新平衡 Rebalancing
原因有很多：数据分布不平衡、某些分区负载过重。
基于目录的分区在重新平衡出现时能让系统较为平稳的度过。
索引 Indexes
简介
主要是为了提升查询的性能。功能类似图书馆建立一个找书的机制。索引使用频率低的话考虑删除。
缺点
- 降低数据更新和增填的效率。
代理 Proxies
简介
介于客户端和后端服务器的中间服务器。
优点
- 过滤请求，或者做加密解密这类简单的修改操作
- 缓存能满足大部分请求
类型
开放代理 Open Proxy
所有用户都可以使用。分为匿名代理(Anonymous Proxy)和透明代理两种(Transparent Proxy)。前者不会披露初始IP地址。后者主要用途就是缓存各种网站。
反向代理 Reverse Proxy
反向代理从一个或多个后端服务器获取信息，当把这些信息返回给客户时，表面上看起来是代理服务器直接提供给用户这些信息。
冗余和同步 Redundancy and Replication
主要防止由于某个部件失效导致整个系统的停摆。而当有多个节点存储相同信息的时候，同步的工作就极为重要，需要保证数据的一致性。
SQL与NoSQL
关系型数据库
略
非关系型数据库
键值存储 Key-Value Stores
以键值对的形式存储，比较著名的有Redis、Voldemort和Dynamo。
文献库 Document Databases
数据被存储在文件中（而不是表中）。文件允许使用不同的结构。比较著名的有CouchDB和MongoDB。
宽列存储 Wide-Column Databases
列族(column families)是行的容器。不需要预先定义所有的列。每一行不需要有相同数量的列。主要应用时分析大的数据集。比较著名的有Cassandra和HBase。
图数据库 Graph Databases
数据关系以图的形式存储。节点表示实体，性质是实体的信息，边则是实体间关系。比较著名的有Neo4J和InfiniteGraph。
区别
存储
SQL存储模式都是表，一行是一个实体，一列是实体的一个数据点。NoSQL存储模式各不相同。
架构 Schema
SQL的架构是固定的，列需要预先定义。NoSQL的是动态的，每条数据不一定有所有的列。
查询
在NoSql中使用UnQL语言，查询是针对文件的集合进行的。不同数据库的语法不相同。
可扩展性
SQL数据库大部分是通过垂直扩展，水平扩展会带来很多问题。NoSQL的扩展性更强
ACID
大部分NoSQL数据库为了更好的性能和扩展性牺牲了ACID。
应用场景
SQL
- 对ACID有强烈需求
- 数据本身结构性强，且结构不会改变
NoSQL
- 大量缺乏结构性的数据
- 云计算和储存 （需要良好扩展性）
- 快捷开发(rapid development)
CAP理论 CAP Theorem
我们的系统无法同时满足以下三个条件：一致性Consistency，可用性Availability，分区容错性Partition Tolerance。
一致性哈希 Consistent Hashing
普通哈希无法实现水平扩展，如果扩容，需要大量维护时间。而且服务器之间难以实现负载均衡。
优点
当添加一台新机器，只有k/n的数据需要被重新映射。k是键值对的数量，n是机器的数量。
网络请求
普通的http请求如下图所示。
Ajax轮询 Ajax Polling
客户端持续向服务器端发请求。如果没有新的数据，服务器端会返回一个空的响应。大部分都是空响应，增加了HTTP的负担。
长轮询 Long Polling
客户端发来请求后，不需要服务端立即响应，所以也被称为Hanging GET。如果没有新的数据，服务端会等到有新的数据产生，再响应请求。客户端收到响应以后，再次发送长轮询，保证服务端有新的等待请求。
网络套接字 WebSockets
提供双全工(full duplex)交流通道。长连接保证客户端和服务器端可以随时发送数据。
服务器发送事件 Server-Sent Events (SSEs)
客户端向服务端建立长连接。服务端用这个连接发送数据给客户。如果客户要发送数据，需要使用别的技术和协议。应用场景是服务端需要先客户端发送实时数据。
参考资料
- 《Grokking the System Design Interview》