分布式缓存在电影基础信息中的应用

马荣彦

(中央宣传部电影数字节目管理中心,北京 100866)

1 引言

近年来,随着计算机互联网技术的发展,大数据的存取以及网站的快速响应成为现在web应用发展所面临的一个巨大的挑战。农村数字电影公共服务平台基于影片信息库中的影片向监管部门、院线、发行方等用户提供了流动放映业务的信息、制作、分发、管理等技术监管服务,影片基础信息库中引入了许多市场上的影片新片,这是整个平台赖以生存的基础,各种角色的用户登陆平台都需要浏览查询影片的基本信息,这对平台的检索展现速度有了更高的要求,同时也对数据库的性能方面提出了更高的要求。为了保证系统运行性能的冗余,查询性能是系统整体优化的关键,因此引入memcached分布式缓存来减轻数据库压力,它通过将从数据库中得到的查询结果缓存起来,来减少系统与DB 的访问连接频次,这样系统读取数据的时候如果命中就会从缓存中获取数据,来提高系统页面的展示速度,增强用户体验。

2 memcached简介

大部分应用系统都将数据存储到数据库管理系统RDMS中,应用服务从数据库中读取相应的数据并进行页面展示。但有时会由于数据库管理系统响应变慢、页面数据或者图片延迟展示等问题影响用户的访问体验,这是由于系统在一段时间内访问量的增长或者对页面中通用展示数据集中访问而导致的。

memcached经常被用来在动态互联网服务中缓解数据库的负载压力。它的主要原理是通过缓存第一次数据库查询结果,通过算法提高数据命中率,来减少和数据库之间的连接访问次数。memcached基于存储键/值对的hashmap,memcached 在启动时增加-d参数将其启动为后台运行进程即为守护进程,尽管它的守护进程是C 语言编写的,但是客户端程序只要支持memcached协议,不管使用何种语言都可以与之进行通信。

memcached 进程运行之后,会提前申请一块较大的内存空间由自己进行管理,用完之后再去申请,不是每次使用时都去向操作系统申请。所以如果分配足够大的内存空间给memcached的时候,基本上memcached的时间消耗就只剩下网络连接的时间了。

图1 memcached使用方式

2.1 memcached的特征

memcached作为一个高效的分布式缓存,它是由自己向服务器申请一块内存,对存储的Hash-Table内容进行有效管理。服务器的内存使用一般仅限于自身使用,不能进行共享,而memcached的出现解决了此问题,允许多个用户同时进行访问,并且同时使用,而且也不会发生在与数据库进行连接访问的时候因磁盘读写消耗资源较多导致进程阻塞的情况。它主要有以下几大特点。

(1)基于文本行的通信协议:memcached的内容管理采用的是简单的、便于操作的、基于文本行的协议,即使通过远程登录也能对缓存内容数据进行读取。

(2)基于libevent库的处理:libevent是一个事件通知程序库,它将Linux的许多事件处理功能封装起来进行统一调用,而且在多线程方面有很好的性能。memcached基于此库可以高效地运行在多种类型的操作系统OS上。

(3)预申请内存的方式:memcached会提前申请较大的内存空间供自己使用,常用的数据都会被存放在申请的空间中,并且会基于某些算法(例如:LRU 即最近最少使用算法)自动移除不经常使用的缓存数据,腾出空间给需要缓存的数据,并且它也会随着memcached或者操作系统的重启全部消失。

(4)独立的分布式缓存:memcached的缓存是一种通过客户端程序来实现的分布式缓存,它们独立工作,多个memcached 不会互相通信来共享信息,亦不会相互干扰,解决了共享内存只能单机应用的局限。

(5)支持多种语言的客户端:许多语言都实现了memcached的客户端,仅memcached网站上列出的语言就有Perl、PHP、Python、Ruby、C#、C/C++、java等。

2.2 memcached的使用场景

memcached的内存缓存用于在系统中提升系统的响应速度。它的主要应用场景如下:

(1)由于memcached缓存是基于分布式的,相对来说比较适合分布式服务系统。

(2)独立于应用:web应用系统响应慢的重要瓶颈是数据库的高并发,和其他的缓存机制例如java的Hibernate缓存机制比较,Hibernate是和应用程序本身的耦合性比较高,不像memcached是基于分布式的、独立于应用系统的。

(3)不同服务系统间信息互通:两个不同的应用服务系统信息需要同步,这时候就可以使用memcached了,其中一个系统将需要共享的信息进行memcached缓存,另一个系统服务就可以通过memcached获得共享的信息,就像获取本地信息一样方便。

