一種多策略協(xié)同的小水電并發(fā)訪問控制方法

周彬彬，馬瑋駿，趙興圓，李勝，殷峻暹，陳志剛，柯愈晴

（1.云南電力調(diào)度控制中心，云南昆明 650011；2.南京金水尚陽信息技術有限公司，江蘇南京 210046；3.深圳航天智慧城市系統(tǒng)技術研究院有限公司，廣東深圳 518057；4.中國水利水電科學研究院，北京 100038）

0 引言

云南電網(wǎng)公司，由于地域和氣候特點，接入和消納2 000 余個裝機容量不足25 MW 的小型發(fā)電站的電量，其中小水電站占比達80%以上，這些發(fā)電站對全省電力精細化統(tǒng)調(diào)統(tǒng)管具有重要影響。電網(wǎng)調(diào)度管理需要及時掌握所轄電站的發(fā)電生產(chǎn)情況，并對各類電站進行高效的監(jiān)控和調(diào)配，確保供需平衡和電網(wǎng)安全穩(wěn)定。然而由于數(shù)千用戶同時使用系統(tǒng)，在規(guī)定時間范圍內(nèi)對各個電站實際運行數(shù)據(jù)進行統(tǒng)計、計劃填報，在數(shù)據(jù)集中填報和計劃編制協(xié)調(diào)高峰時期，大規(guī)模用戶的集中操作、高并發(fā)訪問使得系統(tǒng)響應極其緩慢，嚴重影響各級調(diào)度機構的工作效率。特別是眾多小水電站地處偏僻，通信條件差，及時上報發(fā)電數(shù)據(jù)和獲得調(diào)度指令成為瓶頸，省級電網(wǎng)公司能夠最大程度減少各類電站實時上報數(shù)據(jù)的延時，并將調(diào)度指令及時送達電站，對于提高整個區(qū)域的發(fā)電調(diào)度效率至關重要，急需解決多用戶并發(fā)訪問的高效控制和數(shù)據(jù)庫后臺服務的動態(tài)優(yōu)化問題。

在提高網(wǎng)絡服務器的多用戶并發(fā)訪問效率方面，盡管已有大量研究成果，但并不都能滿足具體應用場景下的特殊需求，特別是大多數(shù)解決方案都是針對一種訪問方式。例如，對于系統(tǒng)調(diào)用方面的網(wǎng)絡服務多用戶并發(fā)設計，通常采取多線程的方式實現(xiàn)，但由于系統(tǒng)能支持的線程數(shù)量有限，當并發(fā)數(shù)超過允許的線程數(shù)量時，還是無法應對所有的服務請求。有學者提出了一種基于Linux系統(tǒng)epoll調(diào)用和任務隊列機制的軟件優(yōu)化方法，能根據(jù)優(yōu)先級高低，對不同等級的服務請求進行區(qū)分處理，緩解了這類服務程序調(diào)用類的多用戶并發(fā)請求［1］。還有針對云平臺非關系型分布式數(shù)據(jù)庫的并發(fā)訪問，結合特定第三方數(shù)據(jù)庫管理系統(tǒng)（DBMS）的索引機制，如HBase，改進R 樹索引，提高分布式讀寫索引的吞吐量［2］。本文的多用戶并發(fā)訪問是針對桌面Web、手機APP 和短信平臺終端等多種訪問方式，訪問頻度呈潮汐式周期變化的特點，而且主要操作是對關系型集中式數(shù)據(jù)庫的讀寫操作，除了充分利用DBMS提供的優(yōu)化工具外，還要綜合運用分布式控制和負載均衡技術［3］。

