Java开发分布式系统特点设计与原理分析

引言

分布式系统（distributed system）是建立在网络之上的软件系统。处理各项协助的任务，然后整合出结果。

一丶分布式系统最大的特点是可扩展性，它能够适应需求变化而扩展。

企业级应用需求经常随时间而不断变化，这也对企业级应用平台提出了很高的要求。企业级应用平台必须要能适应需求的变化，即具有可扩展性。比如移动互联网2C应用，随着互联网企业的业务规模不断增大，业务变得越来越复杂，并发用户请求越来越多，要处理的数据也越来越多，这个时候企业级应用平台必须能够适应这些变化，支持高并发访问和海量数据处理。分布式系统有良好的可扩展性，可以通过增加服务器数量来增强分布式系统整体的处理能力，以应对企业的业务增长带来的计算需求。

分布式系统的核心理念是让多台服务器协同工作，完成单台服务器无法处理的任务，尤其是高并发或者大数据量的任务。

分布式系统由独立的服务器通过网络松散耦合组成的。每个服务器都是一台独立的PC机，服务器之间通过内部网络连接，内部网络速度一般比较快。因为分布式集群里的服务器是通过内部网络松散耦合，各节点之间的通讯有一定的网络开销，因此分布式系统在设计上尽可能减少节点间通讯。此外，因为网络传输瓶颈，单个节点的性能高低对分布式系统整体性能影响不大。比如，对分布式应用来说，采用不同编程语言开发带来的单个应用服务的性能差异，跟网络开销比起来都可以忽略不计。因此，分布式系统每个节点一般不采用高性能的服务器，而是性能相对一般的普通PC服务器。提升分布式系统的整体性能是要通过横向扩展(增加更多的服务器)，而不是纵向扩展(提升每个节点的服务器性能)。

二丶分布式系统最大的特点是廉价高效。

由成本低廉的PC服务器组成的集群，在性能方面能够达到或超越大型机的处理性能，在成本上远低于大型机。这也是分布式系统最吸引人之处。成本低廉的PC服务器在硬件可靠性方面比大型机相去甚远，于是分布式系统由软件来对硬件进行容错，通过软件来保证整体系统的高可靠性。

三丶分布式系统最大的好处是实现企业应用服务层面的弹性扩展。

应用服务层面的弹性扩展是相对计算资源层面的弹性扩展而言的。一般公有云服务(IaaS)厂商都会提供计算资源层面的弹性扩展，比如可以很方便地增加或删除虚拟主机、提升或降低虚拟主机的性能配置等等。但是企业客户真正需要的是应用服务层面的弹性扩展，即随着业务量的涨落，后台应用服务的实例能动态变化，这是IaaS厂商还做不到的。比如，某移动互联网短视频分享应用，在晚间11点到凌晨1点是访问高峰，同时在线人数高达几十万，这时后台应用服务要扩张到数千个实例才能应付这么高并发的访问请求;过了高峰时段，后台应用服务可以收缩到几十个实例。有了分布式系统，就可以很方便地调度应用服务实例，从几十个到几百个甚至上千个，真正实现应用服务的弹性扩展。

四丶分布式系统的设计理念

上面简单介绍了分布式系统的基本情况，下面详细阐述笔者理解的几个分布式系统设计理念：

分布式系统对服务器硬件要求很低

这一点主要现在如下两个方面：

对服务器硬件可靠性不做要求，允许服务器硬件发生故障，硬件的故障由软件来容错。所以分布式系统的高可靠性是由软件来保证;

对服务器的性能不做要求，不要求使用高频CPU、大容量内存、高能存储等等。因为分布式系统的性能瓶颈在于节点间通讯带来的网开销，单台服务器硬件性能再好，也要等待网络IO。

一般而言，互联网公司的大型数据中心都是选用大量廉价的PC服务器而不是用几台高性能服务器搭建分布式集群，以此来降低数据中心成本。比如，Google对于数据中心的成本控制做到了极致：所有服务器一律不要机箱;主板完全定制，只要最基本的组件，早期的定制主板连电源开关和USB接口都不要;在主板上加装隔离带把CPU单独隔出来，让冷风只吹CPU，不吹内存、硬盘等不需要降温的组件，最大限度降低冷却电力消耗。

五丶分布式系统强调横向可扩展性

