生产环境ehcache迁移到集中式redis集群

  原先项目中使用的ehcache分布式缓存,缺点是浪费内存,并且ehcache使用的是jvm进程的内存,因此内存使用很受限制。

还有就是业务中有时希望更新一个业务实体来使对应的缓存失效的场景,这种情况下如果对应业务实体缓存有多台机子那更新实体后更新缓存只能是其中一台,无法全部更新。

  基于以上几点,项目希望切换成集中式缓存。

 集中式缓存服务端架构是:网易LBS+Twemproxy+redis集群。

 缓存客户端使用的是spring Data Redis。

 由于Twemproxy代理本身不支持multi操作,因此项目中覆写了RedisCache的put方法。

我们这边项目用dubbo切分治理服务后,希望每个服务之间定义的缓存也是独立的。因此我们这边通过覆写RedisCacheManager的getCache方法,引入group组的概念。

每个具体服务模块都有一个组名,如商品模块组名:ItemCenter。

这样保证了每个服务间缓存的独立性,不同模块可以使用相同的缓存名称。


监控部分,一个是监控redis这层和业务无关的,还有就是和具体业务方有关的数据监控。

我们这边开发了一个业务层的监控,用于列出所有的cache块,列出每个业务cache块名称及相应元素对象个数。

并提供了一个清除cache块的按钮,当程序有bug时能够及时清除恢复。


spring context 4.0.8.RELEASE版本的spring data redis有个bug,当redis缓存挂掉后,正常业务访问一个缓存方法,这时由于RedisCache在做访问操作时抛出了异常,但未捕获,因此会导致整个业务访问也跟着挂掉。

最新版4.1.3.RELEASE已修复。



 

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值