馬 克 王加陽

(中南大學(xué)計算機學(xué)院 湖南 長沙 410083)

0 引 言

隨著電網(wǎng)運營模式的智能化,逐步實現(xiàn)“智能電網(wǎng)”工程目標[1]及“互聯(lián)網(wǎng)+智慧能源”新型思路在電力供給側(cè)的重點推進[2],未來可能將有更多的電力設(shè)備投入到電網(wǎng)系統(tǒng)中。據(jù)統(tǒng)計,截至2017年底,城鄉(xiāng)居民中智能電表的覆蓋率已達99.03%,累計采集用戶約4.47億,新裝智能電表3 748.7萬只。

新形勢下,必將導(dǎo)致電力數(shù)據(jù)的爆發(fā)性增長,電力系統(tǒng)中的電力數(shù)據(jù)覆蓋設(shè)備檢測、電力營銷、電網(wǎng)運行等多個領(lǐng)域,隨著數(shù)據(jù)增長及業(yè)務(wù)的擴展,各領(lǐng)域下電力數(shù)據(jù)的存儲效率及響應(yīng)能力,將成為整個電力系統(tǒng)運行中至關(guān)重要的一環(huán)。傳統(tǒng)電力系統(tǒng)主要存在以下三種數(shù)據(jù)存儲模型。

(1) 關(guān)系型數(shù)據(jù)庫存儲模型。多采用小微型主機作為存儲設(shè)備,電力數(shù)據(jù)全部存放于關(guān)系型數(shù)據(jù)庫中,如Oracle、SQLServer等。該模型部署簡易,運維便捷,在初期,受到諸多電力企業(yè)青睞。但是,隨著數(shù)據(jù)量的增長,格式單一、擴容性差、響應(yīng)緩慢等問題逐漸暴露。

(2) 單一式非關(guān)系型數(shù)據(jù)庫與關(guān)系型數(shù)據(jù)庫混合存儲模型。引入非關(guān)系型數(shù)據(jù)庫,如Redis、MongoDB等,集中管理部分熱點數(shù)據(jù)并對其進行緩存處理,另一部分非熱點數(shù)據(jù)仍然存放于關(guān)系型數(shù)據(jù)庫中。該模型消除了關(guān)系型數(shù)據(jù)中的數(shù)據(jù)格式單一、響應(yīng)緩慢等問題。然而,單節(jié)點服務(wù)器提供的緩存服務(wù)在內(nèi)存容量、可用性、穩(wěn)固性等方面存在巨大局限。

(3) 分布式非關(guān)系型數(shù)據(jù)與關(guān)系型數(shù)據(jù)庫混合存儲模型。分布式非關(guān)系型數(shù)據(jù)庫能夠?qū)⒄埱髷?shù)據(jù)分布至不同節(jié)點,易于實現(xiàn)負載均衡和服務(wù)器水平擴展,進而提高響應(yīng)速度與并發(fā)性能。其中典型的代表即Redis集群作為分布式緩存架構(gòu),像新浪、GitHub、Pinterest[3]等互聯(lián)網(wǎng)公司已投入應(yīng)用。目前,電力行業(yè)也正深入研究并逐步向此模型邁進。

Redis官方在3.0版本后終于提供了集群化方案,但是官方并沒有對此集群方案在實際生產(chǎn)環(huán)境中進行充分驗證[4]。在實際生產(chǎn)環(huán)境中,Redis集群常會遇到以下問題：動態(tài)擴展能力較弱、可視化性能監(jiān)測缺失、節(jié)點狀態(tài)切換耗時長等。而且,一旦出現(xiàn)異常情況,運維人員不僅要熟知Redis集群相關(guān)架構(gòu),還要在組網(wǎng)架構(gòu)和路由轉(zhuǎn)發(fā)等方面有一定的知識沉淀,對運維人員技能要求高。

