架构的演进过程
1、业务简单、系统功能单一、访问量小的场景下:单节点web应用架构。
2、业务和系统功能相对复杂、访问量较大的场景下:Nginx负载的多web节点集群架构。
3、业务复杂、系统庞大、访问量巨大的场景下:分布式微服务架构。
分布式架构的特点
分布性
对等性
并发性
缺乏全局时钟
故障随时会发生
分布式架构中存在的问题
通信异常:
通讯异常其实就是网络异常,网络系统本身是不可靠的,由于分布式系统需要通过网络进行数据传输,网络光纤,路由器等硬件难免出现问题。只要网络出现问题,也就会影响消息的发送与接受过程,因此数据消息的丢失或者延长就会变得非常普遍。
网络分区:
网络分区,俗称“脑裂现象”,是指集群中本来只有一个领导者,但由于通信异常,导致某一区域自行推举出另外一个领导,两个领导互为冲突。
三态:
通常情况下,方法执行的结果是一个明确的响应,要么成功,要么失败。而在分布式的场景下,会出现以一种除成功和失败以外的第三种状态—超时态。虽然绝大多数的情况下能够接受到成功或失败的响应,但网络一旦出现异常,就非常有可能超时,这时请求的发起方是无法确定请求是否处理成功的。
节点故障:
组成分布式集群的节点机器比较多,节点出现宕机或“僵死”的现象会经常发生。
分布式协调理论
CAP理论
C 一致性(Consistency):在分布式系统中,一致性是数据在多个副本之间是否能够保证一致的特性。
A 可用性(Availability):系统收到请求后,一定给出响应。
P 分区容错性(Partition tolerance):大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区(partition)。分区容错的意思是,区间通信可能失败。比如,一台服务器放在中国,另一台服务器放在美国,这就是两个区,它们之间可能无法通信。
一个分布式系统不可能同时满足一致性、可用性、分区容错性这三个基本需求,最多只能够满足其中两项。由于分布式系统中P总是成立,所以架构师的精力往往集中在根据业务场景,寻求A和C的平衡。
序号 | 被放弃的 | 说明 |
---|---|---|
1 | 放弃P(满足AC) | 将数据和服务都放在一个节点上,避免由于网路问题引起的负面影响,充分保证一致性和可用性。放弃P意味着放弃系统的扩展性。 |
2 | 放弃A(满足CP) | 当节点故障或网络故障时,受影响的服务需要等待一段时间才能恢复响应,在此期间系统无法对外提供正常服务。 |
3 | 放弃C(满足AP) | 系统无法保证数据的实时一致性,但是承诺数据最终会保持一致性。因此存在数据不一致的窗口期,窗口期时间的长短取决于系统设计。 |
BASE理论
即使无法做到强一致性,但分布式系统可以根据自己的业务特点,采用适当的方式来使系统达到最终的一致性。
Basically Avaliable 基本可用:当分布式系统出现不可预见的故障时,允许损失部分可用性,保障系统的“基本可用”;体现在“时间上的损失”和“功能上的损失”;如:部分用户双十一高峰期淘宝页面卡顿或降级处理;
Soft state 软状态:允许系统中的数据存在中间状态,既系统的不同节点的数据副本之间的数据同步过程存在延时,并认为这种延时不会影响系统可用性;如:12306网站卖火车票,请求会进入排队队列。
Eventually consistent 最终一致性:所有的数据在经过一段时间的数据同步后,最终能够达到一个一致的状态;如:理财产品首页充值总金额短时不一致;
分布式协调一致性的算法
序号 | 算法 | 说明 |
---|---|---|
1 | 2p/3p | 2P两阶段提交,数据分布式事务经常使用的一种分布式算法,算法简单,但会出现阻塞,数据在某种情况下不一致的问题。 3P对2P进行了完善。 |
2 | paxos | 分布式一致性算法,分为两阶段,遵循少数服从多数的原则,并不需要所有参与者都同意某一协议。 |
3 | zab | 借鉴paxos的思想,是zookeeper解决分布式一致性所使用的算法。 |
今天的文章什么是分布式?分享到此就结束了,感谢您的阅读。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/10219.html