基于Key-Value的內(nèi)存緩存系統(tǒng)在OMP鑒權(quán)中心中的應(yīng)用*

李文嘉，李煒，王晶

（1 北京郵電大學(xué)網(wǎng)絡(luò)與交換國家重點實驗室，北京 100876；2 東信北郵信息技術(shù)有限公司北京 100191）

基于Key-Value的內(nèi)存緩存系統(tǒng)在OMP鑒權(quán)中心中的應(yīng)用*

李文嘉1，2，李煒1，2，王晶1，2

（1 北京郵電大學(xué)網(wǎng)絡(luò)與交換國家重點實驗室，北京 100876；2 東信北郵信息技術(shù)有限公司北京 100191）

OMP（Open Mobile Platform，能力開放平臺）是中國移動集團為開放其基礎(chǔ)能力給開發(fā)者進行應(yīng)用開發(fā)以滿足用戶個性化需求，并提供相應(yīng)的運營管理功能的通用平臺。為了降低鑒權(quán)中心數(shù)據(jù)庫負載、提高應(yīng)用的處理和響應(yīng)速度，引入了一種高性能的內(nèi)存緩存系統(tǒng)Redis。本文簡單介紹了Redis系統(tǒng)并將其應(yīng)用于OMP鑒權(quán)中心，最后對存在的問題進行分析并提出改進建議。

內(nèi)存緩存；能力開放平臺；J2EE

1 引言

Web 2.0時代提出以人為互聯(lián)網(wǎng)中心，網(wǎng)絡(luò)成了新的平臺，傳統(tǒng)互聯(lián)網(wǎng)用戶被動獲取信息的模式被打破。許多互聯(lián)網(wǎng)企業(yè)都建立自己的平臺，對外開放能力供開發(fā)者構(gòu)建應(yīng)用，以滿足用戶的個性化需求。中國移動雖已建設(shè)了多種能力開放網(wǎng)關(guān)，但是不同網(wǎng)關(guān)的接口卻大相徑庭。這就造成了能力雖然開放，但能力和具體應(yīng)用的集成周期過長，很難滿足目前互聯(lián)網(wǎng)應(yīng)用情形下的快速模式。由此中國移動推出自己的開放平臺來解決此困境。

開放能力引擎(Open Mobile Platform，OMP)是以提供業(yè)務(wù)能力開放，并實現(xiàn)與能力開放相關(guān)的管理運營為主要功能的平臺系統(tǒng)。此系統(tǒng)屏蔽了低層網(wǎng)絡(luò)復(fù)雜性、統(tǒng)一了各能力網(wǎng)關(guān)的調(diào)用接口，并提供了管理運用業(yè)務(wù)服務(wù)，以及多種業(yè)務(wù)計費模式。為保證安全性，構(gòu)建鑒權(quán)中心實現(xiàn)統(tǒng)一認證、鑒權(quán)[1]。隨著業(yè)務(wù)的推廣，用戶數(shù)的增加，在對平臺運行情況監(jiān)測的過程中發(fā)現(xiàn)，目前的OMP鑒權(quán)中心的性能瓶頸集中在數(shù)據(jù)庫中。為了應(yīng)對以后更大的業(yè)務(wù)需求，增強OMP鑒權(quán)中心的業(yè)務(wù)處理能力，我們引入一種高性能Key-Value（KV）內(nèi)存緩存系統(tǒng) Redis來解決此問題。本文主要介紹該系統(tǒng)并將其應(yīng)用在OMP鑒權(quán)中心中，最后對遇到的一些問題提出了改進方案。

2 Redis系統(tǒng)

2.1 Redis簡介

Redis（Remote Dictionary Server），是一個開源的、KV存儲系統(tǒng)，和Memcached類似，但是支持更多的數(shù)據(jù)類型， 除String外，還支持list、set(無序集合)、zset(有序集合)和散列等幾種數(shù)據(jù)結(jié)構(gòu)，這些數(shù)據(jù)結(jié)構(gòu)支持push/pop、add/remove以及相關(guān)集合操作，使得開發(fā)者有了更多選擇，而且大部分操作都是原子性的。同時Redis還提供了持久化方案，可以將異常情況造成的損失降低到最小[2]。

2.2 Redis特點

* Redis包含更豐富的數(shù)據(jù)類型，且這些數(shù)據(jù)類型的相關(guān)操作都是原子性的。Redis的數(shù)據(jù)類型和基本的數(shù)據(jù)結(jié)構(gòu)極其相似，這樣在客戶端實現(xiàn)時不必要為此進行額外的開發(fā)；依此可以簡單地實現(xiàn)RDBMS或其他一些緩存系統(tǒng)很難完成的一些實現(xiàn)；

* Redis是內(nèi)存緩存存儲系統(tǒng)，同時也支持持久化至磁盤，當所記錄的數(shù)據(jù)大于實際內(nèi)存所能支撐，則可以通過開啟Virtual Memory模式將很少使用的KV對保存到Disk中，從而降低物理內(nèi)存的占用；

* 支持主從復(fù)制功能[3]；