針對這種情況,本文基于Codis分布式緩存架構(gòu)進行研究及應(yīng)用,描述了整個架構(gòu)完整的部署方案及核心配置文件,并從電力系統(tǒng)中業(yè)務(wù)存儲能力、數(shù)據(jù)檢索效率、性能優(yōu)良檢測等多角度,對此方案進行深度測試。

1 Codis分布式緩存技術(shù)研究

1.1 Redis特性

基于鍵值對(Key-Value)儲存的非關(guān)系型數(shù)據(jù)庫憑借著靈活的數(shù)據(jù)模型及高性能的體驗[5],被廣泛應(yīng)用于互聯(lián)網(wǎng)及分布式計算等各個領(lǐng)域。在諸多Key-Value非關(guān)系型數(shù)據(jù)庫中,Redis是應(yīng)用最廣泛且最具有代表性的方案[6]。

Redis是開源的、高性能的、鍵值對存儲數(shù)據(jù)的NoSQL數(shù)據(jù)庫,常常被用于緩存和中間件[7]。相比于其他非關(guān)系型數(shù)據(jù)庫,Redis具有以下特點:

(1) 數(shù)據(jù)類型豐富。支持字符串(String)、鏈表(List)、普通集合(Set)、有序集合(Sorted Set)、散列(Hash)五大數(shù)據(jù)類型,輕松應(yīng)對實際產(chǎn)生環(huán)境中的各種數(shù)據(jù)結(jié)構(gòu)。

(2) 操作命令多樣。每種數(shù)據(jù)類型都對應(yīng)著多樣的操作命令,以字符串類型為例,除了常用的set、get命令完成字符數(shù)據(jù)的存取外,還支持替換字符串setrange、批量設(shè)置鍵值對mset、自增存儲數(shù)據(jù)的長度incrby、指定字符追加數(shù)據(jù)值append等命令,極大地方便了開發(fā)者對數(shù)據(jù)屬性的管理操作。

(3) 性能體驗極佳。Redis數(shù)據(jù)存取都是基于內(nèi)存中完成的,因此不會受到磁盤I/O讀寫速度的限制,讀寫速度高達10萬/s[8],遠遠優(yōu)于常規(guī)的關(guān)系型數(shù)據(jù)庫讀寫速度。

(4) 數(shù)據(jù)存儲安全。Redis提高了AOF和RDB兩種數(shù)據(jù)化持久方式[9],允許開發(fā)者自定義時間周期,定期地將內(nèi)存中的數(shù)據(jù)保存至磁盤中,以確保異常情況時迅速恢復(fù)數(shù)據(jù)集。

(5) 應(yīng)用范圍廣泛。目前Redis應(yīng)用于網(wǎng)站訪問量統(tǒng)計、網(wǎng)站在線人數(shù)統(tǒng)計、積分排行榜、消息緩存等多個方面。

1.2 Redis Cluster架構(gòu)

單節(jié)點Redis服務(wù)無法提供高并發(fā)、大數(shù)據(jù)服務(wù)的特性,因此必須采用Redis集群架構(gòu)進行彌補。

以官方提供方案中的Redis Cluster架構(gòu)為例,如圖1所示。Redis Cluster是一個去中心化的結(jié)構(gòu)模型,通過動態(tài)擴展多臺主機節(jié)點,實現(xiàn)Redis分布式架構(gòu)。多節(jié)點服務(wù)器間相互連接,并通過Gossip協(xié)議進行廣播消息通信,確保數(shù)據(jù)之間的同步。對于客戶端,只需任意連接其中一臺節(jié)點服務(wù)器進行相關(guān)讀寫操作,集群便會通過定義配置進行負載均衡,通過路由轉(zhuǎn)發(fā)去請求真正的服務(wù)器節(jié)點。

圖1 Redis Cluster架構(gòu)

