Memcache工作原理总结

 

转自：http://tank.blogs.tkiicpp.com/2010/12/14/memcache%e5%86%85%e5%ad%98%e5%88%86%e9%85%8d%e7%ad%96%e7%95%a5/

一、Memcache内存分配机制

        关于这个机制网上有很多解释的，我个人的总结如下。

1. Page为内存分配的最小单位。

   Memcached的内存分配以page为单位，默认情况下一个page是1M，可以通过-I参数在启动时指定。如果需要申请内存时，memcached会划分出一个新的page并分配给需要的slab区域。page一旦被分配在重启前不会被回收或者重新分配（page ressign已经从1.2.8版移除了） 
   

2. Slabs划分数据空间。

   Memcached并不是将所有大小的数据都放在一起的，而是预先将数据空间划分为一系列slabs，每个slab只负责一定范围内的数据存储。如下图，每个slab只存储大于其上一个slab的size并小于或者等于自己最大size的数据。例如：slab 3只存储大小介于137 到 224 bytes的数据。如果一个数据大小为230byte将被分配到slab 4中。从下图可以看出，每个slab负责的空间其实是不等的，memcached默认情况下下一个slab的最大值为前一个的1.25倍，这个可以通过修改-f参数来修改增长比例。 
   

3. Chunk才是存放缓存数据的单位。

   Chunk是一系列固定的内存空间，这个大小就是管理它的slab的最大存放大小。例如：slab 1的所有chunk都是104byte，而slab 4的所有chunk都是280byte。chunk是memcached实际存放缓存数据的地方，因为chunk的大小固定为slab能够存放的最大值，所以所有分配给当前slab的数据都可以被chunk存下。如果时间的数据大小小于chunk的大小，空余的空间将会被闲置，这个是为了防止内存碎片而设计的。例如下图，chunk size是224byte，而存储的数据只有200byte，剩下的24byte将被闲置。 
   

4. Slab的内存分配。

   Memcached在启动时通过-m指定最大使用内存，但是这个不会一启动就占用，是随着需要逐步分配给各slab的。
            如果一个新的缓存数据要被存放，memcached首先选择一个合适的slab，然后查看该slab是否还有空闲的chunk，如果有则直接存放进去；如果没有则要进行申请。slab申请内存时以page为单位，所以在放入第一个数据，无论大小为多少，都会有1M大小的page被分配给该slab。申请到page后，slab会将这个page的内存按chunk的大小进行切分，这样就变成了一个chunk的数组，在从这个chunk数组中选择一个用于存储数据。如下图，slab 1和slab 2都分配了一个page，并按各自的大小切分成chunk数组。 
   

5. Memcached内存分配策略。

   综合上面的介绍，memcached的内存分配策略就是：按slab需求分配page，各slab按需使用chunk存储。
   这里有几个特点要注意，

   1. Memcached分配出去的page不会被回收或者重新分配
   2. Memcached申请的内存不会被释放
   3. slab空闲的chunk不会借给任何其他slab使用

   

 

      知道了这些以后，就可以理解为什么总内存没有被全部占用的情况下，memcached却出现了丢失缓存数据的问题了。

在缓存的清除方面，memcache是不释放已分配内存。当已分配的内存所在的记录失效后，这段以往的内存空间，memcache自然会重复利用起来。至于过期的方式，也是采取get到此段内存数据的时候采取查询时间戳，看是否已经超时失效。基本不会有其他线程干预数据的生命周期。至于清空的策略等同于ehcache的默认策略——最近很少使用清空策略——也就是英文常用的LRU——Least Recently Used。

 

而memcache鉴定内存不足是在什么情况下呢：无法从slab里面获取新的存储单元了。这个对内存十分贪婪的东东。基本服务器都得是2~4GB以上方能吃得消（非时效性，或者说时效性较低的数据）。

 

Memcache借助了操作系统的libevent工具做高效的读写。libevent是个程序库，它将Linux的epoll、BSD类操作系统的kqueue等事件处理功能封装成统一的接口。即使对服务器的连接数增加，也能发挥高性能。memcached使用这个libevent库，因此能在Linux、BSD、Solaris等操作系统上发挥其高性能。Memcache号称可以接受任意数量的连接请求。事实真的是这样吗？

 

存储过程分析

假设我们现在往memcache中存储一个缓存记录，首先在使用memcache客户端程序的时候要制定一个初始化的服务机器路由表

ry {
			MemcachedClientBuilder builder = new XMemcachedClientBuilder(
					AddrUtil.getAddresses(this.hosts));
			builder.setConnectionPoolSize(this.connPoolSize);//每个缓存节点连接池大小
			builder.setFailureMode(this.failuerMod);//是否使用failuerMod
			if (this.conhash) {//采用多种hash算法中的一种
				builder.setSessionLocator(new KetamaMemcachedSessionLocator());//使用一致性hash,取决于conhash的配置
			}
			builder.setConnectTimeout(this.connTimeOut);//连接缓存服务器超时时间
			builder.setOpTimeout(this.opTimeOut);//操作缓存超时时间
			this.client = builder.build();
                        if (!this.client.isShutdown()) {
			    Object res = this.client.set(key, timeout,value);
			}
		
		} catch (Exception e) {
			throw new IllegalArgumentException("缓存参数配置不正确!");
		}

引用xmemcached-1.4.1.jar

那么在做存储的时候 memcache 客户端程序会 hash 出一个码，之后再根据路由表去将请求转发给 memcache 服务端，也就是说 memcache 的客户端程序相当于做了一个类似负载均衡的功能。

 

 

而memcache在server上面的进程仅仅负责监听服务和接受请求、存储数据的作用。分发不归他管。所以这么看的话，散列到每台memcache服务机器，让每台机器分布存储得均匀是客户端代码实现的一个难点。这个时侯Hash散列算法就显得格外重要了吧。

 

   读取过程分析

 

理解了memcache的存储就不难理解memcache的读取缓存的过程了。在读取的时候也是根据key算出一个hash，之后在算出指定的路由物理机位置，再将请求分发到服务机上。

memcache分布式读写的存储方式有利有弊。如果node2宕机了，那么node2的缓存数据就没了，那么还得先从数据库load出来数据，重新根据路由表（此时只有node1和node3），重新请求到一个缓存物理机上，在写到重定向的缓存机器中。灾难恢复已经实现得较为完备。弊端就是维护这么一个高可用缓存，成本有点儿大了。为了存储更多的数据，这样做是否利大于弊，还是得看具体的应用场景再定。

 

     与ehcache的争论

 

Ehcache的争论之前就说过了，总是在性能上来说这两个的性能如何。还有大家在网上常见的一个列表进行了比较。笔者觉得，这两个最大的差异是原理的差异决定了应用场景的差异。比如做单点应用缓存的时候，就可以使用ehcache直接向本地内存进行缓存的读写。而做集群缓存的时候一般是借由一个集中式管理server来做缓存，既然是集中式server就少不了网络传输了，这个时侯memcache较为适合。不是说ehcache不能做集群式的缓存，而是做了集群的缓存的代价（RMI、JMS、JGroups）、网络资源的占用确实比memcache高一些。至于内存的读写操作效率，这个不太好说。Ehcache用java的随机读写类操作二进制的buffer。Memcache底层是基于libevent程序库的C服务。这个相信效率都差不多。关键的消耗还是在网络IO资源上。