横向可扩展性(Scale Out)是指通过增加服务器数量来提升集群整体性能。纵向可扩展性(Scale Up)是指提升每台服务器性能进而提升集群整体性能。纵向可扩展性的上限非常明显，单台服务器的性能不可能无限提升，而且跟服务器性能相比，网络开销才是分布式系统最大的瓶颈。横向可扩展性的上限空间比较大，集群总能很方便地增加服务器。而且分布式系统会尽可能保证横向扩展带来集群整体性能的(准)线性提升。比如有10台服务器组成的集群，横向扩展为100台同样服务器的集群，那么整体分布式系统性能会提升为接近原来的10倍。

互联网公司的数据中心，一般一个分布式系统横向扩展的上限在万台服务器左右。Google数据中心的基本单元，CELL，由两万台左右服务器组成，每个CELL由一套分布式管理系统，BORG，统一管理，每个数据中心都由多个CELL组成。

分布式系统不允许单点失效(No Single Point Failure)

单点失效是指，某个应用服务只有一份实例运行在某一台服务器上，这台服务器一旦挂掉，那么这个应用服务必然也受影响而挂掉，导致整个服务不可用。例如，某网站后台如果只在某一台服务器上运行一份，那这台服务器一旦宕机，该网站服务必然受影响而不可用。再比如，如果所有数据都存在某一台服务器上，那一旦这台服务器坏了，所有数据都不可访问。

因为分布式系统的服务器都是廉价的PC服务器，硬件不能保证100%可靠，所以分布式系统默认每台服务器随时都可能发生故障挂掉。同时分布式系统必须要提供高可靠服务，不允许出现单点失效，因此分布式系统里运行的每个应用服务都有多个运行实例跑在多个节点上，每个数据点都有多个备份存在不同的节点上。这样一来，多个节点同时发生故障，导致某个应用服务的所有实例都挂掉、或某个数据点的多个备份都不可读的概率大大降低，进而有效防止单点失效。

通常情况，不要让服务器满负荷运行，服务器长时间满负荷运行的话，出故障的概率显著升高。所以分布式系统采用一大堆中低性能的PC服务器，尽可能把负载均摊到所有服务器上，让每台服务器的负载都不高，保证集群整体稳定性。

分布式系统尽可能减少节点间通讯开销

如前所述，分布式系统的整体性能瓶颈在于内部网络开销。目前网络传输的速度还赶不上CPU读取内存或硬盘的速度，所以减少网络通讯开销，让CPU尽可能处理内存的数据或本地硬盘的数据，能显著提高分布式系统的性能。典型的例子就是Hadoop MapReduce，把计算任务分配到要处理的数据所在的节点上运行，从而避免在网络上传输数据。

分布式系统应用服务最好做成无状态的

应用服务的状态是指运行时程序因为处理服务请求而存在内存的数据。分布式应用服务最好是设计成无状态。因为如果应用程序是有状态的，那么一旦服务器宕机就会使得应用服务程序受影响而挂掉，那存在内存的数据也就丢失了，这显然不是高可靠的服务。把应用服务设计成无状态的，让程序把需要保存的数据都保存在专门的存储上，这样应用服务程序可以任意重启而不丢失数据，方便分布式系统在服务器宕机后恢复应用服务。

比如，在设计网站后台的时候，对于用户登陆请求，可以把登陆用户的session相关信息保存在Redis或Memcache等缓存服务中，这样每个网站的后台实例不保存用户登录状态，这样即使重启网站后台程序也不丢失用户的登录状态信息;如果把用户的session相关信息保存在网站后台程序的内存里，那一旦受理用户登录的网站后台程序实例挂掉，必然有用户的登录状态信息会丢失。

总而言之，分布式系统是大数据时代企业级应用的首选平台，它有良好的可扩展性，尤其是横向可扩展性(Scale Out)，使得分布式系统非常灵活，能应对千变万化的企业级需求，而且降低了企业客户对服务器硬件的要求，真正能做到应用服务层面的弹性扩展(auto- scaling)。

六丶分布式系统原理：

1． 哈希方式，把不同的值进行哈希运算，映射到，不同的机器或者节点。考虑冗余的时候可以把多个哈希值映射到同一个地方。哈希的实现方式，取余。其实现扩展时，比较困难，数据分散在很多机器上，扩展的时候要从个机器上获取数据。而且容易出现分布不均有的情况。

常见的哈希，用IP、URL、ID、或者固定的值进行哈希，总是得到相同的结果。