通過架構(gòu)圖可知,Redis Cluster部署方案比較單一,集群內(nèi)部節(jié)點耦合度嚴重。一旦業(yè)務(wù)擴展,需要動態(tài)擴展成百上千節(jié)點時,部署龐大Redis集群將給運維人員帶來極大困難。同時,數(shù)據(jù)遷移、繁瑣配置文件、成千上萬行的運維命令,同樣會給運維人員帶來巨大的挑戰(zhàn)。

1.3 Codis分布式緩存架構(gòu)

Codis是由豌豆莢基于Go語言開發(fā)的一個分布式Redis集群解決方案,并于2014年11月對外開源。

Codis分布式緩存架構(gòu)底層將Redis集群按照一定規(guī)則進行分組,且每個組內(nèi)可以自定義主從配置,如圖2所示[10]。Codis架構(gòu)將Redis節(jié)點群進行分組細化,形成多個組群,分解了Redis集群中的整個去中心化網(wǎng)絡(luò)結(jié)構(gòu),簡化了Redis大集群部署的復(fù)雜度且降低了大集群管理難度。

圖2 Codis分布式緩存架構(gòu)

所有的Redis服務(wù)組通過codis-proxy代理進行管理,由于codis-proxy代理是無狀態(tài)的且無縫銜接Redis協(xié)議,因此上層客戶端可以直接通過codis-proxy代理與整個Redis服務(wù)組進行對接。當(dāng)發(fā)生讀寫請求的時候,客戶端的操作流程與原生的Redis Server并沒有太大差異。底層的轉(zhuǎn)發(fā)流程關(guān)鍵點在于codis-proxy代理,codis-proxy代理會根據(jù)請求按照一定的算法進行路由轉(zhuǎn)發(fā)及數(shù)據(jù)的遷移工作。正是由于codis-proxy代理的出現(xiàn),使得底層讀寫工作對客戶端相對透明,因此能夠充分利用動態(tài)擴展的Redis實例計算能力,從而完成大數(shù)據(jù)量和高并發(fā)的讀寫操作。除此之外,Codis架構(gòu)還提供了可供選擇的運維便捷、高性能化管理的交互組件,組件如下。

(1) Codis Server。在Codis集群架構(gòu)中,會采用插槽(slot)的方式來分配數(shù)據(jù),默認將slot分為1 024份,開發(fā)者可以自行對這1 024份slot進行g(shù)roup分組操作,當(dāng)客戶端進行存儲的時候,會調(diào)用CRC32取模算法,將指定的key映射至對應(yīng)的節(jié)點。redis-server啟動、每部分數(shù)據(jù)插槽管理及數(shù)據(jù)遷移的工作都可以交給Codis Server進行處理。

(2) Codis Dashboard。Codis Dashboard負責(zé)Codis集群的配置工作,該組件支持開發(fā)者通過指定的RESTful接口完成codis-proxy、codis-server的添加及刪除任務(wù)。同時,該組件可以通過Redis的哨兵機制確保codis-proxy狀態(tài)信息一致性。

(3) Codis FE。利用Codis FE,開發(fā)者可以通過可視化Web界面,一鍵式部署Redis服務(wù)節(jié)點、創(chuàng)建codis-proxy代理節(jié)點,甚至可以實時監(jiān)控整個集群運行的性能狀況。

(4) Codis Admin。利用Codis Admin組件,開發(fā)者可以使用命令行工具完成codis-proxy創(chuàng)建、codis-dashboard狀態(tài)變更等控制任務(wù)。此組件的存在,使得Codis整個架構(gòu)更加完整,開發(fā)者不僅可以通過圖形化界面管理集群,而且還可以使用傳統(tǒng)的命令行工具進行管理操作。

2 Codis分布式緩存架構(gòu)部署

2.1 硬件環(huán)境

整個Codis架構(gòu)的部署共涉及5臺服務(wù)器進行模擬實際生產(chǎn)環(huán)境,各臺服務(wù)器的硬件信息如表1所示。

表1 服務(wù)器硬件信息

