太原网站建设联系方式,免费创建网站教程,网站后台页面,苏州建网站提供单服务器无论如何优化#xff0c;无论采用多好的硬件#xff0c;总会有一个性能天花板#xff0c;当单服务器的性能无法满足业务需求时#xff0c;就需要设计高性能集群来提升系统整体的处理性能。
作者#xff1a;马天池
单服务器无论如何优化#xff0c;无论采用多好…单服务器无论如何优化无论采用多好的硬件总会有一个性能天花板当单服务器的性能无法满足业务需求时就需要设计高性能集群来提升系统整体的处理性能。
作者马天池
单服务器无论如何优化无论采用多好的硬件总会有一个性能天花板当单服务器的性能无法满足业务需求时就需要设计高性能集群来提升系统整体的处理性能。
高性能集群的本质很简单通过增加更多的服务器来提升系统整体的计算能力。由于计算本身存在一个特点同样的输入数据和逻辑无论在哪台服务器上执行都应该得到相同的输出。因此高性能集群设计的复杂度主要体现在任务分配这部分需要设计合理的任务分配策略将计算任务分配到多台服务器上执行。
高性能集群的复杂性主要体现在需要增加一个任务分配器以及为任务选择一个合适的任务分配算法。对于任务分配器现在更流行的通用叫法是“负载均衡器”。但这个名称有一定的误导性会让人潜意识里认为任务分配的目的是要保持各个计算单元的负载达到均衡状态。
而实际上任务分配并不只是考虑计算单元的负载均衡不同的任务分配算法目标是不一样的有的基于负载考虑有的基于性能吞吐量、响应时间考虑有的基于业务考虑。考虑到“负载均衡”已经成为了事实上的标准术语这里我也用“负载均衡”来代替“任务分配”但请你时刻记住负载均衡不只是为了计算单元的负载达到均衡状态。 负载均衡分类
常见的负载均衡系统包括3种DNS负载均衡、硬件负载均衡和软件负载均衡。 DNS负载均衡
DNS是最简单也是最常见的负载均衡方式一般用来实现地理级别的均衡。例如北方的用户访问北京的机房南方的用户访问深圳的机房。DNS负载均衡的本质是DNS解析同一个域名可以返回不同的IP地址。例如同样是www.baidu.com北方用户解析后获取的地址是61.135.165.224这是北京机房的IP南方用户解析后获取的地址是14.215.177.38这是深圳机房的IP。
下面是DNS负载均衡的简单示意图 DNS负载均衡实现简单、成本低但也存在粒度太粗、负载均衡算法少等缺点。仔细分析一下优缺点其优点有
简单、成本低负载均衡工作交给DNS服务器处理无须自己开发或者维护负载均衡设备。就近访问提升访问速度DNS解析时可以根据请求来源IP解析成距离用户最近的服务器地址可以加快访问速度改善性能。
缺点有
更新不及时DNS缓存的时间比较长修改DNS配置后由于缓存的原因还是有很多用户会继续访问修改前的IP这样的访问会失败达不到负载均衡的目的并且也影响用户正常使用业务。扩展性差DNS负载均衡的控制权在域名商那里无法根据业务特点针对其做更多的定制化功能和扩展特性。分配策略比较简单DNS负载均衡支持的算法少不能区分服务器的差异不能根据系统与服务的状态来判断负载也无法感知后端服务器的状态。
针对DNS负载均衡的一些缺点对于时延和故障敏感的业务有一些公司自己实现了HTTP-DNS的功能即使用HTTP协议实现一个私有的DNS系统。这样的方案和通用的DNS优缺点正好相反。 硬件负载均衡
硬件负载均衡是通过单独的硬件设备来实现负载均衡功能这类设备和路由器、交换机类似可以理解为一个用于负载均衡的基础网络设备。
目前业界典型的硬件负载均衡设备有两款F5和A10。这类设备性能强劲、功能强大但价格都不便宜一般只有“土豪”公司才会考虑使用此类设备。普通业务量级的公司一是负担不起二是业务量没那么大用这些设备也是浪费。
硬件负载均衡的优点是
功能强大全面支持各层级的负载均衡支持全面的负载均衡算法支持全局负载均衡。性能强大对比一下软件负载均衡支持到10万级并发已经很厉害了硬件负载均衡可以支持100万以上的并发。稳定性高商用硬件负载均衡经过了良好的严格测试经过大规模使用稳定性高。支持安全防护硬件均衡设备除具备负载均衡功能外还具备防火墙、防DDoS攻击等安全功能。
硬件负载均衡的缺点是
价格昂贵最普通的一台F5就是一台“马6”好一点的就是“Q7”了。扩展能力差硬件设备可以根据业务进行配置但无法进行扩展和定制。软件负载均衡
软件负载均衡通过负载均衡软件来实现负载均衡功能常见的有Nginx和LVS其中Nginx是软件的7层负载均衡LVS是Linux内核的4层负载均衡。4层和7层的区别就在于协议和灵活性Nginx支持HTTP、E-mail协议而LVS是4层负载均衡和协议无关几乎所有应用都可以做例如聊天、数据库等。
软件和硬件的最主要区别就在于性能硬件负载均衡性能远远高于软件负载均衡性能。Ngxin的性能是万级一般的Linux服务器上装一个Nginx大概能到5万/秒LVS的性能是十万级据说可达到80万/秒而F5性能是百万级从200万/秒到800万/秒都有数据来源网络仅供参考如需采用请根据实际业务场景进行性能测试。
当然软件负载均衡的最大优势是便宜一台普通的Linux服务器批发价大概就是1万元左右相比F5的价格那就是自行车和宝马的区别了。
除了使用开源的系统进行负载均衡如果业务比较特殊也可能基于开源系统进行定制例如Nginx插件甚至进行自研。 软件负载均衡的优点
简单无论是部署还是维护都比较简单。便宜只要买个Linux服务器装上软件即可。灵活4层和7层负载均衡可以根据业务进行选择也可以根据业务进行比较方便的扩展例如可以通过Nginx的插件来实现业务的定制化功能。
其实下面的缺点都是和硬件负载均衡相比的并不是说软件负载均衡没法用。
性能一般一个Nginx大约能支撑5万并发。功能没有硬件负载均衡那么强大。一般不具备防火墙和防DDoS攻击等安全功能。负载均衡典型架构
前面我们介绍了3种常见的负载均衡机制DNS负载均衡、硬件负载均衡、软件负载均衡每种方式都有一些优缺点但并不意味着在实际应用中只能基于它们的优缺点进行非此即彼的选择反而是基于它们的优缺点进行组合使用。具体来说组合的基本原则为
DNS负载均衡用于实现地理级别的负载均衡硬件负载均衡用于实现集群级别的负载均衡软件负载均衡用于实现机器级别的负载均衡。
以一个假想的实例来说明一下这种组合方式如下图所示。 整个系统的负载均衡分为三层。
地理级别负载均衡www.xxx.com部署在北京、广州、上海三个机房当用户访问时DNS会根据用户的地理位置来决定返回哪个机房的IP图中返回了广州机房的IP地址这样用户就访问到广州机房了。集群级别负载均衡广州机房的负载均衡用的是F5设备F5收到用户请求后进行集群级别的负载均衡将用户请求发给3个本地集群中的一个我们假设F5将用户请求发给了“广州集群2”。机器级别的负载均衡广州集群2的负载均衡用的是NginxNginx收到用户请求后将用户请求发送给集群里面的某台服务器服务器处理用户的业务请求并返回业务响应。
需要注意的是上图只是一个示例一般在大型业务场景下才会这样用如果业务量没这么大则没有必要严格照搬这套架构。例如一个大学的论坛完全可以不需要DNS负载均衡也不需要F5设备只需要用Nginx作为一个简单的负载均衡就足够了。 负载均衡算法
负载均衡算法数量较多而且可以根据一些业务特性进行定制开发抛开细节上的差异根据算法期望达到的目的大体上可以分为下面几类。
任务平分类负载均衡系统将收到的任务平均分配给服务器进行处理这里的“平均”可以是绝对数量的平均也可以是比例或者权重上的平均。负载均衡类负载均衡系统根据服务器的负载来进行分配这里的负载并不一定是通常意义上我们说的“CPU负载”而是系统当前的压力可以用CPU负载来衡量也可以用连接数、I/O使用率、网卡吞吐量等来衡量系统的压力。性能最优类负载均衡系统根据服务器的响应时间来进行任务分配优先将新任务分配给响应最快的服务器。Hash类负载均衡系统根据任务中的某些关键信息进行Hash运算将相同Hash值的请求分配到同一台服务器上。常见的有源地址Hash、目标地址Hash、session id hash、用户ID Hash等。
接下来介绍一下负载均衡算法以及它们的优缺点。
轮询
负载均衡系统收到请求后按照顺序轮流分配到服务器上。
轮询是最简单的一个策略无须关注服务器本身的状态例如
某个服务器当前因为触发了程序bug进入了死循环导致CPU负载很高负载均衡系统是不感知的还是会继续将请求源源不断地发送给它。集群中有新的机器是32核的老的机器是16核的负载均衡系统也是不关注的新老机器分配的任务数是一样的。
需要注意的是负载均衡系统无须关注“服务器本身状态”这里的关键词是“本身”。也就是说只要服务器在运行运行状态是不关注的。但如果服务器直接宕机了或者服务器和负载均衡系统断连了这时负载均衡系统是能够感知的也需要做出相应的处理。例如将服务器从可分配服务器列表中删除否则就会出现服务器已经宕机了任务还不断地分配给它这明显是不合理的。
总而言之“简单”是轮询算法的优点也是它的缺点。 加权轮询
负载均衡系统根据服务器权重进行任务分配这里的权重一般是根据硬件配置进行静态配置的采用动态的方式计算会更加契合业务但复杂度也会更高。
加权轮询是轮询的一种特殊形式其主要目的就是为了解决不同服务器处理能力有差异的问题。例如集群中有新的机器是32核的老的机器是16核的那么理论上我们可以假设新机器的处理能力是老机器的2倍负载均衡系统就可以按照2:1的比例分配更多的任务给新机器从而充分利用新机器的性能。
加权轮询解决了轮询算法中无法根据服务器的配置差异进行任务分配的问题但同样存在无法根据服务器的状态差异进行任务分配的问题。 负载最低优先
负载均衡系统将任务分配给当前负载最低的服务器这里的负载根据不同的任务类型和业务场景可以用不同的指标来衡量。例如
LVS这种4层网络负载均衡设备可以以“连接数”来判断服务器的状态服务器连接数越大表明服务器压力越大。Nginx这种7层网络负载系统可以以“HTTP请求数”来判断服务器状态Nginx内置的负载均衡算法不支持这种方式需要进行扩展。如果我们自己开发负载均衡系统可以根据业务特点来选择指标衡量系统压力。如果是CPU密集型可以以“CPU负载”来衡量系统压力如果是I/O密集型可以以“I/O负载”来衡量系统压力。
负载最低优先的算法解决了轮询算法中无法感知服务器状态的问题由此带来的代价是复杂度要增加很多。例如
最少连接数优先的算法要求负载均衡系统统计每个服务器当前建立的连接其应用场景仅限于负载均衡接收的任何连接请求都会转发给服务器进行处理否则如果负载均衡系统和服务器之间是固定的连接池方式就不适合采取这种算法。例如LVS可以采取这种算法进行负载均衡而一个通过连接池的方式连接MySQL集群的负载均衡系统就不适合采取这种算法进行负载均衡。CPU负载最低优先的算法要求负载均衡系统以某种方式收集每个服务器的CPU负载而且要确定是以1分钟的负载为标准还是以15分钟的负载为标准不存在1分钟肯定比15分钟要好或者差。不同业务最优的时间间隔是不一样的时间间隔太短容易造成频繁波动时间间隔太长又可能造成峰值来临时响应缓慢。
负载最低优先算法基本上能够比较完美地解决轮询算法的缺点因为采用这种算法后负载均衡系统需要感知服务器当前的运行状态。当然其代价是复杂度大幅上升。通俗来讲轮询可能是5行代码就能实现的算法而负载最低优先算法可能要1000行才能实现甚至需要负载均衡系统和服务器都要开发代码。
负载最低优先算法如果本身没有设计好或者不适合业务的运行特点算法本身就可能成为性能的瓶颈或者引发很多莫名其妙的问题。所以负载最低优先算法虽然效果看起来很美好但实际上真正应用的场景反而没有轮询包括加权轮询那么多。 性能最优类
负载最低优先类算法是站在服务器的角度来进行分配的而性能最优优先类算法则是站在客户端的角度来进行分配的优先将任务分配给处理速度最快的服务器通过这种方式达到最快响应客户端的目的。
和负载最低优先类算法类似性能最优优先类算法本质上也是感知了服务器的状态只是通过响应时间这个外部标准来衡量服务器状态而已。因此性能最优优先类算法存在的问题和负载最低优先类算法类似复杂度都很高主要体现在
负载均衡系统需要收集和分析每个服务器每个任务的响应时间在大量任务处理的场景下这种收集和统计本身也会消耗较多的性能。为了减少这种统计上的消耗可以采取采样的方式来统计即不统计所有任务的响应时间而是抽样统计部分任务的响应时间来估算整体任务的响应时间。采样统计虽然能够减少性能消耗但使得复杂度进一步上升因为要确定合适的采样率采样率太低会导致结果不准确采样率太高会导致性能消耗较大找到合适的采样率也是一件复杂的事情。无论是全部统计还是采样统计都需要选择合适的周期是10秒内性能最优还是1分钟内性能最优还是5分钟内性能最优……没有放之四海而皆准的周期需要根据实际业务进行判断和选择这也是一件比较复杂的事情甚至出现系统上线后需要不断地调优才能达到最优设计。Hash类
负载均衡系统根据任务中的某些关键信息进行Hash运算将相同Hash值的请求分配到同一台服务器上这样做的目的主要是为了满足特定的业务需求。例如
源地址Hash
将来源于同一个源IP地址的任务分配给同一个服务器进行处理适合于存在事务、会话的业务。例如当我们通过浏览器登录网上银行时会生成一个会话信息这个会话是临时的关闭浏览器后就失效。网上银行后台无须持久化会话信息只需要在某台服务器上临时保存这个会话就可以了但需要保证用户在会话存在期间每次都能访问到同一个服务器这种业务场景就可以用源地址Hash来实现。
ID Hash
将某个ID标识的业务分配到同一个服务器中进行处理这里的ID一般是临时性数据的ID如session id。例如上述的网上银行登录的例子用session id hash同样可以实现同一个会话期间用户每次都是访问到同一台服务器的目的。
阅读目录置顶)(长期更新计算机领域知识
阅读目录置顶)(长期更新计算机领域知识
阅读目录置顶)(长期科技领域知识
歌谣带你看java面试题
