创建网站需要哪些过程,南昌网站建设q479185700棒,高碑店地区网站建设,国际外贸网站点击“蓝字”关注我们吧福利#xff1a;有件小事想和大家说一下菜菜哥#xff0c;问你个问题#xff0c;为什么现在的系统都设计为分布式系统呢#xff1f;这个问题问得好#xff0c;就像为什么程序员会慢慢脱发一样神奇01PART分布式系统身为二十一世纪的一名程序员#… 点击“蓝字”关注我们吧福利有件小事想和大家说一下菜菜哥问你个问题为什么现在的系统都设计为分布式系统呢这个问题问得好就像为什么程序员会慢慢脱发一样神奇01PART分布式系统身为二十一世纪的一名程序员没听说过分布式系统就显得自己好像没有女票一样尴尬。无论是出去面试跟面试官吹水还是在工作中和同事吹水分布式系统永远是你显得高人一等的筹码。分布式系统已经诞生了好几十年说起来比我们八零后程序员好要老成随着现代互联网的崛起对于系统在性能可靠性上的要求大大提高。分布式系统的定义其实很简单也很抽象任何由处于不同物理位置的多个进程提供相同服务的系统都可以称之为分布式系统退一万步讲同一台服务器上的不同进程也可以组成分布式系统分布式系统的首要目标是提高系统的整体性能但不仅限于吞吐量可靠性响应时间数据一致性等其中提高性能指标是最重要的。如果最终设计出来的分布式系统占用了更多的资源却还比不上单机的性能那这个分布式系统是失败的理论上没有存在的价值一个分布式系统的整体性能提高并不是单单依靠扩展来实现提高单机的处理性能仍然很重要一个把单机性能发挥到极致的分布式系统在同等性能的需求下采用的资源要远远小于其他系统。02PART分布式系统痛点一个好的分布式系统在性能方面要远超单机系统但是在数据行为方面要表现的和单机系统一样优秀其中包括数据的一致性硬件的故障发生率网络的不稳定性等。无论是单机系统还是分布式系统都存在无法回避并且无法彻底去除的风险比如硬盘发生故障网络发生瘫痪光纤被挖.....分布式系统随着节点的增加把这些故障的发生率也随之增大所以分布式系统其中一个目标是要尽量降低这些风险也就是所谓的容错性。既要快还要不出错这在“伦理”上是冲突的。就像我们平时说的分布式锁如果要保证对一个资源的修改不会发生线程安全问题就要付出降低性能的代价。至于性能和容错性怎样选择还需要具体到每个业务场景中比如支付场景中数据的正确性可能要比性能指标更重要而那些日志型数据比如用户的登录日志这些数据的最大特点就是允许小部分丢失在这样的日志系统设计中可能性能指标要大于容错性。目前烂大街的CAP原则的讲解是针对分布式系统的一个抽象理论包括之后BASE理论也是针对分布式系统的一种指导方案。分布式系统这么复杂那设计一个分布式系统看来很难了什么叫很难那叫非常难03PART设计分布式系统分布式系统的特性就决定了它自出生之日起就有多个节点如何协同工作的难题。就像一个团队如果让这个团队有条不紊的工作本来就是个难题。一堆节点为了完成同样的任务注定需要一个规范方圆的规则。就目前已知的方案中主要有中心化和去中心化两种解决方案中心化中心化的分布式设计理念是目前主流的方案在中心化的设计方案中节点是有角色区分的Leader节点和Work节点即领导和干活的。就和现实中类似leader只负责分发任务和监督Work节点只负责领取任务干活多说一句这里Work节点领取任务当然从通信的角度来说又可以分为push和pull推和拉方式。推方式是指leader节点主动将任务分发给Work节点拉方式是指Work节点主动去申请任务。至于push和pull的优缺点不作为今天的主题展开讨论。在任何系统中都无可避免的需要考虑节点down掉的问题分布式系统也一样。在中心化分布式设计中leader和Work也一样都存在down掉的可能性。如果leader掉的话整个系统都陷入瘫痪按照最简单的设计思路leader节点需要一个从节点或者备用节点在主节点down掉之后从主节点或者备用主节点可以手动或者自动实现leader节点服务。至于一个Work节点down掉一般不会使整个系统陷入瘫痪除非全部Work节点同时down掉。一个Work节点down掉但是会影响这个节点当前正在执行的任务所以在必要的条件下可以设计成任务需要Ack才好即一个任务的完成需要确认如果长时间没有确认leader会发起重新分配任务的操作。说到leader的问题现在目前大多数分布式系统都具备了自动选举leader的功能这还要感谢paxosraft等选举算法。在leader不可用的时候这些系统会自动根据节点情况选举出新的leader节点来继续提供服务这大大提高了系统可用性。在所有的中心化设计中数据的写操作都发生在leader节点这在某种程度上类似于单机系统所以这种中心化设计并不适合那些大量写的操作。去中心化在去中心化分布式系统设计中节点类型并不区分Leader和Work所有节点都是相等的。所以任何一个节点down掉都不会导致整个系统瘫痪这是它的优势。但是获取系统中每个节点的信息却比中心化设计要难很多在中心化设计中leader节点存储着系统中所有的节点信息并可以实时把这些信息同步到其他节点同时可以利用相应算法来达到一致性的要求。去中心化的设计中每个节点只能依靠和其他节点不断通信来获取整个系统的节点信息这在技术难度上要比中心化高出很多。在网络中网络是不可靠的。恰恰是这个原因又加大了每个节点互相通信的难度。在极限情况下去中心化的设计方案会出现多个小范围的“团伙”这就是所说的脑裂。比如现在一个由10个节点组成的分布式系统有可能由于网络原因会划分为两个5节点互相通信的两个“团伙”如果出现脑裂的情况目前主流的解决方案和数据库死锁的处理情况类似自爆一个对系统影响比较小的。那我们设计分布式系统的时候是不是优先选择中心化方案呢这个问题就像是选择型数据库是选择关系型还是非关系型一个道理而目前多数的做法是采用扬长避短互相补充的方案那就是混用哦可以这么说分布式系统也一个道理完全中心化和去中心化的系统并不常见反而现在慢慢出现的是二者的搭配者表面看似去中心化设计理念却是中心化的思路在这种架构下leader是程序根据某种算法选举出来的而且在系统leader发生故障的时候系统会自动重新选举leader节点。04PART写在最后对于每个系统来说可靠性是它要实现的主要目标之一尤其是分布式系统。在网络通信硬件设备等条件都非100%可靠的情况下如何提高分布式系统的可用性是一个很深的话题。就算是国内顶尖的BAT等大厂也没有一个系统能达到100%的可用性4个9的可用性已经是很巅峰了。分布式系统本质上是多个节点通过网络IO组成的其中夹杂着一些不可抗拒的元素所以请记住一句话分布式系统是不可靠的我们只能尽量减小故障发生率却根除不了如果你的老板要你设计一套100%可用性的系统要么他是二货要么他是二B●程序员修神之路--为什么我会了SOA你们还要逼我学微服务●程序员过关斩将--数据库的乐观锁和悲观锁并非真实的锁●程序员修神之路--设计一套RPC框架并非易事●程序员过关斩将--要想获取我的用户信息就得按照规矩来●程序员过关斩将--更加优雅的Token认证方式JWT●程序员过关斩将--cookie和session的关系其实很简单●程序员修神之路--用NOSql给高并发系统加速●程序员修神之路--高并发系统设计负载均衡架构●程序员过关斩将--你为什么还在用存储过程●程序员修神之路--问世间异步为何物●程序员修神之路--提高网站的吞吐长按添加菜菜好友关注后回复“大礼包”和“福利”领取惊喜
