集群通信系统是一种用于集团调度指挥通信的移动通信系统,主要应用在专业移动通信领域。该系统具有的可用信道可为系统的全体用户共用,具有自动选择信道功能,它是共享资源、分担费用、共用信道设备及服务的多用途、高效能的无线调度通信系统。是指一组独立的计算机系统构成的一个松耦合的多处理器系统,它们之间通过网络实现进程间的通信。应用程序可以通过网络共享内存进行消息传送,实现分布式计算机。通俗一点来说,就是让若干台计算机联合起来工作(服务),可以是并行的,也可以是做备份。
集群通信的最大特点是话音通信采用PTT(Push To Talk),以一按即通的方式接续,被叫无需摘机即可接听,且接续速度较快,并能支持群组呼叫等功能,它的运作方式以单工、半双工为主,主要采用信道动态分配方式,并且用户具有不同的优先等级和特殊功能,通信时可以一呼百应。
追溯到它的产生,集群的概念确实是从有线电话通信中的“中继”概念而来。1908年,E.C.Mo1ina发表的“中继”曲线的概念等级,证明了一群用户的若干中继线路的概率可以大大提高中继线的利用率。“集群”这一概念应用于无线电通信系统,把信道视为中继。“集群”的概念,还可从另一角度来认识,即与机电式(纵横制式)交换机类比,把有线的中继视为无线信道,把交换机的标志器视为集群系统的控制器,当中继为全利用度时,就可认为是集群的信道。集群系统控制器能把有限的信道动态地、自动地最佳分配给系统的所有用户,这实际上就是信道全利用度或我们经常使用的术语“信道共用”。
负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
负载均衡其意思就是分摊到多个操作单元上进行执行,例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。
分布式系统(distributed system)是建立在网络之上的软件系统。正是因为软件的特性,所以分布式系统具有高度的内聚性和透明性。因此,网络和分布式系统之间的区别更多的在于高层软件(特别是操作系统),而不是硬件。内聚性是指每一个数据库分布节点高度自治,有本地的数据库管理系统。透明性是指每一个数据库分布节点对用户的应用来说都是透明的,看不出是本地还是远程。在分布式数据库系统中,用户感觉不到数据是分布的,即用户不须知道关系是否分割、有无副本、数据存于哪个
集群是个物理形态,分布式是个工作方式。
只要是一堆机器,就可以叫集群,他们是不是一起协作着干活,这个谁也不知道;一个程序或系统,只要运行在不同的机器上,就可以叫分布式,嗯,C/S架构也可以叫分布式。
集群一般是物理集中、统一管理的,而分布式系统则不强调这一点。
所以,集群可能运行着一个或多个分布式系统,也可能根本没有运行分布式系统;分布式系统可能运行在一个集群上,也可能运行在不属于一个集群的多台(2台也算多台)机器上。
站点以及事务在哪个站点上执行等。你被领导要求完成一份文档的编写工作,我们把它看做是计算机要进行处理的业务。
1、这个文档由多个人分解成多个子文档,每个人完成一部分,最后拼装成完整的文档,这就是集群的工作
2、如果这个文档放在一个机器上,多人同时访问会导致响应速度变慢,这时候网管多放了几台机器,每个机器上都有这个文档,访问者会自动被分配到访问较少的服务器上处理该文档,这就叫负载均衡。
3、如果这个文档编写工作需要编写的不止一份文档,而是多个文档,这时由多个人分别处理其中的一部分(而且每次都是同一人处理同一个部分),这就叫分布式。
这个三种架构都是常见的服务器架构,集群的主要是IT公司在做,可以保障重要数据安全;负载均衡主要是为了分担访问量,避免临时的网络堵塞,主要用于电子商务类型的网站;分布式服务器主要是解决跨区域,多个单个节点达到高速访问的目前,一般是类似CDN的用途的话,会采用分布式服务器。分布式是指将不同的业务分布在不同的地方,集群指的是将几台服务器集中在一起,实现同一业务。在现有网络结构之上,负载均衡提供了一种廉价有效的方法扩展服务器带宽和增加吞吐量,加强网络数据处理能力,提高网络的灵活性和可用性。
多种集群
(1)分布式服务器集群
A) 文件服务器集群
图片、视频、其他下载文件,它们的下载通常是占用网络带宽的罪恶魁首,这些资源一定要独立放在带宽好的文件服务器上,能提供http协议访问地址使用,不至于在下载文件时影响web服务器的cpu运算。
文件服务器最好使用磁盘阵列中心存储,比如阿里云提供的文件云服务器,这样使用简单,使用多大带宽多大存储空间选择就好了。
如果没有中心存储,也可以做文件服务器集群,如下图
说白了就是每个文件服务器都安装一个简单的web api作为文件传输和访问的接口,可以手动分配服务器地址给 web 程序使用,当然也可以做一层简单的负载均衡器供web程序统一接口调用。
需要注意的是:web api 接口上传文件结果一定要返回特定服务器完整的http文件下载地址,这个地址要存入数据库。
文件服务器的数量:文件服务器之间都相对独立,没有数据关联,因此数量的多少主要是看带宽的承载量和硬盘空间的大小,动态扩展服务器后,只需把服务器地址加入 web程序的调用列表即可达到无限扩展容量的机制。
B) Web服务器集群
不管是windows系统,还是linux系统,单台服务器的性能和资源都是有限的,支持的连接并发数都有上限,因此必须采用多服务器集群的方法才能提高连接并发数。连接并发数的容量计算也很容易:
连接并发数= 服务器1并发数+服务器2并发数+……+ 服务器n并发数
当然,我们不能都给每台web服务器分配一个域名地址访问,肯定是同一个域名同一个入口,例如百度后面有成百上千台web服务器,但是我们都是使用 www.baidu.com 一个入口,至于这个入口会自动给我们分配一台web服务器访问,我们不会在意这台web服务器的具体地址是多少,这就是负载均衡器的作用。
但是,web服务器集群并不像文件服务器集群那么简单,因为web服务器的程序使用的数据是共享的,具有一致性和实时性的要求。
如果获取数据时都从数据库读取数据,可以保证数据的一致性,但数据量大时,影响性能而又不能保证实时性,这就是我们后面说到的使用缓存技术解决这个问题。
Web服务器类型:微软的.net iis ,阿帕奇 tomcat 都是出名的轻量级web服务器
C) 数据库服务器集群
通常大型的关系型数据库 oracle,mysql , sqlserver 都已经提供了集群的功能,但是,由于磁盘读写速度的限制,难以胜任高并发实时性的要求,我们建议使用带有集群功能的内存数据库。
Mongodb内存数据库:
Mongodb是一个开源的nosql 内存数据库,基于json格式的文档存储,数据对象通过json的序列化与反序列化传输。在服务器内存足够大时,把所有的数据装载到内存中,便于快速访问;当内存不够大时,把不常使用的数据持久化到磁盘文件;最新版本的mongodb 3.0 已经提供了服务器集群的功能,并且引入了hadoop大数据的mapreduce并行运算模式,这让海量数据全部存储与多台服务器的内存上提供很好的解决方案。
现在服务器内存的硬件价格已经十分低廉,配置128G内存的服务器已经很普遍,但是我们还是建议一台服务器存储数据量不要超过1亿条记录,便于提高并行计算的效率。
在硬件充裕的情况下,mongodb集群建议采用多副节点的集群模式,不仅提高访问性能,也保证了数据安全完整性能。
Gemfire内存数据库
Gemfire是很多年前就已经商业化了的nosql内存数据库,经过了多家大型机构的使用考验,更幸运的是,在2015年4月发布其开源版本Geode,可能在不久的将来得到更广泛的使用。
除了开源nosql内存数据库,国内外的巨头都已经在研究自己的内存数据库,比如oracle, ibm , 阿里等等,nosql内存数据库大有代替关系型数据库的趋势。
朋友们可以去研究每个内存数据库的优劣势,不管使用那种产品,我们无非就是解决两个问题:1、内存数据库保证快速访问;2、服务器集群存储大数据。至于如何搭建环境大家可以查找相关资料。
软件作为转发服务器,比如Nginx,HAProxy,LVS 等等,具体安装部署大家可以搜索相关资料。
整体思路图:
负载均衡在分布式架构中的使用
什么是负载均衡(Load balancing)
在网站创立初期,我们一般都使用单台机器对台提供集中式服务,但随着业务量越来越大,无论性能还是稳定性上都有了更大的挑战。这时候我们就会想到通过扩容的方式来提供更好的服务。我们一般会把多台机器组成一个集群对外提供服务。然而,我们的网站对外提供的访问入口都是一个的,比如www.taobao.com。那么当用户在浏览器输入www.taobao.com的时候如何将用户的请求分发到集群中不同的机器上呢,这就是负载均衡在做的事情。
当前大多数的互联网系统都使用了服务器集群技术,集群即将相同服务部署在多台服务器上构成一个集群整体对外提供服务,这些集群可以是Web应用服务器集群,也可以是数据库服务器集群,还可以是分布式缓存服务器集群等。
在实际应用中,在Web服务器集群之前总会有一台负载均衡服务器,负载均衡设备的任务就是作为Web服务器流量的入口,挑选最合适的一台Web服务器,将客户端的请求转发给它处理,实现客户端到真实服务端的透明转发。最近几年很火的「云计算」以及分布式架构,本质上也是将后端服务器作为计算资源、存储资源,由某台管理服务器封装成一个服务对外提供,客户端不需要关心真正提供服务的是哪台机器,在它看来,就好像它面对的是一台拥有近乎无限能力的服务器,而本质上,真正提供服务的是后端的集群。
软件负载解决的两个核心问题是:选谁、转发,其中最著名的是LVS(Linux Virtual Server)。
一个典型的互联网应用的拓扑结构是这样的:
负载均衡分类
现在我们知道,负载均衡就是一种计算机网络技术,用来在多个计算机(计算机集群)、网络连接、CPU、磁碟驱动器或其它资源中分配负载,以达到最佳化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。那么,这种计算机技术的实现方式有多种。大致可以分为以下几种,其中最常用的是四层和七层负载均衡:
二层负载均衡
负载均衡服务器对外依然提供一个VIP(虚IP),集群中不同的机器采用相同IP地址,但机器的MAC地址不一样。当负载均衡服务器接受到请求之后,通过改写报文的目标MAC地址的方式将请求转发到目标机器实现负载均衡。
三层负载均衡
和二层负载均衡类似,负载均衡服务器对外依然提供一个VIP(虚IP),但集群中不同的机器采用不同的IP地址。当负载均衡服务器接受到请求之后,根据不同的负载均衡算法,通过IP将请求转发至不同的真实服务器。
四层负载均衡
四层负载均衡工作在OSI模型的传输层,由于在传输层,只有TCP/UDP协议,这两种协议中除了包含源IP、目标IP以外,还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后,以后通过修改数据包的地址信息(IP+端口号)将流量转发到应用服务器。
七层负载均衡
七层负载均衡工作在OSI模型的应用层,应用层协议较多,常用http、radius、DNS等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个Web服务器的负载均衡,除了根据IP加端口进行负载外,还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。
图:四层和七层负载均衡
对于一般的应用来说,有了Nginx就够了。Nginx可以用于七层负载均衡。但是对于一些大的网站,一般会采用DNS+四层负载+七层负载的方式进行多层次负载均衡。
常用负载均衡工具
硬件负载均衡性能优越,功能全面,但价格昂贵,一般适合初期或者土豪级公司长期使用。因此软件负载均衡在互联网领域大量使用。常用的软件负载均衡软件有Nginx、LVS、HaProxy等。
Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件。
1、 LVS
LVS(Linux Virtual Server),也就是Linux虚拟服务器,是一个由章文嵩博士发起的自由软件项目。使用LVS技术要达到的目标是:通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能、高可用的服务器群集,它具有良好可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的服务性能。
LVS主要用来做四层负载均衡。
LVS架构
LVS架设的服务器集群系统由三个部分组成:最前端的负载均衡层(Loader Balancer),中间的服务器群组层,用Server Array表示,最底层的数据共享存储层,用Shared Storage表示。在用户看来所有的应用都是透明的,用户只是在使用一个虚拟服务器提供的高性能服务。
LVS的各个层次的详细介绍:
Load Balancer层:位于整个集群系统的最前端,有一台或者多台负载调度器(Director Server)组成,LVS模块就安装在Director Server上,而Director的主要作用类似于一个路由器,它含有完成LVS功能所设定的路由表,通过这些路由表把用户的请求分发给Server Array层的应用服务器(Real Server)上。同时,在Director Server上还要安装对Real Server服务的监控模块Ldirectord,此模块用于监测各个Real Server服务的健康状况。在Real Server不可用时把它从LVS路由表中剔除,恢复时重新加入。
Server Array层:由一组实际运行应用服务的机器组成,Real Server可以是Web服务器、Mail服务器、FTP服务器、DNS服务器、视频服务器中的一个或者多个,每个Real Server之间通过高速的LAN或分布在各地的WAN相连接。在实际的应用中,Director Server也可以同时兼任Real Server的角色。
Shared Storage层:是为所有Real Server提供共享存储空间和内容一致性的存储区域,在物理上一般由磁盘阵列设备组成,为了提供内容的一致性,一般可以通过NFS网络文件系统共享数 据,但NFS在繁忙的业务系统中,性能并不是很好,此时可以采用集群文件系统,例如Red hat的GFS文件系统、Oracle提供的OCFS2文件系统等。
从整个LVS结构可以看出,Director Server是整个LVS的核心,目前用于Director Server的操作系统只能是Linux和FreeBSD,Linux2.6内核不用任何设置就可以支持LVS功能,而FreeBSD作为 Director Server的应用还不是很多,性能也不是很好。对于Real Server,几乎可以是所有的系统平台,Linux、windows、Solaris、AIX、BSD系列都能很好地支持。
2、Nginx
Nginx(发音同engine x)是一个网页服务器,它能反向代理HTTP、HTTPS,、SMTP、POP3、IMAP的协议链接,以及一个负载均衡器和一个HTTP缓存。
Nginx主要用来做七层负载均衡。
并发性能:官方支持每秒5万并发,实际国内一般到每秒2万并发,有优化到每秒10万并发的。具体性能看应用场景。
特点:
模块化设计:良好的扩展性,可以通过模块方式进行功能扩展。
高可靠性:主控进程和worker是同步实现的,一个worker出现问题,会立刻启动另一个worker。
内存消耗低:一万个长连接(keep-alive),仅消耗2.5MB内存。
支持热部署:不用停止服务器,实现更新配置文件,更换日志文件、更新服务器程序版本。
并发能力强:官方数据每秒支持5万并发;
功能丰富:优秀的反向代理功能和灵活的负载均衡策略
Nginx的基本工作模式
一个master进程,生成一个或者多个worker进程。但这里master是使用root身份启动的,因为nginx要工作在80端口。而只有管理员才有权限启动小于低于1023的端口。master主要是负责的作用只是启动worker,加载配置文件,负责系统的平滑升级。其它的工作是交给worker。那当worker被启动之后,也只是负责一些web最简单的工作,而其它的工作都是由worker中调用的模块来实现的。
模块之间是以流水线的方式实现功能的。流水线,指的是一个用户请求,由多个模块组合各自的功能依次实现完成的。比如:第一个模块只负责分析请求首部,第二个模块只负责查找数据,第三个模块只负责压缩数据,依次完成各自工作。来实现整个工作的完成。
它们是如何实现热部署的呢?是这样的,我们前面说master不负责具体的工作,而是调用worker工作,它只是负责读取配置文件,因此当一个模块修改或者配置文件发生变化,是由master进行读取,因此此时不会影响到worker工作。在master进行读取配置文件之后,不会立即把修改的配置文件告知worker。而是让被修改的worker继续使用老的配置文件工作,当worker工作完毕之后,直接当掉这个子进程,更换新的子进程,使用新的规则。
3、HAProxy
HAProxy也是使用较多的一款负载均衡软件。HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理,支持虚拟主机,是免费、快速并且可靠的一种解决方案。特别适用于那些负载特大的web站点。运行模式使得它可以很简单安全的整合到当前的架构中,同时可以保护你的web服务器不被暴露到网络上。
HAProxy是一个使用C语言编写的自由及开放源代码软件,其提供高可用性、负载均衡,以及基于TCP和HTTP的应用程序代理。
Haproxy主要用来做七层负载均衡。
常见负载均衡算法
上面介绍负载均衡技术的时候提到过,负载均衡服务器在决定将请求转发到具体哪台真实服务器时,是通过负载均衡算法来实现的。负载均衡算法可以分为两类:静态负载均衡算法和动态负载均衡算法。
静态负载均衡算法包括:轮询、比率、优先权。
动态负载均衡算法包括:最少连接数、最快响应速度、观察方法、预测法、动态性能分配、动态服务器补充、服务质量、服务类型、规则模式。
轮询(Round Robin):顺序循环将请求一次顺序循环地连接每个服务器。当其中某个服务器发生第二到第7 层的故障,BIG-IP 就把其从顺序循环队列中拿出,不参加下一次的轮询,直到其恢复正常。
以轮询的方式依次请求调度不同的服务器; 实现时,一般为服务器带上权重;这样有两个好处:
针对服务器的性能差异可分配不同的负载;
当需要将某个结点剔除时,只需要将其权重设置为0即可;
优点:实现简单、高效;易水平扩展
缺点:请求到目的结点的不确定,造成其无法适用于有写的场景(缓存,数据库写)
应用场景:数据库或应用服务层中只有读的场景
随机方式:请求随机分布到各个结点;在数据足够大的场景能达到一个均衡分布;
优点:实现简单、易水平扩展
缺点:同Round Robin,无法用于有写的场景
应用场景:数据库负载均衡,也是只有读的场景
哈希方式:根据key来计算需要落在的结点上,可以保证一个同一个键一定落在相同的服务器上;
优点:相同key一定落在同一个结点上,这样就可用于有写有读的缓存场景
缺点:在某个结点故障后,会导致哈希键重新分布,造成命中率大幅度下降
解决:一致性哈希 or 使用keepalived保证任何一个结点的高可用性,故障后会有其它结点顶上来
应用场景:缓存,有读有写
一致性哈希:在服务器一个结点出现故障时,受影响的只有这个结点上的key,最大程度的保证命中率; 如twemproxy中的ketama方案; 生产实现中还可以规划指定子key哈希,从而保证局部相似特征的键能分布在同一个服务器上;
优点:结点故障后命中率下降有限
应用场景:缓存
根据键的范围来负载:根据键的范围来负载,前1亿个键都存放到第一个服务器,1~2亿在第二个结点。
优点:水平扩展容易,存储不够用时,加服务器存放后续新增数据
缺点:负载不均;数据库的分布不均衡;
(数据有冷热区分,一般最近注册的用户更加活跃,这样造成后续的服务器非常繁忙,而前期的结点空闲很多)
适用场景:数据库分片负载均衡
根据键对服务器结点数取模来负载:根据键对服务器结点数取模来负载;比如有4台服务器,key取模为0的落在第一个结点,1落在第二个结点上。
优点:数据冷热分布均衡,数据库结点负载均衡分布;
缺点:水平扩展较难;
适用场景:数据库分片负载均衡
纯动态结点负载均衡:根据CPU、IO、网络的处理能力来决策接下来的请求如何调度。
优点:充分利用服务器的资源,保证个结点上负载处理均衡
缺点:实现起来复杂,真实使用较少
不用主动负载均衡:使用消息队列转为异步模型,将负载均衡的问题消灭;负载均衡是一种推模型,一直向你发数据,那么将所有的用户请求发到消息队列中,所有的下游结点谁空闲,谁上来取数据处理;转为拉模型之后,消除了对下行结点负载的问题。
优点:通过消息队列的缓冲,保护后端系统,请求剧增时不会冲垮后端服务器;水平扩展容易,加入新结点后,直接取queue即可;
缺点:不具有实时性;
应用场景:不需要实时返回的场景;
比如,12036下订单后,立刻返回提示信息:您的订单进去排队了...等处理完毕后,再异步通知;
比率(Ratio):给每个服务器分配一个加权值为比例,根椐这个比例,把用户的请求分配到每个服务器。当其中某个服务器发生第2到第7 层的故障,BIG-IP 就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
优先权(Priority):给所有服务器分组,给每个组定义优先权,BIG-IP 用户的请求,分配给优先级最高的服务器组(在同一组内,采用轮询或比率算法,分配用户的请求);当最高优先级中所有服务器出现故障,BIG-IP 才将请求送给次优先级的服务器组。这种方式,实际为用户提供一种热备份的方式。
最少的连接方式(Least Connection):传递新的连接给那些进行最少连接处理的服务器。当其中某个服务器发生第2到第7 层的故障,BIG-IP 就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
最快模式(Fastest):传递连接给那些响应最快的服务器。当其中某个服务器发生第二到第7 层的故障,BIG-IP 就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
观察模式(Observed):连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第7 层的故障,BIG-IP就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
预测模式(Predictive):BIG-IP利用收集到的服务器当前的性能指标,进行预测分析,选择一台服务器在下一个时间片内,其性能将达到最佳的服务器相应用户的请求。(被BIG-IP 进行检测)
动态性能分配(Dynamic Ratio-APM):BIG-IP 收集到的应用程序和应用服务器的各项性能参数,动态调整流量分配。
动态服务器补充(Dynamic Server Act.):当主服务器群中因故障导致数量减少时,动态地将备份服务器补充至主服务器群。
服务质量(QoS):按不同的优先级对数据流进行分配。
服务类型(ToS): 按不同的服务类型(在Type of Field中标识)负载均衡对数据流进行分配。
规则模式:针对不同的数据流设置导向规则,用户可自行。
负载均衡的几种算法Java实现代码
轮询
加权随机负载均衡算法
随机负载均衡算法
负载均衡 ip_hash算法.