work|分布式系统设计理念为何这么难学?


work|分布式系统设计理念为何这么难学?
本文插图
work|分布式系统设计理念为何这么难学?
本文插图

分布式系统
身为二十一世纪的一名程序员 , 没听说过分布式系统就显得自己好像没有女票一样尴尬 。 无论是出去面试跟面试官吹水 , 还是在工作中和同事吹水 , 分布式系统永远是你显得高人一等的筹码 。 分布式系统已经诞生了好几十年 , 说起来比我们八零后程序员好要老成 , 随着现代互联网的崛起 , 对于系统在性能 , 可靠性上的要求大大提高 。
分布式系统的定义其实很简单 , 也很抽象:任何由处于不同物理位置的多个进程提供相同服务的系统都可以称之为分布式系统 , 退一万步讲 , 同一台服务器上的不同进程也可以组成分布式系统
分布式系统的首要目标是提高系统的整体性能 , 但不仅限于吞吐量 , 可靠性 , 响应时间 , 数据一致性等 , 其中提高性能指标是最重要的 。 如果最终设计出来的分布式系统占用了更多的资源却还比不上单机的性能 , 那这个分布式系统是失败的 , 理论上没有存在的价值
一个分布式系统的整体性能提高并不是单单依靠扩展来实现 , 提高单机的处理性能仍然很重要 , 一个把单机性能发挥到极致的分布式系统 , 在同等性能的需求下 , 采用的资源要远远小于其他系统 。

分布式系统痛点
一个好的分布式系统在性能方面要远超单机系统 , 但是在数据行为方面要表现的和单机系统一样优秀 , 其中包括数据的一致性 , 硬件的故障发生率 , 网络的不稳定性等 。
无论是单机系统还是分布式系统都存在无法回避并且无法彻底去除的风险 , 比如:硬盘发生故障 , 网络发生瘫痪 , 光纤被挖.....分布式系统随着节点的增加 , 把这些故障的发生率也随之增大 , 所以分布式系统其中一个目标是要尽量降低这些风险 , 也就是所谓的容错性 。
既要快还要不出错 , 这在“伦理”上是冲突的 。 就像我们平时说的分布式锁 , 如果要保证对一个资源的修改不会发生线程安全问题 , 就要付出降低性能的代价 。 至于性能和容错性怎样选择 , 还需要具体到每个业务场景中 , 比如支付场景中 , 数据的正确性可能要比性能指标更重要 , 而那些日志型数据 , 比如用户的登录日志 , 这些数据的最大特点就是允许小部分丢失 , 在这样的日志系统设计中 , 可能性能指标要大于容错性 。
目前烂大街的CAP原则的讲解 , 是针对分布式系统的一个抽象理论 , 包括之后BASE理论 , 也是针对分布式系统的一种指导方案 。
work|分布式系统设计理念为何这么难学?
本文插图

设计分布式系统

分布式系统的特性就决定了它自出生之日起 , 就有多个节点如何协同工作的难题 。 就像一个团队 , 如果让这个团队有条不紊的工作本来就是个难题 。 一堆节点为了完成同样的任务 , 注定需要一个规范方圆的规则 。 就目前已知的方案中 , 主要有中心化和去中心化两种解决方案
中心化
中心化的分布式设计理念是目前主流的方案 , 在中心化的设计方案中 , 节点是有角色区分的:Leader节点和Work节点 , 即:领导和干活的 。 就和现实中类似 , leader只负责分发任务和监督 , Work节点只负责领取任务干活 , 多说一句 , 这里Work节点领取任务 , 当然从通信的角度来说 , 又可以分为push和pull(推和拉)方式 。 推方式是指 , leader节点主动将任务分发给Work节点 , 拉方式是指:Work节点主动去申请任务 。 至于push和pull的优缺点 , 不作为今天的主题展开讨论 。

work|分布式系统设计理念为何这么难学?


推荐阅读