指标

可扩展性 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》

分布式系统设计的概念相关推荐

分布式系统设计原理与方案Dubbo+Zookeeper+Spring整合
2019独角兽企业重金招聘Python工程师标准>>> 一直在思考分布式系统设计的问题,业务对象原封不动的情况下部署在客户端和服务器端,可以根据配置文件选择是连接服务器还是连接本地的 ...
WCF分布式开发步步为赢(1)：WCF分布式框架基础概念
众所周知,系统间的低耦合一直是大型企业应用系统集成追寻的目标,SOA面向服务架构的出现为我们的如何利用现有企业系统资源进行企业ERP系统设计和实现提供了重要的参考原则.SOA如此炙手可热,各大厂商都 ...
分布式系统设计原理与方案
一直在思考分布式系统设计的问题,业务对象原封不动的情况下部署在客户端和服务器端,可以根据配置文件选择是连接服务器还是连接本地的数据库,这个问题让我绞尽脑汁,我总是设想的客户端与服务器端通信的方式是最低 ...
云原生时代|分布式系统设计知识图谱（内含 22 个知识点）
我们身处于一个充斥着分布式系统解决方案的计算机时代,无论是支付宝.微信这样顶级流量产品.还是区块链.IOT等热门概念.抑或如火如荼的容器生态技术如Kubernetes,其背后的技术架构核心都离不开分布 ...
高并发服务端分布式系统设计概要（上）
高并发服务端分布式系统设计概要(上) ======张峻崇原创.转载请注明出处.====== 又是快一年没写博客了,2013年也只剩尾巴,也不知道今年都忙了些什么.写这篇文章的目的,主要是把今年以来学 ...
云原生时代|分布式系统设计知识图谱（内含22个知识点）
我们身处于一个充斥着分布式系统解决方案的计算机时代,无论是支付宝.微信这样顶级流量产品.还是区块链.IOT等热门概念.抑或如火如荼的容器生态技术如Kubernetes,其背后的技术架构核心都离不开分布 ...
高并发服务端分布式系统设计概要
我大概是从2010年底起开始进入高并发.高性能服务器和分布式这一块领域的研究,到现在也差不多有三年,但其实很多东西仍然是一知半解,我所提到的许许多多概念,也许任何一个我都不能讲的很清楚,还需要继续钻研 ...
分布式系统设计系列 -- 基本原理及高可用策略
"分布式系统设计"系列第一篇文章,这篇文章主要介绍一些入门的概念和原理,后面带来一些高可用.数据分布的实践方法!! 各位亲,如果你们觉得本文有还不错的地方,请点击"投一票 ...
分布式系统设计权衡之CAP(一致性,可用性,分区容错性)
https://blog.csdn.net/Sun_P0/article/details/50221787 写在最前: 1.为什么学习并记录分布式设计理念一系列相关的东西在日常工作中系统设计评审的时 ...