轮询调度算法

❶ 急求一个c语言程序后天就要用了麻烦各位好心高手帮帮忙。谢谢。

#include<reg51.h>
#define uchar unsigned char
#define uint unsigned int

uint Tcounetr=0;
unsigned long int mm=0;
sbit P1_6=P1^6;
sbit P1_7=P1^7;

uchar code table[]={0xc0,0xF9,0xA4,0xB0,0x99,0x92,0x82,0xF8,0x80,0x90,}; //设置字符代码

delay(uint m) //延时1ms程序
{ uint i,j;
for(i=m;i>0;i--)
for(j=60;j>0;j--);
}

xian_shi() //显示程序
{ uchar ,shi,ge,xiaoshu;
unsigned long int k=14,h=36;
unsigned long int jj;
jj=mm*k*h;
=jj/1000000;
shi=jj%1000000/100000;
ge=jj%100000/10000;
xiaoshu=jj%10000/1000;

P2=0xE0;
P0=table[];
delay(1);
P2=0XF0;

P2=0xD0;
P0=table[shi];
delay(1);
P2=0XF0;

P2=0xB0;
P0=table[ge];
delay(1);
P2=0XF0;

P2=0x70;
P0=table[xiaoshu];
delay(1);
P2=0XF0;
}
timer_init() //定时器计数器初始化函数
{ EA=1;
ET0=1;
ET1=1;
TMOD=0X51;
TH0=0XB1;
TL0=0XE0;
TH1=0;
TL1=0;
TR0=1;
TR1=1;
}
main() //主函数
{
timer_init();
P0=0; //开始数码管不显示
while(1)
{
xian_shi();
delay(2); //数码管刷新时间单位毫秒
}
}
void timer0() interrupt 1 //定时器0中断
{ uchar a;
TR0=0;
TH0=0XB1;
TL0=0XE0;
Tcounetr++;
if(Tcounetr>=50)
{ TR1=0;
Tcounetr=0;
a=TH1;
mm=a*256+TL1;
if(mm>=1984)
if(mm>=3000)
P1_7=0,
P1_6=0;
else
P1_7=0;
else
P1=0XFF;
TH1=0;
TL1=0;
TR1=1;
}
TR0=1;
}
void timer1() interrupt 3 //计数器1中断时出错
{ TR1=0;
TR0=0;
mm=0;
TH0=0XB1;
TL0=0XE0;
TH1=0;
TL1=0;
TR0=1;
TR1=1;

❷ RR的简介

Round-Robin，轮询调度，通信中信道调度的一种策略，该调度策略使用户轮流使用共享资源，不会考虑瞬时信道条件。从相同数量无线资源（相同调度时间段）被分配给每条通信链路的角度讲，轮询调度可以被视为公平调度。然而，从提供相同服务质量给所有通信链路的角度而言，轮询调度是不公平的，此时，必须为带有较差信道条件的通信链路分配更多无线资源（更多时间）。此外，由于轮询调度在调度过程中不考虑瞬时信道条件，因此它将导致较低的整体系统性能，但与最大载干比调度相比，在各通信链路间具有更为均衡的服务质量。
队列调度算法的公平性、分组排队时延等性能是影响路由设备QoS特性的中央因素。队列调度算法可用循环调度（RR，Round Robin）等算法。
传统的轮询算法对不同的分组业务流队列进行同样的无差别的循环调度服务，这样的调度方式对于等长业务流队列是公平的，但是互联网的业务流是由不定长分组流构成的，因此不同的队列就可能具有不同的分组长度，结果分组长度大的业务流队列将可能会比分组长度小的业务流队列接收更多的服务，是队列之间产生不公平的现象；而且，这种算法也无法事先对业务需要的时延保证。

❸ 多台异地服务器如何实现负载均衡

一般用的就用简单的轮询就好了
调度算法
静态方法：仅根据算法本身实现调度；实现起点公平，不管服务器当前处理多少请求，分配的数量一致
动态方法：根据算法及后端RS当前的负载状况实现调度；不管以前分了多少，只看分配的结果是不是公平
静态调度算法(static Sche)（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 Sche)（6种）:
(1)lc (Least-Connection Scheling): 最少连接
说明：最少连接调度算法是把新的连接请求分配到当前连接数最小的服务器，最小连接调度是一种动态调度短算法，它通过服务器当前所活跃的连接数来估计服务器的负载均衡，调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1，当连接中止或超时，其连接数减一，在系统实现时，我们也引入当服务器的权值为0时，表示该服务器不可用而不被调度。此算法忽略了服务器的性能问题，有的服务器性能好，有的服务器性能差，通过加权重来区分性能，所以有了下面算法wlc。
简单算法：active*256+inactive (谁的小，挑谁)
(2)wlc (Weighted Least-Connection Scheling):加权最少连接
加权最小连接调度算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权限，加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。由于服务器的性能不同，我们给性能相对好的服务器，加大权重，即会接收到更多的请求。
简单算法：（active*256+inactive）/weight（谁的小，挑谁）
(3)sed (shortest expected delay scheling):最少期望延迟
说明：不考虑非活动连接，谁的权重大，我们优先选择权重大的服务器来接收请求，但会出现问题，就是权重比较大的服务器会很忙，但权重相对较小的服务器很闲，甚至会接收不到请求，所以便有了下面的算法nq。
基于wlc算法，简单算法：（active+1)*256/weight （谁的小选谁）
(4).nq (Never Queue Scheling): 永不排队
说明：在上面我们说明了，由于某台服务器的权重较小，比较空闲，甚至接收不到请求，而权重大的服务器会很忙，所此算法是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地 址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除， 以降低复制的程度。

