文章目录
- 一、分布式整体框架图
- 1.架构eg1
- 2.架构eg2
- 二、什么是分布式系统？
- 1.什么是分布式系统？
- 2.分布式系统的挑战
- 3.分布式系统特性与衡量标准
- 4.组件、理论、协议
- 5.概念与实现
- 6.总结
- 三、分布式学习最佳实践：从分布式系统的特征开始（附思维导图）
- 1.分布式特征的思维导图
- 2.分布式系统的一般特征
- （1）可扩展性
- （2）可用性
- （3）一致性
- （4）高性能
- 四、分布式系统的系统模型
一、分布式整体框架图
1.架构eg1
- 页面层：手机，电脑等
- 网络层：ip
- 应用层：分布式单点登录服务器： 包括：静态资源服务器集群（图片文件服务器），应用服务器寄集群（Web服务器）
- 服务层：分布式服务集群：提供各种各样的服务，为数据层提供分布式数据中间件，分布式消息组件、分布式缓存组件redis、配置中心组件（服务治理组件）、搜索引擎组件
- 数据层：文件图片服务器集群（文件服务器）、MangoDB（MangoDB复制集）、Mysql集群（Mysql读写分离）
2.架构eg2
二、什么是分布式系统？
1.什么是分布式系统？
分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据。
首先需要明确的是，只有当单个节点的处理能力无法满足日益增长的计算、存储任务的时候，且硬件的提升（加内存、加磁盘、使用更好的CPU）高昂到得不偿失的时候，应用程序也不能进一步优化的时候，我们才需要考虑分布式系统。因为，分布式系统要解决的问题本身就是和单机系统一样的，而由于分布式系统多节点、通过网络通信的拓扑结构，会引入很多单机系统没有的问题，为了解决这些问题又会引入更多的机制、协议，带来更多的问题。。。
在很多文章中，主要讲分布式系统分为分布式计算（computation）与分布式存储（storage）。计算与存储是相辅相成的，计算需要数据，要么来自实时数据（流数据），要么来自存储的数据；而计算的结果也是需要存储的。在操作系统中，对计算与存储有非常详尽的讨论，分布式系统只不过将这些理论推广到多个节点罢了。
那么分布式系统怎么将任务分发到这些计算机节点呢，很简单的思想，分而治之，即分片（partition）。对于计算，那么就是对计算任务进行切换，每个节点算一些，最终汇总就行了，这就是MapReduce的思想；对于存储，更好理解一下，每个节点存一部分数据就行了。当数据规模变大的时候，Partition是唯一的选择，同时也会带来一些好处：
- （1）提升性能和并发，操作被分发到不同的分片，相互独立
- （2）提升系统的可用性，即使部分分片不能用，其他分片不会受到影响
理想的情况下，有分片就行了，但事实的情况却不大理想。原因在于，分布式系统中有大量的节点，且通过网络通信。单个节点的故障（进程crash、断电、磁盘损坏）是个小概率事件，但整个系统的故障率会随节点的增加而指数级增加，网络通信也可能出现断网、高延迟的情况。在这种一定会出现的“异常”情况下，分布式系统还是需要继续稳定的对外提供服务，即需要较强的容错性。最简单的办法，就是冗余或者复制集（Replication），即多个节点负责同一个任务，最为常见的就是分布式存储中，多个节点复杂存储同一份数据，以此增强可用性与可靠性。同时，Replication也会带来性能的提升，比如数据的locality可以减少用户的等待时间。
下面这种来自Distributed systems for fun and profit 的图形象生动说明了Partition与Replication是如何协作的。
Partition和Replication是解决分布式系统问题的一记组合拳，很多具体的问题都可以用这个思路去解决。 但这并不是银弹，往往是为了解决一个问题，会引入更多的问题，比如为了可用性与可靠性保证，引用了冗余（复制集）。有了冗余，各个副本间的一致性问题就变得很头疼，一致性在系统的角度和用户的角度又有不同的等级划分。如果要保证强一致性，那么会影响可用性与性能，在一些应用（比如电商、搜索）是难以接受的。如果是最终一致性，那么就需要处理数据冲突的情况。CAP、FLP这些理论告诉我们，在分布式系统中，没有最佳的选择，都是需要权衡，做出最合适的选择。
2.分布式系统的挑战
分布式系统需要大量机器协作，面临诸多的挑战：
- 第一，异构的机器与网络：
分布式系统中的机器，配置不一样，其上运行的服务也可能由不同的语言、架构实现，因此处理能力也不一样；节点间通过网络连接，而不同网络运营商提供的网络的带宽、延时、丢包率又不一样。怎么保证大家齐头并进，共同完成目标，这四个不小的挑战。
- 第二，普遍的节点故障：
虽然单个节点的故障概率较低，但节点数目达到一定规模，出故障的概率就变高了。分布式系统需要保证故障发生的时候，系统仍然是可用的，这就需要监控节点的状态，在节点故障的情况下将该节点负责的计算、存储任务转移到其他节点
- 第三，不可靠的网络：
节点间通过网络通信，而网络是不可靠的。可能的网络问题包括：网络分割、延时、丢包、乱序。
相比单机过程调用，网络通信最让人头疼的是超时：节点A向节点B发出请求，在约定的时间内没有收到节点B的响应，那么B是否处理了请求，这个是不确定的，这个不确定会带来诸多问题，最简单的，是否要重试请求，节点B会不会多次处理同一个请求。
总而言之，分布式的挑战来自不确定性，不确定计算机什么时候crash、断电，不确定磁盘什么时候损坏，不确定每次网络通信要延迟多久，也不确定通信对端是否处理了发送的消息。而分布式的规模放大了这个不确定性，不确定性是令人讨厌的，所以有诸多的分布式理论、协议来保证在这种不确定性的情况下，系统还能继续正常工作。
而且，很多在实际系统中出现的问题，来源于设计时的盲目乐观，觉得这个、那个应该不会出问题。Fallacies_of_distributed_computing很有意思，介绍了分布式系统新手可能的错误的假设：
The network is reliable.
Latency is zero.
Bandwidth is infinite.
The network is secure.
Topology doesn’t change.
There is one administrator.
Transport cost is zero.
The network is homogeneous.
刘杰在《分布式系统原理介绍》中指出，处理这些异常的最佳原则是：在设计、推导、验证分布式系统的协议、流程时,最重要的工作之一就是思考在执行流程的每个步骤时一旦发生各种异常的情况下系统的处理方式及造成的影响。
3.分布式系统特性与衡量标准
（1）透明性：
使用分布式系统的用户并不关心系统是怎么实现的，也不关心读到的数据来自哪个节点，对用户而言，分布式系统的最高境界是用户根本感知不到这是一个分布式系统，在《Distributed Systems Principles and Paradigms》一书中，作者是这么说的：
A distributed system is a collection of independent computers that appears to its users as a single coherent system.
（2）可扩展性
分布式系统的根本目标就是为了处理单个计算机无法处理的任务，当任务增加的时候，分布式系统的处理能力需要随之增加。简单来说，要比较方便的通过增加机器来应对数据量的增长，同时，当任务规模缩减的时候，可以撤掉一些多余的机器，达到动态伸缩的效果
（3）可用性与可靠性
一般来说，分布式系统是需要长时间甚至7*24小时提供服务的。
- 可用性是指系统在各种情况对外提供服务的能力，简单来说，可以通过不可用时间与正常服务时间的比值来衡量；
- 而可靠性而是指计算结果正确、存储的数据不丢失。
（4）高性能
不管是单机还是分布式系统，大家都非常关注性能。不同的系统对性能的衡量指标是不同的，最常见的：
- 高并发，单位时间内处理的任务越多越好；
- -低延迟：每个任务的平均时间越少越好。这个其实跟操作系统CPU的调度策略很像
（5）一致性
分布式系统为了提高可用性可靠性，一般会引入冗余（复制集）。那么如何保证这些节点上的状态一致，这就是分布式系统不得不面对的一致性问题。一致性有很多等级，一致性越强，对用户越友好，但会制约系统的可用性；一致性等级越低，用户就需要兼容数据不一致的情况，但系统的可用性、并发性很高很多。
4.组件、理论、协议
假设这是一个对外提供服务的大型分布式系统，用户连接到系统，做一些操作，产生一些需要存储的数据，那么在这个过程中，会遇到哪些组件、理论与协议呢？
用一个请求串起来
用户使用Web、APP、SDK，通过HTTP、TCP连接到系统。在分布式系统中，为了高并发、高可用，一般都是多个节点提供相同的服务。那么，第一个问题就是具体选择哪个节点来提供服务，这个就是负载均衡（load balance）。
负载均衡的思想很简单，但使用非常广泛，在分布式系统、大型网站的方方面面都有使用，或者说，只要涉及到多个节点提供同质的服务，就需要负载均衡。
通过负载均衡找到一个节点，接下来就是真正处理用户的请求，请求有可能简单，也有可能很复杂。简单的请求，比如读取数据，那么很可能是有缓存的，即分布式缓存，如果缓存没有命中，那么需要去数据库拉取数据。对于复杂的请求，可能会调用到系统中其他的服务。
承上，假设服务A需要调用服务B的服务，首先两个节点需要通信，网络通信都是建立在TCP/IP协议的基础上，但是，每个应用都手写socket是一件冗杂、低效的事情，因此需要应用层的封装，因此有了HTTP、FTP等各种应用层协议。当系统愈加复杂，提供大量的http接口也是一件困难的事情。因此，有了更进一步的抽象，那就是RPC（remote produce call），是的远程调用就跟本地过程调用一样方便，屏蔽了网络通信等诸多细节，增加新的接口也更加方便。
一个请求可能包含诸多操作，即在服务A上做一些操作，然后在服务B上做另一些操作。比如简化版的网络购物，在订单服务上发货，在账户服务上扣款。这两个操作需要保证原子性，要么都成功，要么都不操作。这就涉及到分布式事务的问题，分布式事务是从应用层面保证一致性：某种守恒关系。
上面说到一个请求包含多个操作，其实就是涉及到多个服务，分布式系统中有大量的服务，每个服务又是多个节点组成。
那么一个服务怎么找到另一个服务（的某个节点呢）？通信是需要地址的，怎么获取这个地址，最简单的办法就是配置文件写死，或者写入到数据库，但这些方法在节点数据巨大、节点动态增删的时候都不大方便，这个时候就需要服务注册与发现：提供服务的节点向一个协调中心注册自己的地址，使用服务的节点去协调中心拉取地址。
从上可以看见，协调中心提供了中心化的服务：以一组节点提供类似单点的服务，使用非常广泛，比如命令服务、分布式锁。协调中心最出名的就是chubby，zookeeper。
回到用户请求这个点，请求操作会产生一些数据、日志，通常为信息，其他一些系统可能会对这些消息感兴趣，比如个性化推荐、监控等，这里就抽象出了两个概念，消息的生产者与消费者。
那么生产者怎么讲消息发送给消费者呢，RPC并不是一个很好的选择，因为RPC肯定得指定消息发给谁，但实际的情况是生产者并不清楚、也不关心谁会消费这个消息，这个时候消息队列就出马了。简单来说，生产者只用往消息队列里面发就行了，队列会将消息按主题（topic）分发给关注这个主题的消费者。消息队列起到了异步处理、应用解耦的作用。
上面提到，用户操作会产生一些数据，这些数据忠实记录了用户的操作习惯、喜好，是各行各业最宝贵的财富。比如各种推荐、广告投放、自动识别。这就催生了分布式计算平台，比如Hadoop，Storm等，用来处理这些海量的数据。
最后，用户的操作完成之后，用户的数据需要持久化，但数据量很大，大到按个节点无法存储，那么这个时候就需要分布式存储：将数据进行划分放在不同的节点上，同时，为了防止数据的丢失，每一份数据会保存多分。传统的关系型数据库是单点存储，为了在应用层透明的情况下分库分表，会引用额外的代理层。而对于NoSql，一般天然支持分布式。
一个简化的架构图
下面用一个不大精确的架构图，尽量还原分布式系统的组成部分（不过只能体现出技术，不好体现出理论）
5.概念与实现
那么对于上面的各种技术与理论，业界有哪些实现呢，下面进行简单罗列。
当然，下面的这些实现，小部分我用过，知其所以然；大部分听说过，知其然；还有一部分之前闻所未闻，分类也不一定正确，只是从其他文章抄过来的。罗列在这里，以便日后或深或浅的学习。
负载均衡：
- Nginx：高性能、高并发的web服务器；功能包括负载均衡、反向代理、静态内容缓存、访问控制；工作在应用层
- LVS： Linux virtual server，基于集群技术和Linux操作系统实现一个高性能、高可用的服务器；工作在网络层
webserver：
- Java：Tomcat，Apache，Jboss
- Python：gunicorn、uwsgi、twisted、webpy、tornado
service：
- SOA、微服务、spring boot，django
容器：
- docker，kubernetes
cache：
- memcache、redis等
协调中心：
- zookeeper、etcd等
zookeeper使用了Paxos协议Paxos是强一致性，高可用的去中心化分布式。zookeeper的使用场景非常广泛，之后细讲。
rpc框架：
- grpc、dubbo、brpc
dubbo是阿里开源的Java语言开发的高性能RPC框架，在阿里系的诸多架构中，都使用了dubbo + spring boot
消息队列：
- kafka、rabbitMQ、rocketMQ、QSP
消息队列的应用场景：异步处理、应用解耦、流量削锋和消息通讯
实时数据平台：
- storm、akka
离线数据平台：
- hadoop、spark
PS: apark、akka、kafka都是scala语言写的，看到这个语言还是很牛逼的
dbproxy：
- cobar也是阿里开源的，在阿里系中使用也非常广泛，是关系型数据库的sharding + replica 代理
db：
- mysql、oracle、MongoDB、HBase
搜索：
- elasticsearch、solr
日志：
- rsyslog、elk、flume
6.总结
网上的诸多回答，上来就是看各种论文，google三大件、paxos什么的，个人觉得不是很实用。更好的过程，是先有一个整体的把握，然后自己思考会有什么问题，带着问题去寻求答案，在寻求答案的时候再去看论文。
另外，也有很多人提到，掌握好计算机基础知识，如操作系统、计算机网络，对学习分布式系统是大有裨益的，这一点我很赞同。分布式系统解决问题的思路是早就有的，很多都是前人研究透的问题，思想都是相同的。比如函数式编程中的map reduce之于Hadoop的MapReduce，比如磁盘存储的raid之于Partition与Replication，比如IPC之于消息队列。
三、分布式学习最佳实践：从分布式系统的特征开始（附思维导图）
1.分布式特征的思维导图
从思考分布式的特征出发的学习方式：
（1）先有问题，才会去思考解决问题的办法
由于我们要提高可用性，所以我们才需要冗余；由于需要扩展性，所以我们才需要分片
（2）解决一个问题，常常会引入新的问题
比如，为了提高可用性，引入了冗余；而冗余又带来了副本之间的一致性问题，所以引入了中心化副本协议（primary/secondary)；那么接下来就要考虑primary（节点）故障时候的选举问题。。。
（3）这是一个金字塔结构，或者说，也是一个深度优先遍历的过程。
在这个过程中，我们始终知道自己已经掌握了哪些知识；还有哪些是已经知道，但未了解的知识；也能知道，哪些是空白，即我们知道这里可能有很多问题，但是具体是什么，还不知道。
2.分布式系统的一般特征
任何介绍分布式系统的文章或者书籍都会提到分布式系统的几个特性：可扩展性、高性能、高可用、一致性。这几个特性也是分布式系统的衡量指标，正是为了在不同的程度上满足这些特性（或者说达到这些指标），才会设计出各种各样的算法、协议，然后根据业务的需求在这些特性间平衡。
（1）可扩展性
可扩展性是指当系统的任务（work）增加的时候，通过增加资源来应对任务增长的能力。可扩展性是任何分布式系统必备的特性，这是由分布式系统的概念决定的：
分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统
分布式系统的出现是为了解决单个计算机无法完成的计算、存储任务。那么当任务规模增加的时候，必然就需要添加更多的节点，这就是可扩展性。
扩展性的目标是使得系统中的节点都在一个较为稳定的负载下工作，这就是负载均衡，当然，在动态增加节点的时候，需要进行任务（可能是计算，可能是数据存储）的迁移，以达到动态均衡。
- 第一：分片分式，即按照什么算法对任务进行拆分
常见的算法包括：哈希（hash），一致性哈希（consistency hash），基于数据范围（range based）。每一种算法有各自的优缺点，也就有各自的适用场景。 - 第二：分片的键，partition key
partition key是数据的特征值，上面提到的任何分片方式都依赖于这个partition key，那么该如何选择呢
partition key会影响到任务在分片之间的均衡，而且一些系统中（mongodb）几乎是不能重新选择partition key的，因此在设计的时候就得想清楚 - 第三：分片的额外好处
提升性能和并发：不同的请求分发到不同的分片
提高可用性：一个分片挂了不影响其他的分片 - 第四：分片带来的问题
如果一个操作需要跨越多个分片，那么效率就会很低下，比如数据中的join操作 - 第五：元数据管理
元数据记录了分片与节点的映射关系、节点状态等核心信息，分布式系统中，有专门的节点（节点集群）来管理元数据，我们称之为元数据服务器。元数据服务器有以下特点：
高性能：cache
高可用：冗余 加 快速failover
强一致性（同时只有一个节点对外提供服务） - 第六：任务的动态均衡
为了达到动态均衡，需要进行数据的迁移，如何保证在迁移的过程中保持对外提供服务，这也是一个需要精心设计的复杂问题。
（2）可用性
可用性（Availability）是系统不间断对外提供服务的能力，可用性是一个度的问题，最高目标就是7 * 24，即永远在线。但事实上做不到的，一般是用几个9来衡量系统的可用性，如下如所示：
也就是如果要达到4个9的可用度（99.99%），那么一年之中只能有52.6分钟不可用，这是个巨大的挑战。
为什么分布式系统中必须要考虑可用性呢，这是因为分布式系统中故障的概率很高。
分布式系统由大量异构的节点和网络组成，节点可能会crash、断电、磁盘损坏，网络可能丢包、延迟、网络分割。系统的规模放大了出故障的概率，因此分布式系统中，故障是常态。
那么分布式系统的其中一个设计目标就是容错，在部分故障的情况下仍然对外提供服务，这就是可用性。
- 冗余是提高可用性、可靠性的法宝。
冗余就是说多个节点负责相同的任务，在需要状态维护的场景，比如分布式存储中使用非常广泛。在分布式计算，如MapReduce中，当一个worker运行异常缓慢时，master会将这个worker上的任务重新调度到其它worker，以提高系统的吞吐，这也算一种冗余。但存储的冗余相比计算而言要复杂许多，因此主要考虑存储的冗余。
维护同一份数据的多个节点称之为多个副本。我们考虑一个问题，当向这个副本集写入数据的时候，怎么保证并发情况下数据的一致性，是否有一个节点有决定更新的顺序，这就是中心化、去中心话副本协议的区别。 - 中心化与去中心化
中心化就是有一个主节点（primary master）负责调度数据的更新，其优点是协议简单，将并发操作转变为顺序操作，缺点是primar可能成为瓶颈，且在primary故障的时候重新选举会有一段时间的不可用。
去中心化就是所有节点地位平等，都能够发起数据的更新，优点是高可用，缺点是协议复杂，要保证一致性很难。 - 节点更新策略
primary节点到secondary节点的数据时同步还是异步，即客户端是否需要等待数据落地到副本集中的所有节点。
同步的优点在于强一致性，但是可用性和性能（响应延迟）比较差；异步则相反。 - 数据流向
即数据是如何从Primary节点到secondary节点的，有链式和主从模式。
链式的优点时充分利用网络带宽，减轻primary压力，但缺点是写入延迟会大一些。GFS，MongoDB（默认情况下）都是链式。 - 部分节点写入异常
理论上，副本集中的多个节点的数据应该保持一致，因此多个数据的写入理论上应该是一个事务：要么都发生，要么都不发生。但是分布式事务（如2pc）是一个复杂的、低效的过程，因此副本集的更新一般都是best effort 1pc，如果失败，则重试，或者告诉应用自行处理。 - primary的选举
在中心化副本协议中，primary节点是如何选举出来的，当primary节点挂掉之后，又是如何选择出新的primary节点呢，有两种方式：自治系统，依赖其他组件的系统。（ps，这两个名字是我杜撰的 。。。）
所谓的自治系统，就是节点内部自行投票选择，比如mongodb，tfs，zookeeper
依赖其他组件的系统，是指primary由副本集之后的组件来任命，比如GFS中的primary由master（GFS的元数据服务器）任命，hdfs的元数据namenode由zookeeper心跳选出。 - secondary是否对外提供服务（读服务）
中心化复制集中，secondary是否对外提供读服务，取决于系统对一致性的要求。
比如前面介绍到节点更新策略时，可能是异步的，那么secondary上的数据相比primary会有一定延迟，从secondary上读数据的话无法满足强一致性要求。
比如元数据，需要强一致性保证，所以一般都只会从primary读数据。而且，一般称主节点为active（master），从节点为standby（slave）。在这种情况下，是通过冗余 加上 快速的failover来保证可用性。
（3）一致性
从上面可以看到，为了高可用性，引入了冗余（副本）机制，而副本机制就带来了一致性问题。当然，如果没有冗余机制，或者不是数据（状态）的冗余，那么不会出现一致性问题，比如MapReduce。
一致性与可用性在分布式系统中的关系，已经有足够的研究，形成了CAP理论。CAP理论就是说分布式数据存储，最多只能同时满足一致性（C，Consistency）、可用性（A， Availability）、分区容错性（P，Partition Tolerance）中的两者。但一致性和可用性都是一个度的问题，是0到1，而不是只有0和1两个极端。
一致性从系统的角度和用户的角度有不同的等级。
- 系统角度的一致性
强一致性、弱一致性、最终一致性 - 用户角度的一致性
单调读一致性，单调写一致性，读后写一致性，写后读一致性
（4）高性能
正式因为单个节点的scale up不能完成任务，因此我们才需要scale out，用大量的节点来完成任务，分布式系统的理想目标是任务与节点按一定的比例线性增长。
- 衡量指标
高并发
高吞吐
低延迟
不同的系统关注的核心指标不一样，比如MapReduce，本身就是离线计算，无需低延迟 - 可行的办法
单个节点的scaleup
分片（partition）
缓存：比如元数据
短事务
四、分布式系统的系统模型