分布式系统架构理论与组件

1.分布式系统的发展

在计算机发展的早期,一直都是集中式计算,计算能力依赖大型计算机。随着互联网的发展,繁重的业务需要巨大的计算能力才能完成,而集中式计算无法满足要求,大型计算机的价格也非常昂贵。分布式计算将任务分解成更小的部分,分配给多台计算机处理,这样可以节约整体计算时间,大大提高计算效率。

互联网大型网站往往面临高并发访问、海量数据处理等问题,必须保证系统高可用、易伸缩等等。分布式架构采用多台机器协同工作,动态伸缩容量,使用冗余节点来消除单点故障,提高系统可用性。

2.分布式系统的挑战

软件开发没有银弹,任何系统结构都有利有弊,分布式系统的挑战有三点:

  • 1)网络资源受限:节点间采用网络通信,而网络存在带宽限制和延时,任何一个节点都无法做到瞬间响应和高吞吐量。
  • 2)节点管理成本:分布式系统节点可能膨胀到成千上万个,运维节点的成本非常高。
  • 3)缺乏全局时钟:网络上计算机时钟同步的准确性受到极大的限制,没有一致的全局时间。计算机在空间随意分布,很难定义不同机器上事件先后发生顺序。

3.分布式系统基本理论

3.1 CAP定理

分布式系统的三个特性Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性),最多只能同时满足其中两个,三者不可兼得。

  • Consistency (一致性):数据更新后,所有节点在同一时间的数据完全一致。客户端并发访问时,返回的数据是一致的。服务端尽快将数据复制到整个系统,以保证数据最终一致。
  • Availability (可用性):系统能够一直为用户服务,不出现操作失败或者超时等情况。在单位时间内的可用性常用N个9来衡量,比如99.999%的可用性。
  • Partition Tolerance (分区容错性):分布式系统内部由许多节点构成,外界看上去是一个整体。节点或网络分区遇到故障的时候,仍然能够对外提供满足一致性或可用性的服务。系统中少量机器宕掉,剩下的机器还能够正常运转,用户没有任何感知。

大型互联网应用的集群节点非常多,发生节点或者网络故障是常态。系统必须要满足分区容错性,最终只能在C和A之间取舍。

传统行业项目有所不同,以金融系统为例,涉及到金钱的操作,必须要满足数据一致性。出现网络故障宁可停止服务,也要保证C,最终只能在A和P之间取舍。

3.2 PACELC理论

CAP理论并不能很好的指导现实的系统架构。比如Availability (可用性),如果接口长时间才返回结果,固然可用,但是业务上不能接受。大部分情况下,系统分区都是平稳运行的,系统设计要权衡延迟与数据一致性的问题。为了保证数据一致性,读写的延迟必然升高。

在分区错误的情况下,在C和A中取舍,缩写为 PAC。分区正确的情况下,取 Latency(延迟)与 Consistency(一致性),缩写为LC。PACELC 中的 E 代表 Else,连起来就是PACELC。

很多存储软件实现了 PACELC 的策略,用户根据不同业务场景使用不同的配置。以MySQL主从复制为例,提供了三种模式:

  • 异步模式:主库执行完客户端提交的事务,立即将结果返给客户端,不关心从库是否已经接收并处理。由于数据同步的延时,客户端在从库上可能读不到最新数据。这种模式对MySQL是性能最佳的,但是用户需要权衡,业务能否忍受这种延时。
  • 全同步复制:主库执行完客户端提交的事务,所有的从库都执行了该事务才返回结果。这样保证强一致性,但是响应时间变长了。
  • 半同步
  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值