Memcached使用点滴

  我对于Memcached的接触,还是在去年看了CSDN的一系列国外大型网站架构设计而开始的。最初的时候只是简单的封装了Memcached Java版的客户端,主要是对于配置的简化以及Memcached多点备份作了一些工作,然后就作为ASF的组件一部分提供给其他Team使用。其实看过Memcached Java客户端代码的人就会了解其实客户端的事情很简单,就是要有一套高性能的Socket通信框架以及对Memcached的私有协议实现的接口,自己去做这些事情也是很简单的,不过既然有可以满足自己需求的开源部分,那么就去实现自己需要的但没有实现的。这里我用的是Whalin的客户端版本,这里为什么还要提出来讲这个,后面会提到。

       在对Java客户端作了简单封装和扩展以后,由于其他Team使用的没有什么特殊需求,也就没有再去做太多的修改,直到最近自己的服务集成平台需要做服务访问控制,才重新丰富了Cache组件,也就是这个过程中对于Memcached的一些特性和小的细节有了一些新的认识。

       作为服务集成平台需要对服务有所监控,包括访问频率控制以及访问次数控制。频率控制其实很类似于硬件方面的频率控制,例如硬件可以对IP的高频率访问视为攻击,列入黑名单。而作为服务的访问,对于服务访问者的控制其实涉及到了业务参数,那么硬件就不是很适合去做这方面的控制,为此我也考虑了很久,最开始打算在Apache上做一个模块控制,但是最后觉得还是放在后面的业务框架上做这件事情。当然后面我说说的方案可能并不好,但是也算是一种想法。要把频繁的访问数据记录下来同时分析,那么数据库肯定是不行的,最简单的方式就是采用Cache,又因为是集群范围内的控制,那么集中式Cache就非Memcached莫数了(分布式的Cache传播本身损耗太大,集中式Cache本来的最大缺点就是单点,但作简单的备份操作就可以基本解决此类问题)。

       作为解决这个问题的方法来说只需要实现两部分工作:访问计数器,定时任务。定时任务在我做日志分析框架的时候都是采用了Jdk5Concurrent包里面的ScheduledExecutorService,这个作简单的循环任务足够用了,同时也是有很好的多线程异步支持,复杂一点么用Quartz。计数器就要靠Memcached来实现了,本来一般的Cache最大的问题就是高并发下的事务保证,如果采用Get+Set来完成计数的话,那么高并发下计数器就会出现读写不一致性的问题,幸好Memcached提供了计数累加功能,让这种累加动作能够在服务端一次做好,服务端控制并发写入,保证数据的一致性。

下面就看看以下几个方法:

boolean storeCounter(String key, long count)存储key的计数器,值为count

long getCounter(String key):获取key的计数器,如果不存在返回-1

long addOrDecr(String key, long decr):计数器值减去decr,如果计数器不存在,保存decr作为计数器值

long addOrIncr(String key, long inc):计数器值增加inc,如果计数器不存在,保存inc作为计数器值

long decr(String key, long decr):与addOrDecr不同的是在计数器不存在的时候不保存任何值,返回-1

long incr(String key, long inc) :与addOrIncr不同的是在计数器不存在的时候不保存任何值,返回-1

这里需要说明几点:

storeCounter和普通的set方法不同,如果通过set方式置入key:value的话,getCounter等其他四个方法都认为技术器不存在。所以Counter存储方式是和普通内容存储不同的。

在不同的场景要慎用addOrXXXXXXXX的方法,两者还是有比较大的区别的。

计数器没有提供移除特殊方法,使用delete方法可以移除计数器,但是频繁的deleteaddOrXXXX有时候会出现一些奇怪的问题(例如同名的计数器就没有办法再次被创建,不过这个还需要进一步的去研究一下看看)。一般情况下如果计数器的key不是很多,同时也会被复用,那么可以通过置为0或者减去已经分析过的数量来复位。

       有上面的一套计数器机制就可以很方便的实现Memcached的计数功能,但是又一个问题出现了,如何让定时任务去遍历计数器,分析计数器是否到了阀值,触发创建黑名单记录的工作。早先我同事希望我能够提供封装好的keySet接口,但是我自己觉得其实作为Cache来说简单就是最重要的,Cache不需要去遍历。首先使用Cache的角色就应该知道Key,然后去Cache里面找,找不到就去后台例如DB里面去搜索,然后将搜索的结果在考虑更新到Cache里面,这样才是最高效并且最可靠的,Cache靠不住阿,随时都可能会丢失或者崩溃,因此作为类似于一级缓存或者这类数据完整性要求不高,性能要求很高的场景使用最合适。当时就没有提供这样的接口,直到今天自己需要了,才考虑如何去做这件事情。

       开始考虑是否能够将key都记录在另外的Cache中或者是Memcached中,首先在高并发下更新操作就是一大问题,再者Memcached的内存分配回收机制以及Value的大小限制都不能满足这样的需求,如果使用数据库,那么频繁更新操作势必不可行,采用异步缓存刷新又有一个时间间隔期,同时更新也不是很方便。最后考虑如果能够让Memcached实现Keyset那么就是最好的解决方案,网上搜索了一下,找到一种策略,然后自己优化了一下,优化后的代码如下:

Code

NET技术Memcached使用点滴,转载需保留来源!

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。