❹ 使用RR轮询算法,需要配置哪个文件

需要用辅助的数组存储信息之类的。
RR算法用队列直接模拟是相对很简单的，也很适合在考试时使用，但是其它的调度算法就不一定了，需要用辅助的数组存储信息之类的，符合原理地适时调整。
换进程。该算法中，将一个较小时间单元定义为时间量或时间片。时间片的大小通常为10-100ms。就绪队列作为循环队列。CPU调度程序循环整个就绪队列，为每个进程分配不超过一个时间片的CPU。为了实现RR调度，我们再次将就绪队列视为进程的FIFO队列。新进程添加到就绪队列的尾部。CPU调度程序从就绪队列中选择第一个进程，将定时器设置在一个时间片后中断，最后分派这个进程。接下来，有两种情况可能发生。进程可能只需少于时间片的CPU执行。对于这种情况，进程本身会自动释放CPU。调度程序接着处理就绪队列的下一个进程。否则，如果当前运行进程的CPU执行大于一个时间片，那么定时器会中断，进而中断操作系统。然后，进行上下文切换，再将进程加到就绪队列的尾部，接着CPU调度程序会选择就绪队列内的下一个进程。不过，采用RR策略的平均等待时间通常较长。假设有如下一组进程，它们在时间0到达，其CPU执行以ms计。

❺ 求助：IPVSADM的轮询和加权轮询的区别

1.轮叫调度（Round Robin）(简称rr)调度器通过“轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。2.加权轮叫（Weighted Round Robin）（简称wrr)调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

❻ 软件架构中，负载均衡有哪些调度算法

谢邀！
负载均衡调度算法也叫负载均衡方法有很多种，下面以使用比较广的nginx为例说说软件负载均衡的调度算法：
nginx默认的调度算法，按照时间顺序逐一分配后台服务器
在server后加weigth，weight值越高，后台服务器分配概率越大，下图是说ip为102的后台服务分配概率是ip为101后台服务的两倍
按照访问ip的hash分配，增加ip_hash关键字，同一ip访问相同的后台服务
按照访问url的hash分配，增加url_hash关键字，同一url访问相同的后台服务
按照最少连接数方式分配，增加least_conn关键字，哪个后台服务连接数少就分配哪个
按照最短响应时间分配，增加fair关键字，响应时间短的后台服务优先分配

❼ 怎么优化hadoop任务调度算法