本文以云南電網(wǎng)公司的電網(wǎng)調(diào)度管理系統(tǒng)優(yōu)化改進為應用背景，深入分析業(yè)務特點，根據(jù)系統(tǒng)升級的約束要求，在國產(chǎn)達夢數(shù)據(jù)庫支持的基本數(shù)據(jù)存儲與訪問技術框架下，采用主從式負載均衡技術，設計了業(yè)務驅(qū)動的電網(wǎng)數(shù)據(jù)訪問控制策略，有效分離讀寫操作，并實現(xiàn)了相關控制軟件。不僅徹底解決了數(shù)千計用戶集中報數(shù)時的網(wǎng)頁卡死問題，還將同時訪問的響應時間從原來的最長30 s，穩(wěn)定在5 s 以內(nèi)，大大地改善了用戶體驗，提高了系統(tǒng)的運行效率。

1 業(yè)務特點與系統(tǒng)架構

1.1 云南電網(wǎng)調(diào)度管理系統(tǒng)的業(yè)務特點

云南電網(wǎng)業(yè)務涉及的發(fā)電廠，全口徑數(shù)量為2 260 個左右。其中納入省調(diào)電力電量平衡的電廠有438 個左右，包括10 個左右總調(diào)直調(diào)、100 個左右省調(diào)直調(diào)和328 個左右省地共調(diào)的電廠，站點的歸屬在不同時期會根據(jù)需要調(diào)整，水電個數(shù)占43.15%左右，裝機容量占69.2%左右；其余1 830 多個地調(diào)以下的電廠屬于小電，98%以上是水電。隨著新能源技術的發(fā)展，風電和光電屬于優(yōu)先消納的可再生能源，由于其出力的隨機性和間隙性成為發(fā)電優(yōu)化調(diào)度的難點和重點，作為補償調(diào)節(jié)的發(fā)電能力也從火電逐漸向水電轉移［4］。因此對各類上報數(shù)據(jù)的時效性、一致性和正確性提出了更高的要求。

云南電網(wǎng)已建系統(tǒng)數(shù)據(jù)庫中累積了30多年的數(shù)據(jù)，按照靜態(tài)和動態(tài)特征可以劃分為兩大類。靜態(tài)數(shù)據(jù)主要指電站基本信息，包含電站共性基礎信息（如電站名稱、所屬供電局、電站類型、調(diào)度關系、裝機容量、并網(wǎng)電壓等級、機組臺數(shù)、經(jīng)緯度等），水電站的流域及其邊界信息、水庫信息、大壩信息、閘門信息等。這部分數(shù)據(jù)改動頻度不高，可以采用按需批量備份/更新到本地的辦法解決在線訪問擁塞問題。

動態(tài)數(shù)據(jù)是指電站的運行狀態(tài)信息，主要包含與電站運行狀態(tài)相關的數(shù)據(jù)信息，這些數(shù)據(jù)信息可劃分為供給側數(shù)據(jù)、需求側數(shù)據(jù)、實現(xiàn)供需平衡的調(diào)度數(shù)據(jù)以及與電站相關聯(lián)的動態(tài)數(shù)據(jù)，會根據(jù)監(jiān)測和上報的時間情況定期修改舊有數(shù)據(jù)或增加新的數(shù)據(jù)。其中供給側數(shù)據(jù)主要由與各種不同電站相關的電量信息（包含實時數(shù)據(jù)和歷史數(shù)據(jù)，如發(fā)電容量、發(fā)電機臺數(shù)、運行功率等）、電量計劃信息（包含短期、中長期發(fā)電量預測與計劃數(shù)據(jù)等）、工況信息（包含實時數(shù)據(jù)和歷史數(shù)據(jù)，如運行狀態(tài)、設備溫度、設備濕度、電壓、電流、工況告警等），工況告警信息（如告警設備編號、告警事件、告警內(nèi)容、嚴重程度等），需求側數(shù)據(jù)主要為用戶相關的用電信息（如用電量、電費等）、用電預測信息（包含短期、中長期用電量預測數(shù)據(jù)等），關聯(lián)數(shù)據(jù)主要包含與電站緊密相關的氣象數(shù)據(jù)。

