分布式系统介绍

什么是分布式系统

分布式系统是若干独立计算机的集合，这些计算机对于用户来说像是单个相关系统。

从进程角度看，两个程序分别运行在两台主机的进程，它们相互协作最终完成同一个服务（或者功能），那么理论上两个程序组成的系统，可以称作是“分布式系统”。

两个程序可以使不同程序，也可以是相同程序。如果是相同程序，我们可以称之为“集群”。集群就是将相同的程序，通过不断横向扩展，以提高服务能力的方式。

微服务和分布式

微服务架构偏向业务，比如可以将微服务按子业务，数据库，接口等维度拆分成不同的微服务。
分布式架构偏向于机器，目前可以说微服务架构都是分布式架构，因为目前大多数情况是把每个服务单独部署的。

分布式系统所遇到的挑战

分布式session

session粘滞

当用户访问集群某台机器后，强制指定后续所有请求均落在此机器上（目前F5的方案）
使用场景：机器数适中、对稳定行要求不是非常严苛。
优点：实现简单、配置方便、没有额外网络开销
缺点: 网络有机器Down掉是，用户session会丢失、容易造成单点故障
方案：Nginx的ip_hash 负载均衡方案

Session复制

将一台机器上的session数据广播复制到集群其余机器上
使用场景:机器较少，网络流量小
优点：实现简单，配置较少，当网络有机器down时不影响用户访问
缺点：广播式复制到其余机器有一定延时，带来一定的网络开销
方案：开源方案：tomcat-redis-session-manager

缓存集中式管理

将Session存入分布式缓存集群中的某台机器，当用户访问不同节点时从缓存中拿Session信息
使用场景：集群机器数多，网络环境复杂
优点：可靠性好
缺点：实现复杂、稳定性依赖于缓存的稳定性、Session信息放入缓存时有合适的策略写入
方案：开源方案 Spring Session，也可以自己实现，主要重写HttpServletRequestWrapper中的getSession方法。

分布式配置中心

分布式系统中，一次构建、发布、上线是一个非常重要的过程，它不像单机时代重启一台机器、进程就可以，在分布式系统中，它涉及将软件包（war）分发到可能超过几千台机器，然后将几千台上的应用进程分别进行重启，这样的过程，2000台机器一个应用一次完整的发布过程需要很长时间。那么如何在不停应用集群的情况下，调整整个集群的运行时的行为特征，是一个分布式系统必须解决的问题。从这个角度讲，每一个大型分布式系统都应该有个配置中心。
常见的配置变更：

• 线程池、连接池大小
• 开关、限流配置
• 数据源主备容灾切换
• 路由规则

开源方案

etcd、zookeeper

分布式事务

分布式事务解决用户最基本的诉求：数据一致
目前几个选型方案：
XA事务方案
柔性事务
基于消息的最终一致
业务补偿与人工订正

分布式事务

分布式CAP理论告诉我们，任何一个分布式系统都无法同时满足一致性、可用性、分区容错性，最多只能同时满足两项。

在单机环境中，java其实提供很多并发处理相关的API，但是这些API在分布式场景就无能为力。单纯的JAVA API并不能提供分布式锁的能力，需要分布式环境提供锁的能力。

实现方案

1.mysql
2.内存数据库（redis）
3.zookeeper

CAP理论

一致性、可用性、分区容错性

一致性
我们知道ACID中事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行前后，数据库都必须处于一致性状态。也就是说，事务的执行结果必须是使数据库从一个一致性状态转变到另一个一致性状态。

和ACID中的一致性不同，分布式环境中的一致性是指数据在多个副本之间是否能够保持一致的特性。

分布式系统中，数据一般会存在不同节点的副本中，如果对第一个节点的数据成功进行了更新操作，而第二个节点上的数据却没有得到相应更新，这时候读取第二个节点的数据依然是更新前的数据，即脏数据，这就是分布式系统数据不一致的情况。
在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都能读取到最新的值，那么这样的系统就被认为具有强一致性（或严格的一致性）。

可用性
可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果，如果超过了这个时间范围，那么系统就被认为是不可用的。

“有限的时间内”是在系统的运行指标，不同系统会有差别。例如搜索引擎通常在0.5秒内需要给出用户检索结果。

“返回结果”是可用性的另一个重要指标，它要求系统完成对用户请求的处理后，返回一个正常的响应结果，要明确的反映出对请求处理的成功或失败。如果返回的结果是系统错误，比如"OutOfMemory"等报错信息，则认为此时系统是不可用的。

分区容错性
一个分布式系统中，节点组成的网络本来应该是连通的。然而可能因为某些故障，使得有些节点之间不连通了，整个网络就分成了几块区域，而数据就散布在了这些不连通的区域中，这就叫分区。

当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。

提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项仍然能在其他区中读取，容忍性就提高了。然而，把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。

总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。

BASE理论

BASE理论是对CAP理论的延伸，思想是即使无法做到强一致性（CAP的一致性就是强一致性），但可以采用适当的采取弱一致性，即最终一致性。

BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。

基本可用
基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性），允许损失部分可用性。需要注意的是，基本可用绝不等价于系统不可用。

响应时间上的损失：正常情况下搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。

功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。

软状态
软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

最终一致性
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

分布式定时任务

把分散、可靠性差的计划任务统一纳入平台，并实现集群管理和分布式部署的一种定时任务管理方式，叫做分布式定时任务。

单机定时任务缺点

单点定时任务的缺点:

功能相对简单，交互性差，任务部署效率低，开发和维护成本比较高，不能很好的满足各系统定时任务的管理和控制，尤其在多系统的环境下更加明显；
许多任务都是单机部署，可用性差；
任务跟踪和告警难以实现。
分布式定时任务的优势：

通过集群的方式进行管理调度，大大降低了开发和维护成本；
分布式部署，保证了系统的高可用性，伸缩性，负载均衡，提高了容错；
可以通过控制台部署和管理定时任务，方便灵活高效；
任务都可以持久化到数据库，避免了宕机和数据丢失带来的隐患，同时有完善的任务失败重做机制和详细的任务跟踪及告警策略。