* Redis中保存的數(shù)據(jù)都存儲在Redis內(nèi)置的內(nèi)存存儲空間中。數(shù)據(jù)容量達到指定值之后，就基于LRU(Least Recently Used)算法[4]自動刪除不使用的緩存。

3 Redis在OMP中的應(yīng)用

3.1 問題描述

OMP鑒權(quán)中心主要的業(yè)務(wù)流程為鑒權(quán)批價流程，每個鑒權(quán)批價全流程中會觸發(fā)一系列業(yè)務(wù)邏輯，其中涉及多次數(shù)據(jù)庫訪問操作。后期性能優(yōu)化調(diào)研的過程中發(fā)現(xiàn)，全流程中所涉及的表主要集中在其中幾個，如能力信息表、能力計費信息表等。隨著業(yè)務(wù)量增大，數(shù)據(jù)庫負擔(dān)會不斷增加，導(dǎo)致整個應(yīng)用響應(yīng)速度的降低。在此引入內(nèi)存緩存系統(tǒng)，將常用數(shù)據(jù)緩存起來，以減少數(shù)據(jù)庫的訪問次數(shù)，從而提高應(yīng)用的處理效率、降低響應(yīng)時延。

3.2 部署架構(gòu)

圖1 OMP鑒權(quán)中心部署結(jié)構(gòu)圖

OMP鑒權(quán)中心采用J2EE (Java 2 Platform Enterprise Edition)三層架構(gòu)設(shè)計，分為表現(xiàn)層、業(yè)務(wù)邏輯層和持久化層[5]，從物理結(jié)構(gòu)上分大體包括接口服務(wù)器，呼叫節(jié)點、管理節(jié)點及數(shù)據(jù)庫服務(wù)器(數(shù)據(jù)庫中間件、存儲、話單服務(wù)器和數(shù)據(jù)快速訪問節(jié)點)。OMP鑒權(quán)子系統(tǒng)部署結(jié)構(gòu)如圖1所示。

Redis為內(nèi)存緩存系統(tǒng)，對在大數(shù)據(jù)量的情況下會占用大量物理內(nèi)存，但CPU占用較低，故可以將Redis與業(yè)務(wù)量較小、內(nèi)存占用較少(CPU占用高)的應(yīng)用部署在同一服務(wù)器以減少物理節(jié)點從而降低維護成本。管理節(jié)點為主備，可以共用一個Redis Server，呼叫節(jié)點為雙機，共用一個Redis Server。同時將兩個Redis Server部署為Master-Slave形式，利用Redis的復(fù)制功能來保證數(shù)據(jù)一致性。

3.3 部署方案

3.3.1 Redis Server部署

Redis Server下載及安裝可以參考Redis官方網(wǎng)站。安裝比較簡單，但是為了更好的使用Redis服務(wù)，需根據(jù)自己的需求做些配置上的修改。如數(shù)據(jù)庫數(shù)量，是否使用快照，AOF設(shè)置等，建議關(guān)閉Redis的VM功能。啟動參數(shù)為配置文件路徑：

#path/Redis-server path/Redis.conf

如果Redis Server做持久化，建議分配給Redis Server的內(nèi)存為實際所需物理內(nèi)存數(shù)量的兩倍。因為在進行RDB文件寫操作和AOF rewrite過程中，Redis會fork一個子進程來完成，此時會占用雙倍內(nèi)存。如果物理內(nèi)存過小，會導(dǎo)致不可預(yù)知的錯誤。

3.3.2 客戶端部署

Redis客戶端選擇官方推薦的Jedis作為OMP鑒權(quán)中心的Java客戶端。通過手動添加jar文件或在maven中添加jedis的依賴[6]：

業(yè)務(wù)啟動時對JedisPool連接池進行初始化，根據(jù)配置的Redis的連接信息、超時時間、最大活動鏈接和空閑連接數(shù)等參數(shù)，連接池會創(chuàng)建并維護連接，減少每次操作時創(chuàng)建銷毀與Redis Server連接的開銷，同時也能短期大量進行創(chuàng)建銷毀連接導(dǎo)致的端口資源耗竭。

業(yè)務(wù)邏輯要維護一個JedisPool單例，通過Jedis提供的API，執(zhí)行Redis的相關(guān)操作。

3.4 性能測試比對

測試環(huán)境如表1所示。

測試結(jié)果如表2所示，分析可以發(fā)現(xiàn)，使用了Redis之后，業(yè)務(wù)處理能力有了明顯提升。目前僅將部分表數(shù)據(jù)刷新至Redis中，若將數(shù)據(jù)量更大、訪問更頻繁的訂購關(guān)系數(shù)據(jù)也置入Redis中，鑒權(quán)中心的業(yè)務(wù)處理能力還會有更明顯的提升。

表1 測試環(huán)境

表2 測試結(jié)果對比

3.5 Redis主從復(fù)制缺陷及解決方案

較Memcached而言，Redis新增了主從復(fù)制功能，但并未提供增量同步，這在實際使用中會帶來一些效率上的問題。

