单页面网站制作视频,谁做响应式网站,网站显示百度众测是怎么做的,百度网站推广费用多少一、单点故障问题 集群#xff0c;相信诸位对这个概念并不陌生#xff0c;集群已成为现时代中#xff0c;保证服务高可用不可或缺的一种手段。
回想起初集中式部署的单体应用#xff0c;因为只有一个节点#xff0c;因此当该节点出现任意类型的故障#xff08;网络、硬件…一、单点故障问题 集群相信诸位对这个概念并不陌生集群已成为现时代中保证服务高可用不可或缺的一种手段。
回想起初集中式部署的单体应用因为只有一个节点因此当该节点出现任意类型的故障网络、硬件资源、物理环境……时都会造成整个系统对客户端不可用而这就是所谓的“单点故障问题”。 单点故障是建立高可用系统的第一道坎而集群恰恰是解决单点故障最有效的手段就算系统内一个节点出现故障依旧有其他健康的节点能处理请求保障系统正常运行实现99.999……%高可用。
很多人对集群的认知都源自于Nginx因为当程序性能跟不上业务需求、又不想对服务器升配时就可以使用Nginx来加机器使用多台“价格优美”的低配机器为服务做集群化部署从而提升系统整体的吞吐量。
不过许多人对集群的认知止步于此如何实现PB级的海量数据存储大部分人并不清楚而本文则来详细聊聊集群的各方面知识为诸位量身打造出结构化的集群知识体系。 二、集群的定义与分类 集群即是指通过多台物理机器组成一台逻辑上的庞大机器使用集群带来的优势有四
①高可用集群内某个节点故障可迅速将流量迁移至其他节点解决了单点故障②吞吐量多台机器并行处理外部请求可以为系统带来更强大的负载与吞吐能力③拓展性可根据业务的增长/萎靡动态伸缩集群内的节点数量系统更加灵活④性价比无需花费更高的价格升配机器可使用多台价格、配置较低的机器构建。
集群带来的好处很多即解决了单点故障又兼顾了吞吐与性能、动态伸缩、性价比同时对客户端是无感知的客户端在请求时无法分辨出究竟采用了多少台机器来部署服务。
上面是集群的基本定义与优势现在问大家一个问题从性质维度出发你认为集群可以分为哪几种 1.1、集群的分类
集群大家很熟但一问集群的分类估计各位会愣住这……我没想过啊~
其实集群可粗略分为两大类逻辑处理集群、数据存储集群前者对应着业务系统后者对应着数据存储组件举些例子说明
逻辑处理型集群业务服务、API网关、请求分发器、并行运算科学计算服务等数据存储型集群缓存中间件、消息中间件、数据库、搜索中间件集群、对象存储等。
仔细观察下如果熟悉云技术的小伙伴会发现这跟云平台里定义的有状态、无状态概念很类似~
简单来说逻辑处理型的集群只需要处理客户端请求的逻辑运算拿业务系统来说目前有个登录功能系统只需根据业务流程执行完对应的业务逻辑接着就可给客户端响应结果。 PS为了便于后续讲述逻辑处理型集群则用业务系统来代替当提到业务系统时可自动代入“逻辑处理型集群”。 而存储型的集群客户端一般是“程序”如DB、Redis、MQ、ES……生产环境里处理的绝大多数请求都来自于业务系统。对于客户端的请求需要保存信息处理写入请求需要将客户端带来的数据存好处理读取请求则需将之前存好的数据拿出来返回。 当然有人也许会疑惑业务系统不也是读写请求吗为什么将其归类到逻辑处理型这是因为业务系统自身不会存储任何信息客户端用户提交的数据会由业务系统间接调用各类组件来存储如登录信息放到Redis、业务数据放到DB……。 1.2、逻辑处理型集群的核心
在之前的模式中因为只有一台机器域名可直接映射服务器的公网IP当出现对应域名的请求DNS可直接解析到对应的服务器IP客户端如浏览器直接对拿到的IP发起请求就行。 但是当一个业务系统使用多个节点部署组成集群时所面临的最大问题即是请求如何分发到具体服务器 为了解决该问题不得不引入请求分发器域名映射请求分发器所在的IP分发器接到客户端的请求后再分发给具体的业务节点处理。 当外部请求来到分发器时分发器可以在已配置的节点列表中选一台机器负责处理具体的业务请求逻辑。但这里有个问题如何保证各节点的负载均衡呢随机分发貌似不太合适咋办选择合适的分发算法如轮询。
所谓的轮询则是根据配置的节点列表顺序依次分发请求如第一个请求给第一个节点、第二个请求给第二个节点……当分发到最后一个节点时再回到第一个节点周而复始。听起来不错对吧但有个问题来看例子。 现在有个房子要装修打电话定了一车水泥总共六十包目前有四个人在场30岁的男人、9岁的儿子、30岁的老婆、60岁的老爹。 这里的水泥就是请求按照轮询算法六十包、四个人你一拍大腿正好一人十五包合理不显然不合理先不说别的光看九岁儿子那小身板像个能抗十五袋的人不
上述例子换到集群场景中亦是同理组成集群的机器有好有差如果一视同仁站在那些较差的服务器来说请求分发的不够合理因此该如何保证分发的负载均衡 负载均衡是两个词负载即服务器目前承担的压力均衡代表压力一致组合起来就是指集群内各节点承担的压力要一致相同的访问量分发到一台2C4G服务器上CPU利用率经常打到95%但放到8C16G的机器上根本不是事。 综上所述负载均衡要考虑各机器本身的性能这时就得用到一些较为智能的分发算法如
平滑加权轮询算法在轮询的基础上根据机器配置为各节点分配权重值最小活跃数算法根据实际负载情况进行调整自动寻找活跃度最低的节点处理请求最优响应算法根据分发后请求的处理时间新请求到来时分发给响应最快的节点处理……
这些智能化的分发策略能综合考虑机器性能、实际负载、响应速度等因素选择出相对合适的节点处理请求但这里不做过多展开感兴趣可参考《网络编程-请求分发篇》。
1.3、为什么分发器性能那么高
业务系统做集群通常会选择Nginx毕竟它除开提供负载均衡的能力外还能做反向代理避免了将后端服务直接暴露在公网的隐患性可为什么这类负载均衡器性能那么高呢
相同的访问量Nginx可以轻松抗住而后端服务或许要起几个才能勉强处理为啥其实道理很简单因为这类负载均衡器自身并不负责处理请求只是负责做请求分发所以用户的请求在Nginx里逗留的时间极其短暂。
一台机器处理请求的速度越快在相同的时间窗口里其吞吐量更高。除此之外因为不需要处理业务逻辑自然也不存在资源之类的竞争如锁资源并且Nginx底层选用了多路复用模型实际负责分发请求的线程数极少也不存在多线程应用那种线程上下文频繁切换的开销……种种因素下为其高性能表现提供了强有力的支撑。
1.4、双机热备机制
工作年限较长的一点的小伙伴应该在之前的招聘需求上见过这么一条 “具备集群、双机热备等高可用系统经验者优先……” 其中的双机热备技术是指啥所谓的热备机制可以理解成集群技术的另类体现它是一种系统冗余设计方案即同时部署两套系统一主一备主系统和备用系统并行运行。在主系统发生故障时备用系统能迅速接管主系统的工作维持系统正常运作以确保服务的可用性及业务的连续性。
可是有了Nginx这类负载均衡器还要啥热备技术呀恰巧就是Nginx这类组件需要热备技术支持虽然业务系统通过Nginx做了集群化部署避免单点故障造成系统不可用的风险但Nginx就成了“咽喉要地”因为它只有一个节点如果部署Nginx的机器发生故障就会导致外部流量无法分发到业务系统造成整个系统瘫痪。
热备机制如何实现呢可以借助keepalived、TurbolinuxTurboHA、Heartbeat这类专门保障高可用的技术栈实现建设热备机制时要考虑几点
①当进程出现故障内存溢出、进程宕机等时热备机制能自动重启服务②当部署进程的机器出现故障断网、停电、硬件损坏时备机能及时接替主机工作③新主上线接管后旧主重新启动能自动成为新主的备机保障热备机制的可持续性④出现热备机制无法处理的故障时硬件问题、机房环境问题等能及时通知人工介入。
做好上述四点则代表热备机制较为完善可具体咋做呢这里不过多赘述感兴趣可参考《Keepalived搭建双机热备机制》。 PS除一主一备外也可以选择搭建双主热备这样能最大程度利用资源避免备机长时间处于空闲状态。