由此可見，對于電網(wǎng)調(diào)度管理系統(tǒng)優(yōu)化改進主要方向在于動態(tài)數(shù)據(jù)的存儲訪問控制機制，而瓶頸又在于與小電業(yè)務相關的用戶群，因為小電站地處偏僻、通信條件差（無專線），上報和查詢基本依賴手機APP，集中上線時，很容易造成網(wǎng)頁服務卡死，無法報數(shù)。為此，數(shù)據(jù)上報提供網(wǎng)頁填報和短信上報兩種方式，一旦網(wǎng)頁填報失敗，可采用短信方式補報；電網(wǎng)側通過專門的短信平臺接收短報文并進行解析后處理，完成二次入庫操作。

每天早晨8點到9點集中上線的用戶約2 500人，按數(shù)據(jù)庫表記錄計，上報的時段數(shù)據(jù)約144 000條，日運行數(shù)據(jù)約12 000，日計劃數(shù)據(jù)約12 000 條；電廠上報和地調(diào)下發(fā)96 點發(fā)電計劃4 000 條。該時段單站點數(shù)據(jù)庫的讀寫數(shù)據(jù)量約為400 MB。

1.2 系統(tǒng)總體架構

對大型系統(tǒng)的數(shù)據(jù)訪問與存儲的優(yōu)化需要結合系統(tǒng)的實際業(yè)務需求，有針對性的提出系統(tǒng)總體設計方案。對于投資成本有限、數(shù)據(jù)上報時效嚴格、安全要求高的業(yè)務系統(tǒng)來說，必須綜合考慮性價比高的技術。為此，采取主從式數(shù)據(jù)庫服務器+雙Nginx（一款web 服務器）的負載均衡集群架構［5，6］，以實現(xiàn)整個系統(tǒng)的高可用性目標。整個系統(tǒng)的總體架構如圖1所示。

在內(nèi)網(wǎng)中，整個系統(tǒng)架構主要通過Web 集群的方式來實現(xiàn)，其核心在于采用基于雙Nginx 的高可用及負載均衡集群部署方式來提高系統(tǒng)的性能和可用性。Nginx 是一種高性能的HTTP 和反向代理web 服務器技術，借助Keepalived（Linux 下的輕量級別的高可用解決方案），實現(xiàn)任務分配策略［7］。圖1 的Web服務器A和B中安裝了Keepalived，避免由負載均衡服務器硬件故障造成的單點故障。系統(tǒng)的Web 應用服務同時在A、B、C 三臺Web 服務器上，所有用戶對系統(tǒng)的數(shù)據(jù)連接和訪問都通過Nginx 負載均衡服務器來指派給各個Web 應用服務器，在經(jīng)過了流量的合理分配消除服務器之間負載的不平衡后，系統(tǒng)訪問請求在服務器集群之間得到了性能優(yōu)化，提高了系統(tǒng)的反應速度以及系統(tǒng)的可靠性。系統(tǒng)工作原理如圖2所示。

圖1 主從式數(shù)據(jù)庫服務器+雙Nginx的負載均衡集群架構Fig.1 Load balancing cluster framework based on master-slave DB Server+double Nginx

圖2 系統(tǒng)工作原理Fig.2 System work principle

2 讀寫分離的數(shù)據(jù)訪問實現(xiàn)

2.1 與數(shù)據(jù)庫分級適配的讀寫分離策略

電力系統(tǒng)業(yè)務數(shù)據(jù)具有數(shù)據(jù)類型多樣、結構較為復雜等特點，導致單次數(shù)據(jù)訪問量差異大，如96 點發(fā)電計劃一條記錄包含100 多個字段，讀寫一次約數(shù)十MB，而日運行數(shù)據(jù)的一條記錄字段數(shù)則相對較少，一次訪問只有數(shù)MB。此外，業(yè)務要求每天上午8 點-9 點必須完成數(shù)據(jù)上報和發(fā)電計劃下達（一般情況先上報再查詢），存在多點并發(fā)存取現(xiàn)象，可采取將讀寫操作映射到不同數(shù)據(jù)庫服務器上的辦法分而治之。

