分布式系统专题一:分布式系统介绍

1、发展背景

一、单一应用架构
当网站流量很小时,只需一个应用,将全部功能都部署在一块儿,以减小部署节点和成本。。前端

二、垂直应用架构
当访问量逐渐增大,单一应用增长机器带来的加速度愈来愈小,将应用拆成互不相干的几个应用,以提高效率。java

三、分布式服务架构
当垂直应用愈来愈多,应用之间交互不可避免,将核心业务抽取出来,做为独立的服务,逐渐造成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。mysql

2、什么是分布式系统?

《分布式系统原理和范型》一书中是这样定义分布式系统的:“分布式系统是若干独立计算机的集合,这些计算机对于用户来讲就像是单个相关系统”。
从进程角度看,两个程序分别运行在两台主机的进程上,它们相互协做最终完成同一个服务(或者功能),那么理论上这两个程序所组成的系统,也能够称做是“分布式系统”。
固然,这个两个程序能够是不一样的程序,也能够是相同的程序。若是是相同的程序,咱们又能够称之为“集群”。所谓集群,就是将相同的程序,经过不断横向扩展,以提升服务能力的方式。web

分布式和微服务
微服务架构偏向于业务,好比能够将微服务按子业务、数据库、接口等维度拆分红不一样的微服务
分布式架构偏向于机器,目前,你能够说微服务架构都是分布式架构,由于目前大部分公司都是把每一个服务单独部署的

3、分布式系统所遇到的挑战

(一)分布式session

好比user第一个请求到机器A,第二个请求却被分配到机器B,那么就会存在session的问题;由于机器B读不到user在机器A上的session;redis

  1. Session粘滞
    即粘性Session、当用户访问集群中某台机器后,强制指定后续全部请求均落到此机器上
    使用场景:机器数适中、对稳定性要求不是很是苛刻
    优势:实现简单、配置方便、没有额外网络开销
    缺点:网络中有机器Down掉时、用户Session会丢失、容易形成单点故障
    方案:Nginx的ip_hash负载均衡方案
  2. Session复制
    将一台机器上的Session数据广播复制到集群中其他机器上
    使用场景:机器较少,网络流量较小
    优势:实现简单、配置较少、当网络中有机器Down掉时不影响用户访问
    缺点:广播式复制到其他机器有必定廷时,带来必定网络开销
    方案:开源方案tomcat-redis-session-manager,暂不支持Tomcat8
  3. 缓存集中式管理
    将Session存入分布式缓存集群中的某台机器上,当用户访问不一样节点时先从缓存中拿Session信息
    使用场景:集群中机器数多、网络环境复杂
    优势:可靠性好
    缺点:实现复杂、稳定性依赖于缓存的稳定性、Session信息放入缓存时要有合理的策略写入
    方案:开源方案Spring Session,也能够本身实现,主要是重写HttpServletRequestWrapper中的getSession方法

(二)分布式配置中心

在分布式系统中,一次构建、发布、上线是很是很是重的一个过程,它不像单机时代那样重启一台机器、一个进程就能够了,在分布式系统中,它涉及到将软件包(例如war)分发到可能超过几千台机器,而后将几千台机器上的应用进程一一重启,这么一个过程,超过2000台机器的一个应用一次完整的发布过程须要很长时间。
那么如何在不停应用集群的状况下,调整整个集群的运行时的行为特征,是一个分布式系统必须回答的一个问题。从这个角度讲, 咱们认为: 每个大型分布式系统都应该有一个配置中心!
咱们平时常见的分布式系统的配置变动,诸如:
• 线程池、链接池大小
• 开关、限流配置
• 数据源主备容灾切换
• 路由规则算法

开源解决方案
一、disconf,百度开源,与spring集成的很好,有web管理,client只支持java。
二、diamond,阿里开源,阿里内部应用普遍,由http server(nameservers), diamond-server ,web组成,diamond-server链接同一个mysql,数据同步经过mysql dump文件同步(同步效率?),支持订阅发布,client只支持java。
三、doozer,已中止更新,设计倾向于实时的数据变动通知,数据所有放于内存,不会持久化文件。
四、etcd,CoreOS开源,轻量级分布式key-value数据库,同时为集群环境的服务发现和注册而设计,它提供了数据TTL失效(经过TTL更新来判断机器下线,来避免必定的网络分区问题)、数据改变监视、多值、目录监听、分布式锁原子操做等功能,来管理节点状态。
五、zookeeper,成熟的分布式配置解决方案。spring

(三)分布式事务