首先介绍了Hadoop平台下作业的分布式运行机制，然后对Hadoop平台自带的4种任务调度器做分析和比较，最后在分析JobTracker类文件的基础上指出了创建自定义任务调度器所需完成的工作。
首先Hadoop集群式基于单服务器的，只有一个服务器节点负责调度整个集群的作业运行，主要的具体工作是切分大数据量的作业，指定哪些Worker节点做Map工作、哪些Worker节点做Rece工作、与Worker节点通信并接受其心跳信号、作为用户的访问入口等等。其次，集群中的每个Worker节点相当于一个器官，运行着主节点所指派的具体作业。这些节点会被分为两种类型，一种是接收分块之后的作业并做映射工作。另一种是负责把前面所做的映射工作按照约定的规则做一个统计。
Task－Tracker通过运行一个简单循环来定期地发送心跳信号（heartbeat）给JobTracker．这个心跳信号会把TaskTracker是否还在存活告知JobTracker，TaskTracker通过信号指明自己是否已经准备
好运行新的任务．一旦TaskTracker已经准备好接受任务，JobTracker就会从作业优先级表中选定一个作业并分配下去．至于到底是执行Map任务还是Rece任务，是由TaskTracker的任务槽所决定的．默认的任务调度器在处理Rece任务之前，会优先填满空闲的Map任务槽．因此，如果TaskTracker满足存在至少一个空闲任务槽时，JobTracker会为它分配Map任务，否则为它选择一个Rece任务．TaskTracker在运行任务的时候，第一步是从共享文件系统中把作业的JAR文件复制过来，从而实现任务文件的本地化．第二步是TaskTracker为任务新建一个本地文件夹并把作业文件解压在此目录中．第三步是由Task－Tracker新建一个TaskRunner实例来运行该任务．
Hadoop平台默认的调度方案就是JobQueueTaskScheler，这是一种按照任务到来的时间先后顺序而执行的调度策略．这种方式比较简单，JobTracker作为主控节点，仅仅是依照作业到来的先后顺序而选择将要执行的作业．当然，这有一定的缺陷，由于Hadoop平台是默认将作业运行在整个集群上的，那么如果一个耗时非常大的作业进入执行期，将会导致其余大量作业长时间得不到运行．这种长时间运行的优先级别并不高的作业带来了严重的作业阻塞，使得整个平台的运行效率处在较低的水平．Hadoop平台对这种FIFO（FirstINAndFirstOut）机制所给出的解决办法是调用SetJobPriority（）方法，通过设置作业的权重级别来做平衡调度．
FairScheler是一种“公平”调度器，它的目标是让每个用户能够公平地共享Hadoop集群计算能力．当只有一个作业运行的时候，它会得到整个集群的资源．随着提交到作业表中作业的增多，Hadoop平台会把集群中空闲出来的时间槽公平分配给每个需要执行的作业．这样即便其中某些作业需要较长时间运行，平台仍然有能力让那些短作业在合理时间内完成［3］．FairScheler支持资源抢占，当一个资源池在一定时段内没有得到公平共享时，它会终止该资源池所获得的过多的资源，同时把这些释放的资源让给那些资源不足的资源池．
Hadoop平台中的CapacityScheler是由Yahoo贡献的，在调度器上，设置了三种粒度的对象：queue，job，task．在该策略下，平台可以有多个作业队列，每个作业队列经提交后，都会获得一定数量的TaskTracker资源．具体调度流程如下．
（1）选择queue，根据资源库的使用情况从小到大排序，直到找到一个合适的job．
（2）选择job，在当前所选定的queue中，按照作业提交的时间先后以及作业的权重优先级别进行排序，选择合适的job．当然，在job选择时还需要考虑所选作业是否超出目前现有的资源上限，以及资源池中的内存是否够该job的task用等因素．
（3）选择task，根据本地节点的资源使用情况来选择合适的task．
虽然Hadoop平台自带了几种调度器，但是上述3种调度方案很难满足公司复杂的应用需求．因此作为平台的个性化使用者，往往需要开发自己的调度器．Hadoop的调度器是在JobTracker中加载和调用的，因此开发一个自定义的调度器就必须搞清楚JobTracker类文件的内部机制．作为Hadoop平台的核心组件，JobTracker监控着整个集群的作业运行情况并对资源进行管理调度．每个Task－Tracker每隔3s通过heartbeat向JobTracker汇报自己管理的机器的一些基本信息，包括内存使用量、内存的剩余量以及空闲的slot数目等等［5］．一
旦JobTracker发现了空闲slot，便会调用调度器中的AssignTask方法为该TaskTracker分配task。

❽ 权重轮询调度算法(Weighted Round-Robin Scheling) [C语言实现]

weight[i+1] = a % weight[i+1];
这句话导致后面的weight为0