基于Key-Value的内存缓存系统在OMP鉴权中心中的应用2012-09《电信工程技术与标准化》
李文嘉1,2 李炜1,2 王晶1,2
(1.北京邮电大学网络与交换国家重点实验室 北京 100876,
2.东信北邮信息技术有限公司 北京 100191)
摘 要: OMP(Open Mobile Platform,能力开放平台)是中国移动集团为开放其基础能力给开发者进行应用开发以满足用户个性化需求,并提供相应的运营管理功能的通用平台。为了降低鉴权中心数据库负载、提高应用的处理和响应速度,引入了一种高性能的内存缓存系统Redis。本文简单介绍了Redis系统并将其应用于OMP鉴权中心,最后对存在的问题进行分析并提出改进建议。
关键词: 内存缓存、能力开放平台、J2EE
Application of Key-Value Memory Caching System in Authentication Center of Open Mobile Platform
Li Wenjia1,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)
Abstract: 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.
Key Words: Memory Cache、Open Mobile Platform(OMP)、J2EE
1. 引言
Web2.0时代提出以人为互联网中心,网络成了新的平台,传统互联网用户被动获取信息的模式被打破。许多互联网企业都建立自己的平台,对外开放能力供开发者构建应用,以满足用户的个性化需求。中国移动虽已建设了多种能力开放网关,但是不同网关的接口却大相径庭。这就造成了能力虽然开放,但能力和具体应用的集成周期过长,很难满足目前互联网应用情形下的快速模式。由此中国移动推出自己的开放平台来解决此困境。
开放能力引擎(Open Mobile Platform,OMP)是以提供业务能力开放,并实现与能力开放相关的管理运营为主要功能的平台系统。此系统屏蔽了低层网络复杂性、统一了各能力网关的调用接口,并提供了管理运用业务服务,以及多种业务计费模式。为保证安全性,构建鉴权中心实现统一认证、鉴权[1]。随着业务的推广,用户数的增加,在对平台运行情况监测的过程中发现,目前的OMP鉴权中心的性能瓶颈集中在数据库中。为了应对以后更大的业务需求,增强OMP鉴权中心的业务处理能力,我们引入一种高性能Key-Value内存缓存系统--Redis来解决此问题。本文主要介绍该系统并将其应用在OMP鉴权中心中,最后对遇到的一些问题提出了改进方案。
2. Redis系统
3.1. Redis简介
Redis全称为:REmote DIctionary Server,是一个开源的、Key-Value存储系统,和Memcached类似,但是支持更多的数据类型,除String外,还支持list、set(无序集合)、zset(有序集合)和Hash等几种数据结构,这些数据结构支持push/pop、add/remove以及相关集合操作,使得开发者有了更多选择,而且大部分操作都是原子性的。同时Redis还提供了持久化方案,可以将异常情况造成的损失降低到最小[2]。
3.2. Redis特点
l Redis包含更丰富的数据类型,且这些数据类型的相关操作都是原子性的。Redis的数据类型和基本的数据结构极其相似,这样在客户端实现时不必要为此进行额外的开发;依此可以简单地实现RDBMS或其他一些缓存系统很难完成的一些实现;
l Redis是内存缓存存储系统,同时也支持持久化至磁盘,当所记录的数据大于实际内存所能支撑,则可以通过开启Virtual Memory模式将很少使用的KV对保存到Disk中,从而降低物理内存的占用;
l 支持主从复制功能[3];
l 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],从物理结构上分大体包括接口服务器,呼叫节点、管理节点及数据库服务器(DB中间件、存储、话单服务器和数据快速访问节点)。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]:
<!-- java readis客户端 -->
<dependency>
<groupId>Redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>2.0.0</version>
</dependency>
|
业务启动时对JedisPool连接池进行初始化,根据配置的Redis的连接信息、超时时间、最大活动链接和空闲连接数等参数。连接池会创建并维护连接,减少每次操作时创建销毁与RedisServer连接的开销,同时也能方式短期大量进行创建销毁连接导致的端口资源耗竭。
业务逻辑要维护一个JedisPool单例,通过Jedis提供的API,执行Redis的相关操作。
3.4. 性能测试比对
测试环境如表1所示:
表 1 测试环境
机器硬件
|
HP ProLiant DL580 G5(487362-AA1)
Intel Xeon 2.67GH*4,4 Cores/16G Memory
|
操作系统
|
Red Hat Enterprise Linux Server release 5.5
|
数据库
|
Oracle 11g
|
运行环境
|
JDK1.7
|
表 2 测试结果对比
测试项
测试条件
|
平均处理速率(caps)
|
未使用Redis
|
789.9
|
使用Redis
|
923.2
|
测试结果如表2所示,分析可以发现,使用了Redis之后,业务处理能力有了明显提升。目前仅将部分表数据刷新至Redis中,若将数据量更大、访问更频繁的订购关系数据也置入Redis中,鉴权中心的业务处理能力还会有更明显的提升。
3.5. Redis主从复制缺陷及解决方案
较Memcached而言,Redis新增了主从复制功能,但并未提供增量同步,这在实际使用中会带来一些效率上的问题。
如:
当Slave由于错误或网络问题与Master断开连接,Slave进行重新连接时,会向Master发起一个sync请求,主机此时会创建一个最新的快照(SnapShot),然后同步给Slave。Slave接收后先将全部数据除,然后重新建立整个内存表。Slave在进行内存数据恢复的过程中,数据复制是阻塞业务的,即客户端来的请求Slave是不予受理的。主机在进行快照操作的时候也会带来一定压力。
通过需求分析,目前我们部署一台Redis服务器即可应对当前业务,即便是做数据缓存而非存储,对于故障的及时有效处理也是需要我们考虑的。在此我们提出了这样两种部署方案来解决单机故障。
方案一:在两台服务器上分别部署一套Redis,两台服务器共用一个浮动IP,两套Redis实例则做Master-Slave,始终由浮动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] 中国移动集团,能力开放引擎总体技术要求,2011.03
[2] Salvatore Sanfilippo and Pieter Noordhuis [online]http://redis.io/topics/introduction
[3] 杨艳,李炜,王纯,内存数据库在高速缓存方面的应用,现代电信科技,2011,12:59-64
[4] 王文林,廖建新,朱晓民,VoiceXML语音平台缓存技术综述,通信学报,2007,28(2):101-108
[5] 戚琦,廖建新,王纯,武家春,基于敏捷方法的轻量级J2EE架构的应用,计算机系统应用,2007,(2):53-56
[6] Jonathan Leibiusky [online]https://github.com/xetorthio/jedis
[7] 刘晓洁, 黄永佳,基于Linux的双机热备系统的实现技术,计算机应用研究,2007,27(4):255-257