分布式事务解决的用户最本质诉求是什么?数据一致
大中企业有一个共同的诉求是数据一致,几乎覆盖到各个行业。
好比说零售行业,库存与出货的数据须要保持一致,出货量与库存数据不匹配,显而易见会出问题,拿到订单却没货了,或者有货却下不了订单。
好比说金融行业,转帐数据搞错了,A扣款了,B没加上,立刻该用户投诉了;A没扣款,B却加上了,产生资损;又好比从总帐户中买了基金、股票后余额不对了,等等,都会致使严重问题。
随着互联网技术快速发展,数据规模增大,分布式系统愈来愈普及,采用分布式数据库或者跨多个数据库的应用在中大规模企业广泛存在,服务化也是普遍应用,因为网络的不可靠和机器不可靠,数据不一致问题很容易出现。
数据一致性问题是必须解决的,在不少大企业多年前就已经成为突出问题,他们是怎么解决的?有这么几个典型方案:
• XA事务方案
• 柔性事务
• 基于消息的最终一致
• 业务补偿与人工订正sql

(四)分布式锁

目前几乎不少大型网站及应用都是分布式部署的,分布式场景中的数据一致性问题一直是一个比较重要的话题。
分布式的CAP理论告诉咱们,任何一个分布式系统都没法同时知足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance),最多只能同时知足两项。
因此,不少系统在设计之初就要对这三者作出取舍。在互联网领域的绝大多数的场景中,都须要牺牲强一致性来换取系统的高可用性,系统每每只须要保证“最终一致性”,只要这个最终时间是在用户能够接受的范围内便可。
在不少场景中,咱们为了保证数据的最终一致性,须要不少的技术方案来支持,好比分布式事务、分布式锁等。有的时候,咱们须要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中,Java中其实提供了不少并发处理相关的API,可是这些API在分布式场景中就无能为力了。也就是说单纯的Java Api并不能提供分布式锁的能力。因此须要须要针对分布式环境提供锁的能力。数据库

一、常见的分布式锁的实现方案
1)mysql
2)内存数据库(redis、redisson、memcached等)
3)zookeeper缓存

5、CAP理论

在这里插入图片描述
一个分布式系统最多只能同时知足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。

一、Consistency 一致性
一致性分为强一致性、弱一致性、最终一致性

好比有一个Mysql集群(Mysql-A,Mysql-B),Mysql中由一份数据初始值为1,如今有一个用户User,User有两步操做:
1)修改Mysql集群中的数据为2;(假设,修改的是Mysql-A,Mysql-B中的更改须要同步)
2)读取Mysql集群中的数据;(假设,读取的是Mysql-B)
若是:
强制要求步骤2读取的时候,必定要读取的是2,不能读取到的是1,那么要求Mysql之间同步很是迅速或者在步骤2上加锁以等待数据同步完成,那么这种叫强一致性;
容许步骤2读取的时候,能够读取的是1,那么这种叫弱一致性,其实就是不须要要一致;
容许步骤2读取的时候,能够先读到1,过一段时间再读到2,那么这种叫最终一致性,就是能够等待一段时间才一致;

CAP中的一致说的是强一致性

二、Availability 可用性
可用性指服务一直可用,并且是正常响应时间。
好的可用性主要是指系统可以很好的为用户服务,不出现用户操做失败或者访问超时等用户体验很差的状况。一个分布式系统,上下游设计不少系统如负载均衡、WEB服务器、应用代码、数据库服务器等,任何一个节点的不稳定均可以影响可用性。

三、Partition Tolerance分区容错性
分区容错性指,即分布式系统在遇到某节点或网络分区故障的时候,仍然可以对外提供知足一致性和可用性的服务。

分区容错性和扩展性紧密相关。在分布式应用中,可能由于一些分布式的缘由致使系统没法正常运转。好的分区容错性要求可以使应用虽然是一个分布式系统,而看上去却好像是在一个能够运转正常的总体。好比如今的分布式系统中有某一个或者几个机器宕掉了,其余剩下的机器还可以正常运转知足系统需求,或者是机器之间有网络异常,将分布式系统分隔为独立的几个部分,各个部分还能维持分布式系统的运做,这样就具备好的分区容错性。
简单点说,就是在网络中断,消息丢失的状况下,系统若是还能正常工做,就是有比较好的分区容错性。

知足分区容错性的分布式系统,只能在一致性和可用性二者中,选择其中一个。
证实文章能够读CAP定理

四、CA without P,保证可用性和一致性,不要分区容错性
这种状况在分布式系统中几乎是不存在的。首先在分布式环境下,网络分区是一个天然的事实。由于分区是必然的,因此若是舍弃P,意味着要舍弃分布式系统。
对于一个分布式系统来讲。P是一个基本要求,CAP三者中,只能在CA二者之间作权衡,而且要想尽办法提高P。

