Memcached笔记——（三）Memcached使用总结

最新推荐文章于 2023-12-09 23:39:00 发布

iteye_14356

最新推荐文章于 2023-12-09 23:39:00 发布

阅读量140

点赞数

文章标签： memcached 数据结构与算法 java

本文探讨了如何在使用Memcached时优化缓存策略，避免因唯一标识和对象体积过大导致的问题，包括重写代码以统一Key生成、使用Map或Set管理缓存数据、以及对大体积对象进行压缩。同时，介绍了如何利用一致性哈希算法提高Memcached服务器利用率，并提供了使用XMemcached的Java代码实现。最后，分享了通过调整缓存配置和优化SQL来解决缓存大小限制的方法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

为了将N个前端数据同步，通过Memcached完成数据打通，但带来了一些新问题：

使用iBatis整合了Memcached，iBatis针对每台server生成了唯一标识，导致同一份数据sql会产生不同的key，造成重复缓存。——通过重写iBatis部分原码，终止了唯一标识的生成，同一个SQL产生同一个Key，同时对生成key做hash，控制长度，使得数据统一在Memcached。
为了迎合iBatis的架构，通过CacheModel模式，对缓存数据分组管理。最初通过Map实现CacheModel，就是简单的Key对应最终的Object。为了后台操作数据时，前台能及时响应，以CacheModel为基准点。后台操作数据时，做Flush，清空对应的CacheModel，可以及时同步数据。但，由于前后台Domain对象可能不一致，调用CacheModel（Map）反序列化时，发生ClassNotFonudException（CNF）。——将CacheModel的Map实现改为Set，CacheModel仅存需要Flush掉的key，Object按原有方式缓存。
以前一直用EhCache，也很少会把List<List>这样的重量级对象放进缓存里。即便如此，只要EhCache没有抛异常，我们恐怕也无感知。这次改用Memcached，没有注意到缓存List过大，导致“Cannot cache data larger than 1MB memcached”，即缓存对象体积不能超过1MB——使用Memcached数据压缩，优化SQL，可以暂时维持。

说了这么多，简要总结如下：

Memcached的Key，要杜绝使用空格，且长度控制在250个字符。
Memcached的Value，要控制体积，必须小于1MB，必要时进行使用压缩。
失效时间，0为永久有效，最大值不得超过30天（2592000s），否则重新计算可能缓存只有1秒
Memcached仅支持LRU算法，完全适用你的需要。
尽量不要将List这种重体积对象扔到Memcached中，传输、存储都会产生瓶颈。
使用一致性哈希算法实现，提高多个Memcacehd Server利用率。

关于使用XMemcached实现时，参考如下实现：

     Java代码 
     
   
 privateMemcachedClientBuildercreateMemcachedClientBuilder( 
 Propertiesproperties){ 
 Stringaddresses=properties.getProperty(ADDRESSES).trim(); 
  
 if(logger.isInfoEnabled()){ 
 logger.info("ConfigureProperties:[addresses="+addresses+"]"); 
 } 
 MemcachedClientBuilderbuilder=newXMemcachedClientBuilder( 
 AddrUtil.getAddresses(addresses)); 
  
 //使用二进制文件 
 builder.setCommandFactory(newBinaryCommandFactory()); 
 //使用一致性哈希算法（ConsistentHashStrategy） 
 builder.setSessionLocator(newKetamaMemcachedSessionLocator()); 
 //使用序列化传输编码 
 builder.setTranscoder(newSerializingTranscoder()); 
 //进行数据压缩，大于1KB时进行压缩 
 builder.getTranscoder().setCompressionThreshold(1024); 
  
 returnbuilder; 
 } 