基于Key-Value的內存緩存系統在OMP鑒權中心中的應用*

李文嘉，李煒，王晶

（1 北京郵電大學網絡與交換國家重點實驗室，北京 100876；2 東信北郵信息技術有限公司北京 100191）

基于Key-Value的內存緩存系統在OMP鑒權中心中的應用*

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

（1 北京郵電大學網絡與交換國家重點實驗室，北京 100876；2 東信北郵信息技術有限公司北京 100191）

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

內存緩存；能力開放平臺；J2EE

1 引言

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

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

2 Redis系統

2.1 Redis簡介

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

2.2 Redis特點

* Redis包含更豐富的數據類型，且這些數據類型的相關操作都是原子性的。Redis的數據類型和基本的數據結構極其相似，這樣在客戶端實現時不必要為此進行額外的開發；依此可以簡單地實現RDBMS或其他一些緩存系統很難完成的一些實現；

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

* 支持主從復制功能[3]；

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

3 Redis在OMP中的應用

3.1 問題描述

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

3.2 部署架構

圖1 OMP鑒權中心部署結構圖

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

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

3.3 部署方案

3.3.1 Redis Server部署

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

#path/Redis-server path/Redis.conf

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

3.3.2 客戶端部署

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

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

業務邏輯要維護一個JedisPool單例，通過Jedis提供的API，執行Redis的相關操作。

3.4 性能測試比對

測試環境如表1所示。

測試結果如表2所示，分析可以發現，使用了Redis之后，業務處理能力有了明顯提升。目前僅將部分表數據刷新至Redis中，若將數據量更大、訪問更頻繁的訂購關系數據也置入Redis中，鑒權中心的業務處理能力還會有更明顯的提升。

表1 測試環境

表2 測試結果對比

3.5 Redis主從復制缺陷及解決方案

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

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

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

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

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

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

方案二：部署多套Redis實例，選擇一個為主機。客戶端側進行改造，客戶端連接一個實例，配多套Redis實例連接備選，并增加相應的路由管理。當客戶端連接主路由失敗時，嘗試連接備用路由，同時需要重啟主路由所連接Redis實例，并且切換Redis實例的主從關系。Redis實例的主從切換需要客戶端在進行路由切換的時候通知HA軟件[6]或直接調用相關腳本進行。

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

4 結束語

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

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

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

[3] 楊艷，李煒，王純. 內存數據庫在高速緩存方面的應用[J].現代電信科技，2011，12：59-64.

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

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

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

[7] 劉曉潔， 黃永佳. 基于Linux的雙機熱備系統的實現技術[J].計算機應用研究，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

國家自然科學基金（No. 61072057，61101119，61121001，60902051）；長江學者和創新團隊發展計劃資助（No. IRT1049）；國家科技重大專項（No. 2011ZX03002-001-01，移動互聯網總體架構研究）。