為了進一步提高數(shù)據(jù)的更新和查詢效率，采用主從數(shù)據(jù)庫的方式對不同層級的數(shù)據(jù)進行存儲［8-10］，其中第一層級和第二層級的數(shù)據(jù)由于訪問頻繁，存放在主庫中，并且使用外鍵等約束措施保證數(shù)據(jù)的邏輯關系，維護數(shù)據(jù)完整性，第三層級和第四層級的數(shù)據(jù)由于數(shù)據(jù)量大，訪問頻度不高，與主庫數(shù)據(jù)相關性小，部署在獨立的數(shù)據(jù)庫服務器中，從而緩解主庫的數(shù)據(jù)處理壓力。具體分級如圖3所示。

圖3 系統(tǒng)工作原理Fig.3 System work principle

Web 程序采用Spring（一種開放源代碼的J2EE 應用程序框架），在進入Web Service 之前，使用AOP（Aspect Oriented Programming：面向切面的編程）來做出判斷，對數(shù)據(jù)庫的訪問是寫庫還是讀庫，進而可以對讀/寫操作進行分離，緩解數(shù)據(jù)庫服務器的壓力［11，12］。

使用AOP 來做出判斷，依據(jù)對數(shù)據(jù)庫操作的方法名判斷，比如說以query、find、get等開頭的讀庫，指示到從數(shù)據(jù)庫所在的服務器上；其他的操作指示到主數(shù)據(jù)庫服務器上。

利用數(shù)據(jù)庫提供的主從數(shù)據(jù)庫自動同步數(shù)據(jù)的服務。配置好數(shù)據(jù)同步服務后，當主數(shù)據(jù)庫有數(shù)據(jù)變動時，從數(shù)據(jù)庫自動同步主數(shù)據(jù)庫的數(shù)據(jù)。讀寫分離機制如圖4所示。

通常，可根據(jù)對數(shù)據(jù)庫的并發(fā)訪問量和系統(tǒng)對數(shù)據(jù)庫的訪問方式，設置讀寫全分離還是部分分離。圖4 中對于不經(jīng)過AOP 處理的非直接Web 訪問方式，可不采用讀寫分離，如通過短信方式訪問中心數(shù)據(jù)庫的情況。

圖4 讀寫分離機制Fig.4 Separated read and write

2.2 系統(tǒng)數(shù)據(jù)同步控制機制

當進行讀寫分離操作時，可能發(fā)生短暫的讀取數(shù)據(jù)不是最新寫入的情況，需要設置有效的數(shù)據(jù)同步控制機制。

首先，制定數(shù)據(jù)庫設計和訪問控制約束條件：

（1）數(shù)據(jù)庫之間不進行實時的數(shù)據(jù)交換，只在數(shù)據(jù)量達到一定規(guī)?；蛘叨〞r器超時后，進行批量、定時的數(shù)據(jù)交換。

（2）數(shù)據(jù)庫之間不建立外鍵等完整性約束，從而減少約束檢查所帶來的訪問開銷。

（3）對非關鍵業(yè)務數(shù)據(jù)庫的讀/寫操作分散到不同的節(jié)點上，從而隔離寫操作對讀操作的影響。

然后，采用觸發(fā)器方式來實現(xiàn)主從數(shù)據(jù)庫間的同步更新，確保不同庫之間的數(shù)據(jù)一致性，其處理流程如圖5所示。

在圖5 所顯示的處理流程中，所有表的數(shù)據(jù)都先由處理程序?qū)懭氲骄彺姹碇?，隨后緩存表中的觸發(fā)器根據(jù)寫入的數(shù)據(jù)對實時庫或者歷史庫中相應的庫表數(shù)據(jù)進行更新。對于日以上的數(shù)據(jù)，還需要同時對多個歷史表進行修改。

圖5 基于觸發(fā)器的數(shù)據(jù)同步流程Fig.5 Trigger-based data synchronization process

這種方式的優(yōu)點是處理程序較為簡單，具有較高的可維護性，且單表鎖表的時間較短，數(shù)據(jù)庫出現(xiàn)沖突的可能性較小，滿足業(yè)務應用對數(shù)據(jù)庫讀寫的需求。

3 改進的負載均衡任務分配算法