如果使用memcached后不仅不会带来任何便利之处,相反还会拖慢整个系统,因为网络连接同样需要消耗资源,那么这时候就不适合使用memcached。不适合使用memcached的主要业务:

(1)数据对象占用较大空间:由于memcached存储信息在内存中,空间有限因此不适合那些较大数据块的存储。

(2)应用服务运行在内存不受控制的服务器上:memcached需要申请和控制大块的内存供自己调配,如果memcached管理的内存被其它服务占用或者丢失,memcached的缓存命中率将会大大降低,性能也会随之下降。

(3)没有安全策略的应用中:如果没有安全保障,memcached缓存的数据就很容易被不适当的进程获取,memcached本身并未提供任何安全策略以及安全管理机制,因此需要对服务本身以及运行环境考虑增强安全策略。

(4)需要存储的是持久化数据:由于memcached本身是为缓存而设计的服务器,因此它的数据是有时效的,在缓存数据量达到一定的值后,就会根据某些特定的算法移除部分缓存数据,并不适合永久性数据的存储情况。

2.3 memcached和服务器的local cache对比

本地缓存local cache顾名思义就是应用服务器本身的缓存空间,它能够利用的内存容量受到服务器空闲内存空间的限制,memcached则不会,不过local cache不但可以存储任意的数据,而且没有网络存取的延迟,在这一点上有其独特的优势。

(1)本地缓存数据查询速度更优:可以把页面中使用非常频繁的或者访问次数最多的数据放在本地缓存中,这样每次加载数据时就可以实现查询的秒级响应,没有网络延迟。

(2)本地缓存不会自动更新失效数据:在memcached集群中,对key-value的修改删除会通过某种方式同时通知所有的客户端获取此数据的变更。这一点本地缓存方式劣势明显,它需要刷新服务器数据,效率很慢。

(3)本地缓存受限于本地服务器的空闲内存大小。

2.4 memcached集群

由于memcached 之间不进行任何数据复制备份,本身也没有内置分布式功能,并且服务器与服务器之间没有任何通信都是相互独立的,因此memcached本身是没有任何策略维持失效转发的,所以当任何服务器节点出现故障时,可能会导致获取不到有效数据,所以我们可以利用magent 将memcache做成集群方式来避免出现单点故障,实现多台memcached缓存服务器的高效管理。

magent是一款比较常用的memcached代理服务器,从图2 可以看到有两个magent节点,每个magent节点又分别连接memcached节点,magent下memcached有主备的区别,memcache主节点可以有多台机器,它分散存储所有缓存的键值数据,备节点则存储了一个完整的键值数据。magent有效地解决了memcached的不能节点分布式问题,如果其中一台缓存服务器宕掉,系统依然可以继续工作,magent依然可以读取到数据,这样数据就不会丢失并且可以保证数据的完整性。特别需要注意的是,memcached重启后缓存数据会被清空,这时尽管备份的memcached还有数据,magent取得的仍可能会是空值,可采用定时维护服务器,来同步恢复memcached缓存数据。

图2 memcached与magent的混合模型

magent和每个memcached服务器之间保持着长连接的连接方式,这样可以减少创建连接、销毁连接的资源消耗。它和memcached 一样,基于libevent的事件程序库来处理IO 读写请求,并且支持memcached的许多通信协议指令,来实现系统请求的转发。

3 memcached性能比较测试

3.1 memcached客户端分布式原理

memcached的主要原理是通过在预先申请到的内存中维护一张hashtable来存储各种格式的数据,比如图片、数字、文本以及从数据库中查询到的结果数据等。memcached缓存是存储了很多 〈key,value〉键值对的表,通过两段哈希算法可以存储或查询任意的数据。客户端程序实现了memcached的分布式,它把数据使用一定的算法存储在不同的memcached缓存服务器里,不同服务器存储的数据不同,当用户需要使用此数据时,程序会首先使用内置算法计算出(key)的哈希值即阶段一哈希,找到一个服务器节点并将数据请求发送给此节点,此节点再通过一次哈希即阶段二哈希,这时才查找到最后需要的数据 (value)。各种语言的客户端实现的哈希算法是不同的,因此在缓存服务器中数据的存储方式也是不尽相同的。