2.2 軟件環(huán)境

此集群架構(gòu)每臺服務(wù)器節(jié)點上所涉及軟件環(huán)境為:Go 1.7.1、JDK1.7.0、Codis 3.1、Redis3.2.4、ZooKeeper3.4.9。具體節(jié)點部署信息如表2所示。

表2 服務(wù)器軟件信息

2.3 部署流程

由于整個Codis分布式緩存架構(gòu)組件較多,接下來主要描述架構(gòu)搭建關(guān)鍵步驟及部分核心配置,其他非關(guān)鍵性配置信息省略。

(1) Go語言及依賴庫的安裝。由于Codis是基于Go語言開發(fā)的,因此首先必須確保基礎(chǔ)環(huán)境的存在,具體命令如下：

yum install autoconf automake libtool -y

yum install -y gcc glibc gcc-c++ make git

cd ＄GOPATH/src/github.com/CodisLabs/codis

make

(2) Java環(huán)境及ZooKeeper安裝。ZooKeeper核心配置文件zoo.cfg部分配置信息如下：

tickTime=2000

#自定義心跳檢測發(fā)送時間

dataDir=/usr/data/zookeeper

#自定義產(chǎn)生數(shù)據(jù)路徑

server.1=192.168.2.105:2888:3888 #添加主機服務(wù)地址

(3) Codis Server安裝與配置。codis-server部署成功后將替代redis-server進行啟動,關(guān)鍵配置如下：

#bind 127.0.0.1

#為了安全考慮建議綁定內(nèi)網(wǎng)IP,防止外網(wǎng)訪問

port 6379

#redis節(jié)點監(jiān)聽端口,生成環(huán)境中建議更換為非常用端口

daemonize yes

#開啟守護進程模式

pidfile/usr/local/redis/redis-6380/run/redis_6380.pid

#自定義pid進程文件生成的位置

logfile/usr/local/redis/redis6380/logs/logs_6380.log

#自定義log日志文件生成的位置

dir/usr/local/redis/redis-6380/db

#自定義數(shù)據(jù)文件生成的位置

requirepass mark-codis

#開啟登錄主機密碼

(4) Codis Dashboard安裝與配置。Dashboard安裝編譯成功后會生成一個dashboard.ini配置文件,需要對此文件進行如下修改：

coordinator_name="zookeeper"

#使用的協(xié)調(diào)器的名稱,只

#能設(shè)置兩個zookeeper、etcd關(guān)系的鍵值對

coordinator_addr="192.168.2.105:2181"

#使用的協(xié)調(diào)器的節(jié)點地址

product_name="codis-demo"

#該產(chǎn)品名稱

product_auth="mark-codis"

#該產(chǎn)品的授權(quán)秘鑰

admin_addr="0.0.0.0:18080"

#自定義后臺管理路徑的地址和端口

(5) Codis Proxy安裝與配置。codis-proxy安裝編譯成功后會生成一個proxy.ini配置文件,需要對此文件進行如下修改：

product_name="codis-demo"

#該產(chǎn)品名稱

product_auth="mark-codis"

#該產(chǎn)品的授權(quán)秘鑰

jodis_name="zookeeper"

#使用的協(xié)調(diào)器

admin_addr="0.0.0.0:11080"

#連接地址

jodis_addr="192.168.2.105:2181"

#設(shè)置zookeeper地址

(6) Codis FE安裝與配置。使用codis-admin提供的相關(guān)命令即可快速完成codis-fe的安裝：

/usr/local/codis/bin/codis-admin—dashboard-list—zookeeper=192.168.2.105|tee/usr/local/codis/conf/codis.json

所有組件部署并啟動成功后,在瀏覽器中輸入codis-fe進程運行所在節(jié)點的主機地址,即192.168.2.105:18090/#codis-demo,可以發(fā)現(xiàn)Codis架構(gòu)已經(jīng)正常啟動。Codis架構(gòu)部署成功后啟動界面如圖3所示。

