点击上方蓝色字体，选择“设为星标”

优质文章，及时送达

故事从一次内部分享开始，我们每周组织组内分享，会分享一些技术，中间件，研发流程规范或者业务系统架构等内容，在进行了一系列中间件技术分享之后，会发现其中提及一系列通用的概念，这些是分布式系统所共有的，所以我们简单聊聊分布式概念。

什么是分布式系统呢？

从百度百科得到：

分布式系统是建立在网络之上的软件系统，拥有软件特性，所以分布式系统具有高度内聚性，和透明性。是建设于网络之上的高层软件，而不是硬件。

是不是看起来很拗口难以理解，简单的说：

分布式系统是一组独立的计算机以网络链接组成的服务系统，对用户来说是一个统一的体系。

因为分布式系统建立在网络之上，由多个独立操作系统组成，所以分布式系统对比独立部署并运行于单一操作系统之上的软件系统来说存在要解决通信和共识等问题。

分布式系统特点

分布式系统是多个服务器通过网络互联而构建的松耦合系统，其具备以下特点：

1. 分布式：分布式由多台计算机组成，在地域上是独立分散的，可以分散在一个单位，一个城市，一个国家，或是全球范围内。整个系统的统一功能是分散在多个节点上实现的，因而分布式系统具有数据处理的分布式特性。

2. 自治性：分布式系统各个节点包含自己独有的cpu和内存，具备独立的处理数据能力。一般来说每个节点是对等的，没有主次之分，可以自治的进行任务处理，还可以通过网络传输信息，协同完成任务处理。

3. 并行性：一个大的任务可以按规则划分到多个计算节点上进行独立的子任务支持，体现了并行性。

4. 全局性：分布式系统必须存在一个单一的，全局的通信机制，使得任何一个进程都能和其他进程通信，并且不区分本地通信和远程通信。在一个分布式集群中，往往所有机器具有统一的系统调用能力。

在不同的抽象层次上来说，分布式系统中每一个物理机，虚拟机，docker镜像，独立进程都可以认为是一个节点。

分布式系统可以很好的解决单机系统带来的资源限制问题，但其也存在特有缺点。

由于一个大型集群中，机器数量众多，每天集群中机器宕机都在发生，一般在机器宕机之后，通过健康检查和负载均衡机制将流量切割迁移。故障机器可能是由于fullgc等问题造成，之后会慢慢恢复。也可能因为机器磁盘或是物理问题导致，需要人工介入。

分布式系统中，节点之间通过网络互通互联。由于网络不稳定因素存在，所以数据丢包，消息丢失时有发生，节点之间可能无法进行通信，也就是出现了所谓的网络分化，这里我们一般引入CAP进行系统分析。

网络传输同样会造成信息乱序问题，也就是网络传输过程中A节点发送给B节点的消息，在B节点接受消息时并不一定和A发送给B的顺序一样。这种情况可能造成业务上的问题，网络传输层次上我们可以了解下TCP的处理方式，业务上我们可以采用创建全局唯一发号器和业务幂等来处理乱序带来的如：消息的无效，信息的过期等业务问题。

分布式系统中，节点之间通信不像单机系统那样非成功即失败，我们考虑到网络不确定性带来的问题，所以分布式场景下存在“分布式三态”的概念。也就是说A节点调用B节点，可能是B节点返回成功，或是B节点返回失败，还有就是因为网络问题而产生的超时状态，针对这种问题我们一般采用“failfast”，“retry+幂等”等方式。

分布式网络中，通过负载均衡我们可以将请求将负载到不同节点进行数据处理，在进行数据查询时同样可能会负载到不同的节点进行数据获取。这个问题场景其实是值得深入讨论的，不同的业务要求，不同的业务容错场景存在不同的解决方案。我们可以从其他节点获取数据，也可以在数据保存时要求一定的数据一致性等级处理，在完成多节点数据复制，才响应客户端。

正是由于分布式系统存在这样那样的异常问题，我们在进行分布式系统设计过程中需要面向异常进行系统架构设计，尽早在设计阶段考虑到可能遇到的异常问题，以进行容错的异常处理。