在一定訪問權限和優(yōu)先級的控制下，對于發(fā)電計劃的修訂和執(zhí)行情況應優(yōu)先保證數(shù)千個電站的數(shù)據(jù)訪問延遲間隔最小。雖然將讀寫操作分別映射到不同數(shù)據(jù)庫服務器上，但對于通過Web 服務器訪問系統(tǒng)的應用，還需在Web 應用服務器集群首次接納任務時，均衡負載，提高整體工作效率。

3.1 常用的負載均衡策

目前Nginx主要支持以下6種負載均衡6種策略：

（1）輪詢Polling。將服務請求按照順序輪流地分配到各個服務器上，適合用于服務器硬件條件基本相同和任務量本身較一致的情況，不能感知服務器運行狀態(tài)，例如新增或者某個服務器宕機。

（2）權重方式Weight。該方法是在輪詢的基礎上加一個權重，權重高的服務器處理的請求就多。可以根據(jù)情況進行調(diào)整，但仍然需要進行session（計算機術語，會話控制）同步。

（3）IP 分配方式IP_hash。無需進行session 同步，固定IP 會固定訪問一臺服務器。提供的服務不同，面向的地區(qū)不同，IP可能會出現(xiàn)集中，造成不均勻，不可控，尤其在惡意攻擊情況下，會造成某臺服務器崩潰。

（4）響應時間方式Fair。會根據(jù)服務器處理請求的速度進行負載均衡分配，最早結束的任務，拿到下一個請求，具有一定的自適應能力，也需要進行session同步。

（5）URL 分配方式URL_hash。根據(jù)URL 進行hash，某些請求永遠分配到某臺Web 服務器，有利于利用服務器的緩存，但是可能由于URL 的哈希值分布不均勻，以及業(yè)務側重造成某些服務器壓力大，某些負荷低，也需要進行session同步。

（6）隨機方式Random。每來一個請求，從后端服務器中隨機地選擇一個服務器處理請求。如果隨機數(shù)是等概率生成的，運行一定時間，就跟輪詢算法沒什么區(qū)別了。

還有其他的一些算法，如加權輪詢等，都是針對具體應用特點改進的，適用于特定環(huán)境［13-15］。我們根據(jù)電力系統(tǒng)數(shù)據(jù)和業(yè)務應用特點，提出了一種IP_hash與Fair相結合的負載均衡任務分配算法IPHF，根據(jù)時段內(nèi)D 到達的Web 應用任務特征，在IP_hash基礎上，引入任務時間閾值，作為動態(tài)調(diào)整參考量，必要時執(zhí)行Fair 策略。該方法可以有效發(fā)揮IP_hash 能夠根據(jù)用戶區(qū)域分配服務器的優(yōu)點，滿足常規(guī)情況下簡單易行的服務器負載均衡配置要求，又能發(fā)揮Fair 考慮服務器動態(tài)執(zhí)行任務的特新，克服突發(fā)時期IP_hash 無法應對不均勻任務負載造成的臨時過載問題。

3.2 IPHF負載均衡任務分配算法

本文綜合IP_hash和Fair方式，設計了IPHF算法，將任務分配分為兩個階段：階段1，IP_hash 動態(tài)服務器組分配；階段2，F(xiàn)air動態(tài)服務器組分配。

式中，ID 表示任務唯一標識，如可與站點號關聯(lián)；S?P，表示任務的主要操作子集，P∈{W，R，B，U}，W-寫，R-讀，B-瀏覽，U-其他（如計算、修改等）；Tf表示任務執(zhí)行所需要的大致時間，即任務時間閾值。

為了便于操作，根據(jù)圖3 給出的數(shù)據(jù)層級劃分和系統(tǒng)關于數(shù)據(jù)字典關于數(shù)據(jù)庫表結構的描述，統(tǒng)計分析常用應用服務的所需時間，設定一個任務特征參數(shù)映射表。當有Web 應用服務請求時，先提取HTTP 協(xié)議中的相關信息，查找映射表，生成一個三元組。