五、CP without A,保证一致性和分区容错性,牺牲可用性
若是一个分布式系统不要求强的可用性,即允许系统停机或者长时间无响应的话,就能够在CAP三者中保障CP而舍弃A。
一个保证了CP而舍弃了A的分布式系统,一旦发生网络故障或者消息丢失等状况,就要牺牲用户的体验,等待全部数据所有一致了以后再让用户访问系统。
设计成CP的系统其实也很多,其中最典型的就是不少分布式数据库,他们都是设计成CP的。在发生极端状况时,优先保证数据的强一致性,代价就是舍弃系统的可用性。如Redis、HBase等,还有分布式系统中经常使用的Zookeeper也是在CAP三者之中选择优先保证CP的。

六、AP wihtout C,保证可用性和分区容错性,牺牲一致性
要高可用并容许分区,则需放弃一致性。一旦网络问题发生,节点之间可能会失去联系。为了保证高可用,须要在用户访问时能够立刻获得返回,则每一个节点只能用本地数据提供服务,而这样会致使全局数据的不一致性。

七、按场景选择合适的
对于涉及到钱财这样不能有一丝让步的场景,C必须保证。网络发生故障宁肯中止服务,这是保证CP,舍弃A。好比前几年支付宝光缆被挖断的事件,在网络出现故障的时候,支付宝就在可用性和数据一致性之间选择了数据一致性,用户感觉到的是支付宝系统长时间宕机,可是其实背后是无数的工程师在恢复数据,保证数数据的一致性。
对于其余场景,比较广泛的作法是选择可用性和分区容错性,舍弃强一致性,退而求其次使用最终一致性来保证数据的安全。这实际上是分布式领域的另一个理论–BASE理论

6、BASE理论

BASE理论
BASE理论是对CAP理论的延伸,核心思想是即便没法作到强一致性(Strong Consistency,CAP的一致性就是强一致性),但应用能够采用适合的方式达到最终一致性。

BASE是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency)。
一、基本可用(Basically Available)
基本可用是指分布式系统在出现故障的时候,容许损失部分可用性,即保证核心可用。
电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务。这就是损失部分可用性的体现。

二、软状态( Soft State)
软状态是指容许系统存在中间状态,而该中间状态不会影响系统总体可用性。分布式存储中通常一份数据至少会有三个副本,容许不一样节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

三、最终一致性( Eventual Consistency)
最终一致性是指系统中的全部数据副本通过必定时间后,最终可以达到一致的状态。弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊状况。

因为BASE理论须要在一致性和可用性方面作出权衡,所以涌现了不少关于一致性的算法和协议:
1) 两阶段提交
2)三阶段提交
3)Paxos算法
4)Zab协议

7、分布式定时任务

首先,咱们要了解计划任务这个概念,计划任务是指由计划的定时运行或者周期性运行的程序。咱们最多见的就是Linux的‘crontab’和Windows的‘计划任务’。
那么什么是分布式定时任务,我的总结为:把分散的,可靠性差的计划任务归入统一的平台,并实现集群管理调度和分布式部署的一种定时任务的管理方式。叫作分布式定时任务。
一、单点定时任务的缺点:
1)功能相对简单,交互性差,任务部署效率低,开发和维护成本比较高,不能很好的知足各系统定时任务的管理和控制,尤为在多系统的环境下更加明显;
2)许多任务都是单机部署,可用性差;
3)任务跟踪和告警难以实现。

二、分布式定时任务的优点:
1)经过集群的方式进行管理调度,大大下降了开发和维护成本;
2)分布式部署,保证了系统的高可用性,伸缩性,负载均衡,提升了容错;
3)能够经过控制台部署和管理定时任务,方便灵活高效;
4)任务均可以持久化到数据库,避免了宕机和数据丢失带来的隐患,同时有完善的任务失败重作机制和详细的任务跟踪及告警策略。

三、流行的分布式定时任务框架
1)Quartz:Quartz是Java领域最著名的开源任务调度工具。Quartz提供了极为普遍的特性如持久化任务,集群和分布式任务
2)Elastic-job:Elastic-Job是ddframe中dd-job的做业模块中分离出来的分布式弹性做业框架。去掉了和dd-job中的监控和ddframe接入规范部分。该项目基于成熟的开源产品Quartz和Zookeeper及其客户端Curator进行二次开发。
分布式系统问题的本质
分布式各系统中间都须要进行网络通讯,因此原本在单一架构中能保证的数据一致性,升级为分布式系统后数据的一致性就难以保证,而Zookeeper的诞生就能够解决这个本质问题:数据一致性,再加上zookeeper的其余特性还能够解决分布式锁,分布式定时任务等等场景问题。

以上均为鲁班学院学习资料,欢迎你们报班学习,真心推荐!