圖3 Codis架構(gòu)部署成功部分界面

3 電力系統(tǒng)中Codis架構(gòu)應(yīng)用及測試

3.1 業(yè)務(wù)存儲

漏電、過載、短路等電氣異常是火災(zāi)引發(fā)的重要因素[11-12],因此電力系統(tǒng)中通常存在監(jiān)控子模塊,不間斷采集用電線路中的電壓、電流、諧波、功率等數(shù)據(jù),并通過時分秒等時間刻度趨勢圖進行分析預(yù)測。這就意味著短時間內(nèi)電力系統(tǒng)中將要存儲大量電力數(shù)據(jù),并且需要在不同時間刻度之間進行快速的數(shù)據(jù)運算,而這些短時間內(nèi)電力數(shù)據(jù)并不需要長期保存,因此可以采用Hash結(jié)構(gòu)存儲電力屬性數(shù)據(jù),并根據(jù)線路、時間刻度等關(guān)鍵信息為基礎(chǔ)設(shè)置Key值(electric_線路_秒),具體存儲模型如圖4所示。

圖4 電力線路數(shù)據(jù)存儲結(jié)構(gòu)

當(dāng)準備向Codis架構(gòu)中存儲采集到的電力數(shù)據(jù)時,首先需要先連接至codis-proxy代理,命令如下：

/home/mark/Cluster/gowork/src/github.com/CodisLabs/codis/extern/redis-3.2.4/src/redis-cli-h 192.168.2.105-a foobared-p 19000

然后通過hset命令向Codis架構(gòu)中存儲電力數(shù)據(jù),當(dāng)存儲部分電力數(shù)據(jù)后,試圖分別登錄codis-server01、codis-server02、codis-server03,尋找electric_trunk1_road01對應(yīng)的Hash值,發(fā)現(xiàn)并不是每臺redis服務(wù)組上的每個redis節(jié)點都儲存著指定的key值數(shù)據(jù),實際上這條指定的key對應(yīng)的鍵值,會經(jīng)過CRC32的取模算法映射至一臺指定redis節(jié)點。這意味著該集群底層可以被無限地擴展,形成一個原則上內(nèi)存無限大的Redis服務(wù)。動態(tài)擴展的多節(jié)點可以通過自定義規(guī)則按照組別劃分,對Redis集群中復(fù)雜交錯的網(wǎng)絡(luò)拓撲結(jié)構(gòu)進行了解耦,有力地加強對Redis集群的管理。而且Codis架構(gòu)底層運作原理對于開發(fā)者來講又是透明的,開發(fā)者只需要像操作原生單節(jié)點Redis服務(wù)一樣操作Codis架構(gòu)即可完成數(shù)據(jù)存儲,這將大大提高電力業(yè)務(wù)數(shù)據(jù)的存儲能力與效率。

3.2 索引檢索

在電力系統(tǒng)中監(jiān)控模塊往往存在一些公共的數(shù)據(jù)信息,如線路坐標信息。這些信息通常不會變更,需要持久保存,但在系統(tǒng)中卻經(jīng)常去檢索相關(guān)線路坐標信息。為了能夠快速地按照建筑、樓層等要素值進行檢索,可以仿照3.1節(jié)中涉及的業(yè)務(wù)存儲模型建立相關(guān)的Hash結(jié)構(gòu)儲存。

為了測試Codis架構(gòu)檢索的速度,設(shè)置電力數(shù)據(jù)請求參數(shù)集：不同數(shù)量的客戶端并發(fā)數(shù)，每個客戶端請求均為1 000次,請求數(shù)據(jù)量大小均為10 000 B,分別在Codis架構(gòu)和部署了3臺相同硬件配置服務(wù)器(共計9個Redis服務(wù)節(jié)點)的Redis集群上進行測試,測試結(jié)果如圖5所示。

圖5 并發(fā)響應(yīng)時間對比