在時間段D中，電網(wǎng)管理系統(tǒng)中的客戶端的Web 應用服務請求遵循定義1，記為Task={task1，task2，…，taskm}，其中m為Web應用服務請求的總數(shù)。第i個服務請求taski記為式（1）：

定義2：在Web 服務器集合S={S1，S2，…，Sn}中，第i個服務器Si的當前任務狀態(tài)記為式（2）：

式中：n為Web 服務器的總數(shù)，Ni為服務器Si的當前任務總數(shù)，為服務器Si處理完當前所有任務需要的時間，即服務器剩余執(zhí)行時間。

（1）IPHF階段1：IP_hash動態(tài)服務器組分配算法設計。

用IP_hash 進行靜態(tài)分配，負載均衡器按照客戶端IP 地址組，分配任務到三個Web 服務器之一，使得正常情況下相同的客戶端的請求發(fā)送到相同的服務器，以保證session 會話的一致性?；九渲萌缦拢?/p>

當某個服務器出現(xiàn)長任務過多時，如分配到同一臺服務器的多個站點在時間段D 中同時上報96點發(fā)電計劃，而其他服務器相對空閑時，采用Fair 策略分配處理請求的Web 應用服務器。

任務分配策略切換機制：當客戶端的Web 應用服務請求的響應時間大于用戶最大容忍時間時，即Tf＞，當前客戶端所分配的服務器會反饋告警信息到Nginx 負載均衡管理器Keepalived，使之進入IPHF 階段2；隨即，采用Fair 方式處理所積攢的Web 應用服務，直到在下一個D 時段內(nèi)沒有出現(xiàn)響應時間大于的任務請求，再次切換到IPHF階段1。

（2）IPHF階段2：Fair動態(tài)服務器組分配算法原理。

每個服務器中的當前任務總數(shù)Si和服務器執(zhí)行時間都是已知的。在當前時段D，新接入的任務請求將被分配至最先達到空閑狀態(tài)的服務器Si中，即式（3）：

IPHF負載均衡任務分配算法偽代碼如下。

4 性能評價

用戶的數(shù)據(jù)庫訪問時間，體現(xiàn)在客戶端訪問Web 應用服務器時，從請求任務到響應執(zhí)行完畢的過程（包括應用服務負載均衡分配、讀寫分離數(shù)據(jù)庫服務器劃分和分級分區(qū)數(shù)據(jù)庫表映射）。為了對上述整體優(yōu)化設計進行綜合性能評價，采用基于實際業(yè)務數(shù)據(jù)的算法仿真方式對Web 應用服務的查詢時間和成功完成任務的比率進行對比分析［16-18］。

4.1 數(shù)據(jù)來源與性能評價參數(shù)

模擬數(shù)據(jù)為2019 年7 月至2019 年12 月共6 個月的云南電網(wǎng)運行數(shù)據(jù)，由于系統(tǒng)采用了分庫分區(qū)的優(yōu)化方法，所有運行數(shù)據(jù)按照月份存儲在不同的分區(qū)表中，各個分區(qū)表的記錄數(shù)和占用空間等詳細信息如表1所示。

表1 分區(qū)表模擬數(shù)據(jù)詳情Tab.1 Partition table simulation data details

模擬測試環(huán)境隨機抽取了100 組數(shù)據(jù)，將Web 應用服務請求的平均響應時間t、Web 服務器的負載均衡指數(shù)LI以及任務成功接納率Ps作為算法的評價標準。同時，將IPHF 與單獨運用IP_hash或Fair的負載均衡任務分配算法進行對比。

LI、Ps可分別通過公式（4）、公式（5）進行計算。

式中：n為Web服務器的總數(shù)，Si為Web 服務器所成功接納的服務請求總數(shù)。

本文規(guī)定Web 應用服務請求的響應時間大于任務時間閾值時，即t＞，認為任務接納失敗。

式中：s為任務成功接納的數(shù)量。

