1 你要有提供相同应用的多台Web服务器。
2 要有负载均衡的设备（可以是软件也可以是硬件）。
3 要为这个服务分配一个虚拟地址（作为服务访问的统一入口）和若干真实地址（有几台Web服务器需要几个真实地址）。
注：一般建议采用硬件设备，通常需要做负载均衡的应用说明他的负载很大，专用的硬件比较可靠。
具备以上条件后将Web服务器连接到负载均衡设备上，在负载均衡设备上配置虚拟地址和真实地址、配置负载均衡算法，配置负载均衡策略，将负载均衡设备接入网络。
这样，外面的用户只需要访问这个虚拟地址就可以了，负载均衡设备收到请求后会按照负载均衡策略和算法把请求分配到真实地址上，实现负载功能。
以上所说只是负载均衡的一种部署方式，根据实际需要选择单臂、双臂接入网络；根据应用的特点选择健康检查的方式；根据应用选择是否使用回话保持算法等。
具体要看代理的后端服务是否是无状态的服务？
若无状态，即不需要使用会话保持，使用轮询策略即可。
若有状态，即需要会话保持，则需要使用基于源IP地址哈希算法，即同一IP的请求会分发之同一台后端服务器。
负载均衡有硬件设备和开源软件，除IDC机房和大公司可以承受像F5这样的昂贵物理设备，而物理设备也需要双机实现HA。
开源软件nginxhaproxylvs等配合keepalived使用也是很好的选择。
根据使用的设备或软件结合业务选择合适的调度策略即可。
这个问题有点搞笑！！！
用户多，不代表你服务器访问量大，访问量大不一定你服务器压力大！我们换成专业点的问题，高并发下怎么优化能避免服务器压力过大？
1，整个架构:可采用分布式架构，利用微服务架构拆分服务部署在不同的服务节点，避免单节点宕机引起的服务不可用！
2，数据库:采用主从复制，读写分离，甚至是分库分表，表数据根据查询方式的不同采用不同的索引比如btree，hash，关键字段加索引，sql避免复合函数，避免组合排序等，避免使用非索引字段作为条件分组，排序等！减少交互次数，一定不要用select！
3，加缓存:使用诸如memcache，redis，ehcache等缓存数据库定义表，结果表等等，数据库的中间数据放缓存，避免多次访问修改表数据！登录信息session等放缓存实现共享！诸如商品分类，省市区，年龄分类等不常改变的数据，放缓存，不要放数据库！
同时要避免缓存雪崩和穿透等问题的出现导致缓存崩溃！
4，增量统计:不要实时统计大量的数据，应该采用晚间定时任务统计，增量统计等方式提前进行统计，避免实时统计的内存，CPU压力！
5，加服务器:等大文件，一定要单独经过文件服务器，避免IO速度对动态数据的影响！保证系统不会因为文件而崩溃！
6，HTML文件，枚举，静态的方法返回值等静态化处理，放入缓存！
7，负载均衡:使用nginx等对访问量过大的服务采用负载均衡，实现服务集群，提高服务的最大并发数，防止压力过大导致单个服务的崩溃！
8，加入搜索引擎:对于sql中常出现的like，in等语句，使用lucence或者solr中间件，将必要的，依赖模糊搜索的字段和数据使用搜索引擎进行存储，提升搜索速度！#注意:全量数据和增量数据进行定时任务更新！
9，使用消息中间件:对服务之间的数据传输，使用诸如rabbitmq，kafka等等分布式消息队列异步传输，防止同步传输数据的阻塞和数据丢失！
10，抛弃tomcat:做web开发，接触最早的应用服务器就是tomcat了，但是tomcat的单个最大并发量只能不到1w！采取netty等actor模型的高性能应用服务器！
11，多线程:现在的服务器都是多核心处理模式，如果代码采用单线程，同步方式处理，极大的浪费了CPU使用效率和执行时间！
12，避免阻塞:避免bio，blockingqueue等常常引起长久阻塞的技术，而改为nio等异步处理机制！
13，CDN加速:如果访问量实在过大，可根据请求来源采用CDN分流技术，避免大流量完成系统崩溃！
14，避免低效代码:不要频繁创建对象，引用，少用同步锁，不要创建大量线程，不要多层for循环！
还有更多的细节优化技术，暂时想不起来了！
一般用的就用简单的轮询就好了调度算法
静态方法：仅根据算法本身实现调度；实现起点公平，不管服务器当前处理多少请求，分配的数量一致
动态方法：根据算法及后端RS当前的负载状况实现调度；不管以前分了多少，只看分配的结果是不是公平
静态调度算法(static Schedu)（4种）:
(1)rr (Round Robin) :轮叫,轮询
说明：轮询调度算法的原理是每一次把来自用户的请求轮流分配给内部中的服务器，从1开始，直到N(内部服务器个数)，然后重新开始循环。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。缺点：是不考虑每台服务器的处理能力。
(2)wrr (Weight Round Robin) :加权轮询(以权重之间的比例实现在各主机之间进行调度)
说明：由于每台服务器的配置、安装的业务应用等不同，其处理能力会不一样。所以，我们根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。
(3)sh (Source Hashing) : 源地址hash实现会话绑定sessionaffinity
说明：简单的说就是有将同一客户端的请求发给同一个real server,源地址散列调度算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的并且没有超负荷，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法的相同。它的算法流程与目标地址散列调度算法的基本相似，除了将请求的目标IP地址换成请求的源IP地址。
(4)dh : (Destination Hashing) : 目标地址hash
说明：将同样的请求发送给同一个server,一般用于缓存服务器，简单的说，LB集群后面又加了一层，在LB与realserver之间加了一层缓存服务器，当一个客户端请求一个页面时,LB发给cache1,当第二个客户端请求同样的页面时，LB还是发给cache1,这就是我们所说的，将同样的请求发给同一个server,来提高缓存的命中率。目标地址散列调度算法也是针对目标IP地址的负载均衡，它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
动态调度算法(dynamic Schedu)（6种）:
(1)lc (Least-Connection Scheduling): 最少连接
说明：最少连接调度算法是把新的连接请求分配到当前连接数最小的服务器，最小连接调度是一种动态调度短算法，它通过服务器当前所活跃的连接数来估计服务器的负载均衡，调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1，当连接中止或超时，其连接数减一，在系统实现时，我们也引入当服务器的权值为0时，表示该服务器不可用而不被调度。此算法忽略了服务器的性能问题，有的服务器性能好，有的服务器性能差，通过加权重来区分性能，所以有了下面算法wlc。
简单算法：active256+inactive (谁的小，挑谁)
(2)wlc (Weighted Least-Connection Scheduling):加权最少连接
加权最小连接调度算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权限，加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。由于服务器的性能不同，我们给性能相对好的服务器，加大权重，即会接收到更多的请求。
简单算法：（active256+inactive）/weight（谁的小，挑谁）
(3)sed (shortest expected delay scheduling):最少期望延迟
说明：不考虑非活动连接，谁的权重大，我们优先选择权重大的服务器来接收请求，但会出现问题，就是权重比较大的服务器会很忙，但权重相对较小的服务器很闲，甚至会接收不到请求，所以便有了下面的算法nq。
基于wlc算法，简单算法：（active+1)256/weight （谁的小选谁）
(4)nq (Never Queue Scheduling): 永不排队
说明：在上面我们说明了，由于某台服务器的权重较小，比较空闲，甚至接收不到请求，而权重大的服务器会很忙，所此算法是sed改进，就是说不管你的权重多大都会被分配到请求。简单说，无需队列，如果有台real server的连接数为0就直接分配过去，不需要在进行sed运算。
(5)LBLC(Locality-Based Least Connections) :基于局部性的最少连接
说明：基于局部性的最少连接算法是针对请求报文的目标IP地址的负载均衡调度，主要用于Cache集群系统，因为Cache集群中客户请求报文的目标IP地址是变化的，这里假设任何后端服务器都可以处理任何请求，算法的设计目标在服务器的负载基本平衡的情况下，将相同的目标IP地址的请求调度到同一个台服务器，来提高服务器的访问局部性和主存Cache命中率，从而调整整个集群系统的处理能力。
(6)LBLCR(Locality-Based Least Connections with Replication) :基于局部性的带复制功能的最少连接
说明：基于局部性的带复制功能的最少连接调度算法也是针对目标IP地址的负载均衡，该算法根据请求的目标IP地址找出该目标IP地 址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除， 以降低复制的程度。服务器负载均衡
像其他任何Web服务器一样，你可以对Citrix StoreFront、DDC和VMware连接服务器进行负载均衡。下面是实现这种工作负载的一些方式：
DNS轮转：这是一种简单的方式，可以通过在DNS服务器上为StoreFront或连接服务器设定多个名称或者“A”记录的方式实现。比如，用于轮转的DNS列表可以是这样的：STOREFRONT 192168010, STOREFRONT 192168011，等等。DNS服务器使用下一个可用IP地址来解析对于服务器名的后续请求。
这种方式的优点是十分简单、可用性高和开销低(没有开销)。但是缺点是，这并不是真正的负载均衡;只是简单的给出了下一个可用的服务器IP地址。这种方式没有使用先进的负载均衡器(LBs)进行查询和更为先进的关键性能因素。专用的负载均衡服务器可以根据目标服务器的CPU、网络使用率、磁盘输入/输出情况和服务可用性来平衡负载。对于一个出现关键服务离线或者崩溃的服务器来说，将其加入到负载均衡当中没有什么意义。
微软网络负载均衡服务(NLB)。NLB需要使用Windows服务器授权。可以在连接服务器或者StoreFront服务器本地运行NLB，并加入到集群当中，产生一个逻辑名称和IP地址。NLB根据网络流量负载情况来判断主机的繁忙程度，这样可以提供更为有意义的负载均衡。其可以智能地判断出如果集群中的某个主机不可用，那么就不会将负载转发到这个主机上。这个测试不包括集群中的服务器是活动的，但是StoreFront或连接服务没有正常工作的情况。
专用负载均衡器。 Citrix NetScaler、F5 Big IP Local Traffic Manager、Kemp Technologies LoadMaster和Radware 的Alteon工具都可以为XenDesktop和Horizon View提供专用的负载均衡功能。这些负载均衡器可能是物理硬件或者虚拟设备，相比于DNS轮转和NLB方式，它们有很多优势。
专用的负载均衡器可以在VDI实施过程中识别更多因素。它会持续评估目标服务器的健康程度，包括像内存和CPU使用率这样的性能指标。负载均衡器可以对服务器进行评估和常规测试，以判断服务器是否工作正常。如果在健康检查时发现问题，其可以将服务器从用户的可用列表中删除，实现宕机时间的透明化。
负载均衡只是这些产品诸多特性中的一个。负载均衡服务器提供的内容缓存、压缩、优先级和其他网络流量优化可以通过降低VDI服务器自身负载来改善性能表现。
随着网站、应用访问量的增加，一台服务器已经不能满足应用的需求，而需要多台服务器集群，这时就会用到负载均衡
它的好处
负载均衡优化了访问请求在服务器组之间的分配，消除了服务器之间的负载不平衡，从而提高了系统的反应速度与总体性能；
负载均衡可以对服务器的运行状况进行监控，及时发现运行异常的服务器，并将访问请求转移到其它可以正常工作的服务器上，从而提高服务器组的可靠性采用了负均衡器器以后，可以根据业务量的发展情况灵活增加服务器，系统的扩展能力得到提高，同时简化了管理。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）