從實驗結(jié)果來看,Codis架構(gòu)雖經(jīng)過Proxy代理真正Redis服務(wù)節(jié)點并且配置了多種組件的情況下,性能并不輸于Redis集群,當(dāng)客戶端并發(fā)量超過700個左右時,Codis架構(gòu)的性能甚至略優(yōu)于Redis集群；當(dāng)客戶端并發(fā)量達到1 000個時,Codis架構(gòu)可以在40 ms內(nèi)檢索到數(shù)據(jù),由此可推斷Codis架構(gòu)可以高速地完成電力數(shù)據(jù)的檢索工作。

3.3 性能監(jiān)測

電力系統(tǒng)業(yè)務(wù)復(fù)雜,性能指標不僅僅體現(xiàn)在數(shù)據(jù)存儲容量、檢索效率方面,數(shù)據(jù)吞吐能力也是關(guān)鍵一環(huán),數(shù)據(jù)吞吐能力高低直接決定了Codis分布式緩存架構(gòu)是否能夠應(yīng)用于電力系統(tǒng)中。

為此,分別設(shè)置不同的請求量對Codis分布式緩存架構(gòu)中操作頻繁的命令進行QPS測試,測試結(jié)果如圖6所示。

圖6 Codis架構(gòu)中頻繁操作命令QPS

測試結(jié)果表明,對于產(chǎn)生環(huán)境中操作頻繁的命令在多客戶端情況下進行請求,每秒鐘能夠響應(yīng)的請求次數(shù)依舊有著不俗表現(xiàn),而且在測試期間,后端codis-server平均CPU占用率約為60%～85%,意味著此時Codis架構(gòu)并非滿負載運行,每臺codis-server服務(wù)器仍存在空余空間完成其他操作。與同硬件環(huán)境的9臺Redis集群相比,同指令相同請求量下QPS沒有太大差距,Codis架構(gòu)的數(shù)據(jù)吞吐能力依舊可以勝任電力系統(tǒng)中緩存數(shù)據(jù)讀寫的工作。

3.4 部署運維

Redis集群作為緩存架構(gòu)在電力系統(tǒng)中長期運行,一方面,隨著電網(wǎng)規(guī)模的擴張和電力業(yè)務(wù)的變動,快速地部署更多Redis服務(wù)節(jié)點是必經(jīng)之路；另一方面,不可避免地會因為內(nèi)部代碼Bug、硬件問題或者外部因素出現(xiàn)故障,從而導(dǎo)致整個電力系統(tǒng)運行不穩(wěn)定。及時地鎖定故障節(jié)點并排查故障原因,能夠極大地減少故障處理時間,減少運維人員工作量,進而提高電力系統(tǒng)運行的穩(wěn)定性。然而,Redis集群關(guān)于以上兩點都沒有給出相應(yīng)的解決方案，但是Codis架構(gòu)卻提供了圖形化界面，完成新的Redis節(jié)點部署與故障節(jié)點的定位排查,如圖7所示。

圖7 Codis架構(gòu)中Redis節(jié)點管理可視化界面

4 結(jié) 語

本文從電力系統(tǒng)中緩存架構(gòu)存在的實際問題出發(fā),對Codis分布式緩存架構(gòu)進行研究,并給出該架構(gòu)的核心配置步驟及方案,然后對其在電力系統(tǒng)中的業(yè)務(wù)存儲能力、索引檢索效率、性能優(yōu)良分析等方面進行實際應(yīng)用與測試。實驗證明,該架構(gòu)在數(shù)據(jù)儲存與索引查詢上具備優(yōu)異性能,在可視化分析、運維管理角度突出于Redis集群,具有一定的研究與推廣價值。

下一步將繼續(xù)結(jié)合電力系統(tǒng)中實際應(yīng)用場景,對Codis分布式緩存架構(gòu)的高可用、故障轉(zhuǎn)移方面做進一步的研究。