仿真過程中客戶端的數(shù)量分別設置為1 000、1 500、2 000、2 500、3 000，客戶端的Web 應用服務請求按照泊松分布到達，請求的任務大小符合正態(tài)分布；Web 服務器數(shù)量設置為3。針對上述三種算法，對相關參數(shù)設置分述如下：

（1）IPHF：客戶端均勻分配至Web服務器，Tf=5 s；

（2）IP_hash：客戶端均勻分配至Web服務器；

（3）Fair：Web 服務器根據(jù)其狀態(tài)（最小剩余任務時間）響應客戶端請求。

4.2 性能分析

Web應用服務請求的平均響應時間仿真結果如圖6所示。

圖6 不同算法下的請求平均響應時間MRTFig.6 MRT under different methods

結果表明，當客戶端的數(shù)量為1 000、1 500時，3 種算法的Web 應用服務請求的平均響應時間保持在5 s 以內(nèi)。隨著客戶端的數(shù)量的增加，IPHF 相比較IP_hash 和Fair有著更好的表現(xiàn)。當客戶端的數(shù)量為3 000時，IPHF 的Web 應用服務請求的平均響應時間為4.88 s；而IP_hashFair 的平均響應時間分別為26.68和15.23 s，其中IP_hash 的平均響應時間最長，F(xiàn)air 表現(xiàn)次之。這是因為這兩種算法下，客戶端的任務請求被指定的Web 服務器所響應，當某個客戶端的請求的任務大小較大時，會導致后續(xù)的客戶端任務請求發(fā)生阻塞，等待Web 服務器處理完前一個客戶端的任務請求。

Web服務器的負載均衡指數(shù)LI仿真結果如圖7所示。

圖7 不同算法下的請求平均響應時間MRTFig.7 MRT under different methods

結果表明，IPHF 的LI分別為在不同客戶端的數(shù)量下保持在26.34。在客戶端數(shù)量為3 000時，IP_hash 和Fair的LI分別為78.62、58.96。同時，IP_hash 和Fair 隨著客戶端數(shù)量的增加，LI呈現(xiàn)著上升后平穩(wěn)的趨勢，這是由于在客戶端數(shù)量較少時，IP_hash 和Fair 都可以及時處理客戶端的服務請求。隨著客戶端數(shù)量的增加，服務請求數(shù)增多，服務器對個別服務請求的響應時間超過Tf，導致請求接納失敗。任務成功接納率Ps仿真結果如圖8所示。

圖8 不同算法下的任務成功接納率指標PsFig.8 Indicator Ps under different methods

同樣地，IPHF表現(xiàn)出的性能最佳，在不同數(shù)量的客戶端下，任務成功接納率Ps均可達到99%。而IP_hash 和Fair 隨著客戶端數(shù)量的增加，任務成功接納率Ps有著明顯的降低。該項指標的提高，將大大減少用戶由于無法正常使用客戶端APP 訪問電網(wǎng)業(yè)務系統(tǒng)的概率，避免盲目嘗試短信等其他方式造成的二次信道擁堵。

5 結論

為了提高對地域分布廣、數(shù)量多的小電站的信息化水平，在硬件和通信條件有限的電網(wǎng)信息管理系統(tǒng)升級改造時，必須考慮如何改善在并發(fā)訪問度較高、數(shù)據(jù)存儲量較大情況下的用戶使用體驗。以云南電網(wǎng)為應用背景，綜合采用讀寫分離的主從式數(shù)據(jù)庫服務器、基于分庫分區(qū)的海量數(shù)據(jù)存取機制、基于雙Nginx 負載均衡服務器的系統(tǒng)架構和改進的任務分配算法，有效提升了系統(tǒng)的可擴展性和快速響應能力。實驗結果表明，系統(tǒng)采取的數(shù)據(jù)訪問控制技術極大降低數(shù)據(jù)的訪問響應時間，提高多應用服務器之間的均衡度和總體任務成功接納率，最大限度地滿足發(fā)電行業(yè)數(shù)據(jù)上報和查詢的業(yè)務需求，為保障復雜多源發(fā)電站的信息系統(tǒng)可用性提供了先進實用的解決方案。