2． 按数据范围分布，比如ID在1~20的在机器A上，ID在21~40的在机器B上，ID在40~60的在机器C上实现，ID在60~100的分布在机器D上，数据分布比较均匀。如果某个节点处理能力有限，可以直接分裂该节点。维护数据分布的元信息，可能出现单点瓶颈。几千机器，每个机器又划分为N个范围，导致需要维护的数据分布范围元数据过大，导致可能需要几台机器实现。

一定要严格控制元数据量，进可能的减少元数据的存储。

3． 按数据量分布，另一类常用的数据分布方式则是按照数据量分布数据。与哈希方式和按数据范围方式不同，数据量分布数据与具体的数据特征无关，而是将数据视为一个顺序增长的文件，并将这个文件按照某一较为固定的大小划分为若干数据块（chunk），不同的数据块分布到不同的服务器上。与按数据范围分布数据的方式类似的是，按数据量分布数据也需要记录数据块的具体分布情况，并将该分布信息作为元数据使用元数据服务器管理。

由于与具体的数据内容无关，按数据量分布数据的方式一般没有数据倾斜的问题，数据总是被均匀切分并分布到集群中。当集群需要重新负载均衡时，只需通过迁移数据块即可完成。集群扩容也没有太大的限制，只需将部分数据库迁移到新加入的机器上即可以完成扩容。按数据量划分数据的缺点是需要管理较为复杂的元信息，与按范围分布数据的方式类似，当集群规模较大时，元信息的数据量也变得很大，高效的管理元信息成为新的课题。

4． 一致性哈希，构造哈希环，有哈希域[0,10]，则构造3个部分，[1,4)/[4,9)/[9,10),[0,1)/分成了3个部分，这3部分是一个环状，增加机器时，变动的是其附近的节点，分担的是附近节点的压力，其元数据的维护和按数据量分布一样。其未来的扩展，可以实现多个需节点。

5． 构建映射元数据，建立映射表的方式。

6． 副本与数据分布，把一个数据副本分散到多台服务器上。比如应用A的数据，存储在A、B、C ，3台机器上，如果3台机器中，其中一台出现问题，请求被处理到其他2台机器上，如果加机器恢复，还需要从另外2台机器上，Copy数据，又增加了这2台机器的负担。如果我们有应用A和应用B，各自有3台机器，那么我们可以把A应用分散在6台机器上，B应用也分散在6台机器上，可以实现相同的数据备份，但是应用存储的数据被分散了。某台机器损害，只是把该机器所承担的负载平均分配到了，另外5台机器上。恢复数据从5台机器恢复，其速度快和给各台服务器的压力都不大，而且可以实现机器损害，更换完全不影响应用。

其原理是多个机器互为副本，是比较理想的实现负载分压的方式。

7． 分布式计算思想，移动数据不如移动计算，就进计算原则，减少跨进程、跨网络、等跨度较大的实现，把计算所需的资源尽可能的靠近。因为可能出现网络、远程机器的瓶颈。

8． 常见分布式系统数据分布方式: GFS、HDFS:按数据量分布；Map reduce 按GFS的数据分布做本地化；BigTable、HBase按数据范围分布；Pnuts按哈希方式或者数据范围分布，可以选择；Dynamo、Cassndra按一致性哈希；Mola、Armor、BigPipe按哈希方式分布；Doris按哈希方式和按数据量分布组合。

三、数据副本协议

1． 副本一定要满足一定的可用性和一致性要求、具体容错能力，即使出现一些问题也能提供可靠服务。

2． 数据副本的基本协议，中心化和去中心化2种基本的副本控制协议。

3． 中心化副本控制协议的基本思路是由一个中心节点协调副本数据的更新、维护副本之间的一致性。中心化副本控制协议的优点是协议相对较为简单，所有的副本相关的控制交由中心节点完成。并发控制将由中心节点完成，从而使得一个分布式并发控制问题，简化为一个单机并发控制问题。控制问题，简化为一个单机并发控制问题。所谓并发控制，即多个节点同时需要修改副本数据时，需要解决“写写”、“读写”等并发冲突。单机系统上常用加锁等方式进行并发控制。对于分布式并发控制，加锁也是一个常用的方法，但如果没有中心节点统一进行锁管理，就需要完全分布式化的锁系统，会使得协议非常复杂。中心化副本控制协议的缺点是系统的可用性依赖于中心化节点，当中心节点异常或与中心节点通信中断时，系统将失去某些服务（通常至少失去更新服务），所以中心化副本控制协议的缺点正是存在一定的停服务时间。即存在单点问题，即使中心化节点是一个集群，也只不过是一个大的单点。