假设有客户端client,memcached服务器A、B、C。应用程序要保存〈“key1”,“11”〉,〈“key2”,“22”〉的数据:client首先根据某种算法计算出键“key1”的哈希值,假设选中了服务器A,然后client会与服务器A 连接,把数据“11”存储到键“key1”的value中去。同样 〈“key2”,“22”〉也通过哈希算法选择相应的缓存服务器进行数据存储。接下来我们要访问数据,获取时也要将键“key1”的hash值传递给函数库,然后使用与存储“key1”时相同的哈希算法 (哈希算法相同,就可以保证两次选中同一台服务器),计算出“key1”在服务器A上,然后发送get 指令,就可以获得value 数据“11”。只要缓存的数据没有因为故障、超时等某些原因被服务器移除,就能获得之前存储的value,如图3所示。

图3 memcached存取数据示意图

如果memcached服务器数量比较多,不同的数据value就会被分配到不同的服务器上进行存储,这就实现了memcached的缓存数据分散存储即分布式的功能,而且即使其中一台服务器因故障无法被连接,也不会影响其他服务器的正常运行,因为它们都是各自独立处理不会相互干扰,在逻辑层面用户是感觉不到故障的发生的,因此被认为是正常运行的。

3.2 对比实例

在了解memcached 的原理之后,为了验证memcached的有效性,本文采用3000 多部影片基础信息作为测试对象,比较从数据库中查询数据和从memcached中查询符合条件的20条数据的性能。一部影片的基本信息包括影片名称、许可证号、出品年代、导演、主演、编剧、英文名称、制片人、时长、题材、影片类型、国家/地区、出品单位、摄制单位、影片简介等。

在对比测试前做好一些准备工作,首先安装memcached服务器端,要先安装libevent库,如果系统已有此库,可跳过。本次实验采用的是centos操作系统,因此使用yum install memcached进行安装,安装完成后操作目录为/usr/bin/memcached,并成功启动该服务。

本文采用的语言为java,因此采用memcached的java客户端xmemcached 版本2.0.0 进行测试,对于memcached的所有java客户端之间的对比可以参考下一节内容。表1为单线程的情况下查询10次的平均值的对比测试结果。

表1 从数据库中和memcached中查询数据的性能对比结果

从表1和表2可以看到memcached存取数据的时间明显比数据库中直接查询有很大的提升,尤其是线程数越多越明显。当数据库的连接数目超过一定的值后会造成数据库的崩溃,因此memcached对于缓解数据库的压力有很好的帮助。

表2 不同线程数情况下响应时间结果比较

尽管系统使用memcached后性能有了很大的提升,但毕竟它只是缓存,这时如果数据发生变化,我们可以有两种方式进行处理:一是对缓存和数据库的数据同时进行更新,二是对缓存的数据进行直接移除或者删除,等下次访问的时候再进行处理,这样就可以避免读取到脏数据,造成系统数据展示不正确。因为写操作总是要重新进行缓存处理,消耗大量的资源占用带宽,因此缓存是不适合有大量写和更新操作的数据应用场景的。

3.3 java 客户端xmemcached 和javamemcached-client比较

memcachedClient:该客户端基于传统的I/O阻塞模型,在高并发的时候比较容易报内存溢出的异常。

xmemcached:它的性能和稳定性比较高,可以作为首选。它基于Java NIO,和传统I/O 阻塞模型对比,它的优势比较明显即效率高、资源耗费少,已经被越来越多地应用到大型应用服务中,成为解决高并发与大量连接、I/O 处理问题的有效方式。NIO 是一种同步非阻塞的I/O 模型,也是I/O 多路复用的基础,只需要创建和维护一个连接 (当然NIO 也可以做池化处理),这样便省去了线程创建和切换的资源消耗,在并发量比较多的用户连接下有着非常突出的表现。

4 总结

当今社会需要提供实时的动态页面和信息,针对数据库高并发的读写需求,如果使用传统的直连数据库模式,并发负载明显偏高容易造成数据库死锁或者宕机。本文对memcached进行了简要的介绍,在3000多部影片基础信息数据的基础上做了不同的对比,从对比结果来看,memcached在性能上的优异很明显,并且还可以和magent实现memcached集群,来解决服务器节点单点故障的问题。但是它也有本身的弱点,memcached对内部存储的缓存数据同等对待,并没有进一步来区分数据,比如访问频次多的数据可以更容易被查询等,因此需要进一步的优化,可以从命中率、空间利用率、安全性能等许多方面对此进行考虑,还需要进一步的探索研究。