无状态服务体系下，请求可以被随机或是以哈希，一致性哈希等方式负载到不同到节点进行数据处理。节点异常可以随意的将问题节点下线和新节点扩容。但是对于有状态的分布式节点我们就不能简单的，随意的对分布式节点进行上下线操作了。

为解决分布式系统下有状态节点的数据完整性或叫做安全性的要求，我们一般采用多副本方式。

副本（replication）指的是在分布式系统中为数据节点或是数据单元进行的冗余。

数据副本一般分散放在多个节点之上，以提供更好的安全性，这样在某一个持有数据副本的节点宕机或是数据丢失之后，可以去其他持有副本的节点之上获取数据。所以给数据做副本是分布式系统解决数据丢失的常用手段。

除了数据安全性提升之外，多副本也可以提升系统查询吞吐能力，当然这个需要看分布式系统怎么设计了。

在副本设计上，我们首要需要考虑的是如何将数据正确的复制到其他数据副本之上，以满足副本数据和原始数据信息一致的要求。

对于数据和副本之间数据一致性上我们有以下几种实现方式：

1. 强一致性：也就是说对于数据访问者而言，访问分布式网络下任意节点下的数据副本都可以读到最新更新的数据信息。实现强一致的数据复制会牺牲系统的并发能力和吞吐能力，实现方案上也较为复杂，业务上一般不采用这种方式。

   这里抛出一个问题，是否有真正的数据强一致要求呢？还是都可以通过最终一致性搞定。

2. 单调一致性：意思是数据访问者一旦读取到某个数据副本最新的值，就不会在读到比这个副本值旧的值了。这个概念提出是为了满足以数据访问者视角来说的数据一致性。

3. 会话一致性：数据访问者在一次会话之内一旦读取到最新数据副本之后就不会再读取到比这个数据旧的值了，听起来是不是和上面的很类似。区别在于这里要求的是一次会话，如果同一个数据访问者发起多次会话可能就不满足这个一致性要求了，其并不对多次会话一致性提供保障，所以它是弱与上面情况的一种一致性实现。

4. 最终一致性：其要求一旦数据在某个副本更新成功，最终在各个副本上都可以访问到最终数据，以达到最终完全一致的状态，但是完整一致性的这个时间不做承诺。最终一致性一般是我们做分布式系统设计时采用的方案，而这个最终一致性的时间承诺来自于每个系统，中间件的SLA。

5. 弱一致性：说的是数据更新成功之后，并不能在一个确定的时间内读到更新之后的值，也不承诺其他副本可以获取最新的值。所以弱一致性在真实场景中很难被系统所采纳。

分布式系统的副本机制很好的提升了分布式系统的高可用性，针对不同等级的一致性要求可以采用不同的解决方案，越是强一致性的模型对用户来说越友好，当然实现成本也更高。

对于单机系统服务来说，我们考量系统的指标常来自于单机资源所带来的指标，比如内存，cpu，磁盘io等指标。分布式系统的性能指标则不一样：

• 系统吞吐能力，一般以系统每秒处理总数据量形容。

• 系统延迟能力，指的是完成一次任务处理所需要的时间。

• 系统并发能力，系统可以一起合作完成一项任务的能力，通常以QPS来衡量。

不同系统对于以上性能指标有不同的侧重，高吞吐系统往往难以做到低延迟，系统任务执行时间较长的系统，也难以承载更高的QPS。

分布式系统中每个节点都可能因为各种原因不能提供服务，所以系统可用性是系统很重要的指标之一。通过计算系统正常提供服务和停服的时间占比计算得来，我们所说的可用性几个9就是这个道理。

可扩展性并不是系统性能指标之一，但是对于分布式系统的设计上，我们期望实现分布式系统的线性扩展。通过系统扩展我们可以提供更大规模的吞吐，提升集群整体存储容量，提升集群计算能力。

一口气没有条理的聊了分布式系统的一些概念，分布式概念还有很多，我们以后慢慢道来。