4． 副本数据同步常见问题，1）网络异常，导致副本没有得到数据；2）数据脏读，主节点数据已经更新，但是由于某种原因，没有得到最新数据；3）增加新节点没有得到主节点数据，而读数据时从新节点读数据导致，没有得到数据。

5． 去中心化副本控制协议没有中心节点，协议中所有的节点都是完全对等的，节点之间通过平等协商达到一致。从而去中心化协议没有因为中心化节点异常而带来的停服务等问题。然而，没有什么事情是完美的，去中心化协议的最大的缺点是协议过程通常比较复杂。尤其当去中心化协议需要实现强一致性时，协议流程变得复杂且不容易理解。由于流程的复杂，去中心化协议的效率和性能较低。

6． Paxos是唯一在工程中得到应用的强一致性去中心化副本控制协议。ZooKeeper、Chubby，就是该协议的应用。

Zookeeper用Paxos协议选择Leader，用Lease协议控制数据是否有效。用Quorum协议把Leader的数据同步到follow。

Zeekeeper，实现Quorum写入时，如果没有完全写入成功，则所有的follow机器，反向向Leader写数据，写入数据后follow又向Leader同步数据，保持一致，如果是失败的数据先写入，你们follow同步到原来的数据，相对于回滚；如是是最新的数据先写入Leader则就是完成了最新数据的更新。

7． Megastore，使用的是改进型行Paxos协议。

8． Dynamo / Cassandra使用基于一致性哈希的去中心化协议。Dynamo使用Quorum机制来管理副本。

9． Lease机制是最重要的分布式协议，广泛应用于各种实际的分布式系统中。1）Lease通常定义为：颁发者在一定期限内給予持有者一定权利的协议。2）Lease 表达了颁发者在一定期限内的承诺，只要未过期颁发者必须严格遵守 lease 约定的承诺；3）Lease 的持有者在期限内使用颁发者的承诺，但 lease 一旦过期必须放弃使用或者重新和颁发者续约。4）的影响。中心服务器发出的lease的含义为：在lease的有效期内，中心服务器保证不会修改对应数据的值。5）可以通过版本号、过多上时间、或者到某个固定时间点认为Lease证书失效。

其原理和我们的Cache一样，比如浏览器缓存道理一致。其要求时间时钟同步，因为数据完全依赖于期限。

10． 心跳（heartbeat）检测不可靠,假如检测及其Q，被检测机器A，可能由于Q发起检测，但是A的回应被阻塞，导致Q 认为A宕机，阻塞很快恢复，导致根据心跳检测来做判断不可靠；也可能是他们之间的网络断开；也可能是Q机器本身异常导致认为A机器宕机；如果根据Q的检测结果，来判断很可能出现多个主机的情况。

11． Write-all-read-one（简称WARO）是一种最简单的副本控制规则，顾名思义即在更新时写所有的副本，只有在所有的副本上更新成功，才认为更新成功，从而保证所有的副本一致，这样在读取数据时可以读任一副本上的数据。写多份，读从其中一份读取。

12． quorum协议，其实就是读取成功的副本数大于失败的副本数，你们读取的副本里面一定包含了最新的副本。

13． Mola*和Armor*系统中所有的副本管理都是基于Quorum，即数据在多数副本上更新成功则认为成功。

14． Big Pipe*中的副本管理也是采用了WARO机制。

总结

以 上就是我对Java开发分布式系统特点设计与原理分析问题及其优化总结，分享给大家，希望大家可以了解什么是Java开发分布式系统特点设计与原理分析问题及其优化。觉得收获的话可以点个关注收藏转发一波喔，谢谢大佬们支持！

1、多写多敲代码，好的代码与扎实的基础知识一定是实践出来的

2、可以去百度搜索腾讯课堂图灵学院的视频来学习一下java架构实战案例，还挺不错的。

最后，每一位读到这里的网友，感谢你们能耐心地看完。希望在成为一名更优秀的Java程序员的道路上，我们可以一起学习、一起进步。

3丶想了解学习以上课程内容可加群：469717771 验证码（06 必过）

帅的人都已经点赞了~.~

今日头条号:搜索 "JavaLeader"  (欢迎大家关注支持，头条更精彩)

java资源分享总群(六) :238600498       java招聘信息共享群：489895481

 java微信技术群:微信搜索18335013040加好友，拉入群内。