项目场景:
- 在项目中使用基于内存(JVM)的缓存
- 缓存了每个用户的基本信息
- 用户的基本信息会同步到终端设备
问题描述:
- 发现同步到终端设备的数据与数据库的不一致。但是很奇怪的是其中一个属性值
小概率
被置为空了。在数据库中值是存在的。
原因分析:
1,论证数据库数据与缓存数据的一致性,这里的一致性是指,我在数据库看到的,和被缓存的数据是否相同。
因为不排除,在查询数据库并缓存时,ORM映射问题导致某个属性没被赋值,但是这种问题一般出现频率是高频的,而不会是偶发。但也不排除偶发概率,因为在属性映射时,假设映射的代码在处理数据时根据某种特定情况而导致返回空。
2,是否存在非数据库的数据源更新缓存。笔者就是走进了这个坑。
- 首先,我们使用的是内存缓存,当然这里的内存缓存应该理解为被缓存在JVM运行时中,这种缓存就是我们常说的
Ehcache
,和Redis不同是,Redis是单独的进程,而Ehcache是同一个进程 - 假设我们对用户A对象进行了缓存,在不销毁的情况下,无论在何时获取用户A对象,返回的都是指向同一个对象地址的指针。在这种模式下,某个线程执行时,经过了用户A对象缓存的获取,通过参数被传递,慢慢的就可能忘记它是缓存返回的。也就慢慢
不小心对这个缓存对象的某个属性进行了修改
,在其他线程使用时,由于内存地址都是一样的,所以这个缓存的属性已经被偷偷的修改了,已经和数据库的不一致了。在开发时,一个不注意,这个缓存就会被慢慢的污染,最终面目前非,导致莫名其妙的问题。
总结
- 在使用基于Ehcache、HashMap等在同一进程的缓存时,一定要注意,读出来的缓存不能被修改,这应该是规范。
- 某些情况我们会对读取的缓存数据进行加工、转换,但同时加工、转换的载体又放在了缓存对象本身,此时我们应该对缓存对象进行深拷贝。