輪詢調度演算法
❶ 急求一個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