如：當Slave由于錯誤或網(wǎng)絡(luò)問題與Master斷開連接，Slave進行重新連接時，會向Master發(fā)起一個sync請求，主機此時會創(chuàng)建一個最新的快照(Snap Shot)， 然后同步給Slave。Slave接收后先將全部數(shù)據(jù)除，然后重新建立整個內(nèi)存表。Slave在進行內(nèi)存數(shù)據(jù)恢復(fù)的過程中，數(shù)據(jù)復(fù)制是阻塞業(yè)務(wù)的，即客戶端來的請求Slave是不予受理的。主機在進行快照操作的時候也會帶來一定壓力。

通過需求分析，目前我們部署一臺Redis Server即可應(yīng)對當前業(yè)務(wù)，即便是做數(shù)據(jù)緩存而非存儲，對于故障的及時有效處理也是需要我們考慮的。在此我們提出了這樣兩種部署方案來解決單機故障。

方案一：在兩臺服務(wù)器上分別部署一套Redis，兩臺服務(wù)器共用一個浮動IP，兩套Redis實例則做MasterSlave形式，始終由浮動IP指向服務(wù)器上的Redis實例做Master。使用HA軟件來檢測Redis實例的運行情況[7]，如果從機出現(xiàn)異常，則重啟從機Redis實例；當主機出現(xiàn)異常，則進行如下操作：

（1）Slave主動斷開與Master的連接(通過HA軟件調(diào)用預(yù)置腳本實現(xiàn))，然后HA軟件將浮動IP指向備機，進行主備機切換；

（2）切換后，HA軟件嘗試重啟現(xiàn)備機的Redis實例，重啟成功后將其配置為現(xiàn)主機Redis實例的Slave，然后開始主從復(fù)制。

方案二：部署多套Redis實例，選擇一個為主機?？蛻舳藗?cè)進行改造，客戶端連接一個實例，配多套Redis實例連接備選，并增加相應(yīng)的路由管理。當客戶端連接主路由失敗時，嘗試連接備用路由，同時需要重啟主路由所連接Redis實例，并且切換Redis實例的主從關(guān)系。Redis實例的主從切換需要客戶端在進行路由切換的時候通知HA軟件[6]或直接調(diào)用相關(guān)腳本進行。

兩個方案比較：第一種方案不用對客戶端做太多改造，但是切換過程可能會造成短時Redis不可用。第二種方案則反之，但是在Redis Server端仍需要相應(yīng)的軟件或者腳本來實現(xiàn)Redis的一些操作，如Master-Slave關(guān)系的切換。具體方案選擇需根據(jù)具體需求進行。

4 結(jié)束語

作為一個高性能對象緩存系統(tǒng)，在鑒權(quán)中心引入Redis之后，有效降低了數(shù)據(jù)庫負擔(dān)，提高了處理的效率與響應(yīng)速度。作為一個推出時間不久的緩存系統(tǒng)，它的優(yōu)勢突出，缺點也很明顯。但是我們相信，隨著Redis的改進，Redis的前景會更明朗。

[1] 中國移動集團，能力開放引擎總體技術(shù)要求[Z]. 2011.03.

[2] Salvatore Sanfilippo and Pieter Noordhuis [EB/OL] http：//redis.io/ topics/introduction.

[3] 楊艷，李煒，王純. 內(nèi)存數(shù)據(jù)庫在高速緩存方面的應(yīng)用[J].現(xiàn)代電信科技，2011，12：59-64.

[4] 王文林，廖建新，朱曉民. VoiceXML語音平臺緩存技術(shù)綜述[J].通信學(xué)報，2007，28(2)：101-108.

[5] 戚琦，廖建新，王純，武家春. 基于敏捷方法的輕量級J2EE架構(gòu)的應(yīng)用[J]. 計算機系統(tǒng)應(yīng)用，2007，(2)：53-56.

[6] Jonathan Leibiusky [EB/OL] https：//github.com/xetorthio/jedis

[7] 劉曉潔， 黃永佳. 基于Linux的雙機熱備系統(tǒng)的實現(xiàn)技術(shù)[J].計算機應(yīng)用研究，2007，27(4)：255-257.

Application of key-value memory caching system in authentication center of open mobile platform

LI Wen-jia1,2, LI Wei1,2, WANG Jing1,2
(1 State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing 100876, China; 2 EB Information Technology Co. Ltd, Beijing 100191, China)

OMP (Open Mobile Platform) is an open common platform that developers will design and develop various applications on it with the abilities integrated by China Mobile Communications Corporation to satisfy consumer’s needs. In order to cut down the database load and improve the efficiency of service procedure, we introduced a high-performance in-memory caching system called Redis and applied it to authentication center of OMP. In this article, we briefly introduced the redis and the way to deploy redis on authentication center. And then, we analyzed some problems encountered and finally put forward several practical suggestions to solve these problems.

memory cache; open mobile platform; J2EE

TN929.5

A

1008-5599（2012）09-0078-04

2012-08-28

國家自然科學(xué)基金（No. 61072057，61101119，61121001，60902051）；長江學(xué)者和創(chuàng)新團隊發(fā)展計劃資助（No. IRT1049）；國家科技重大專項（No. 2011ZX03002-001-01，移動互聯(lián)網(wǎng)總體架構(gòu)研究）。