Redisson3.10 RCacheMap踩坑记录
- RMapCache实现了对map中每个key的淘汰机制eviction，是通过一系列org.redisson.EvictionScheduler来实现定期清理的，但是经测试，时效性不能保证，面向小批量任务 分钟级别的延迟也比较大 （eg：每个key10min过期，map共有20个任务，淘汰时延在10分钟之内，难道是我使用的姿势不对？）
- Redisson为所有实现了RMapCache或RLocalCachedMapCache接口的对象提供了监听以下事件的监听器： 当部署多个服务实例时，初始化RMapCache的监听器之后，其实是在每个实例上都绑定了这些监听器，当RMapCache发生变化时，多个实例均能捕获到变化，并执行对应监听器里的代码片段===》个人理解，类似于发布订阅模式 元素添加事件 | org.redisson.api.map.event.EntryCreatedListener 元素过期事件 | org.redisson.api.map.event.EntryExpiredListener 元素删除事件 | org.redisson.api.map.event.EntryRemovedListener 元素更新事件 | org.redisson.api.map.event.EntryUpdatedListener
- 使用fastPut修改RMapCache中已存在key的ttl时，令ttl=0不生效；但令ttl ！= 0 均可生效？ //key1不存在时，ttl=3s生效 map.fastPut("key1", new SomeObject(), 3, TimeUnit.SECONDS)； //key1存在时，令ttl=0，即永久保存key1，不生效 map.fastPut("key1", new SomeObject(), 0, TimeUnit.SECONDS)； 那多个实例下，如何维护分布式环境下RMapCache中竞争资源的竞争？如何保证多实例下只有一个监听器被触发执行？即使加上分布式锁，也无法保证。
下一篇：
SpringCloud系列--重点速学