啊嘞！？

最近工作中遇到一个比较有趣的问题，在应用层中某个API针对同一参数查询返回的结果反复不定，大概过两分钟左右以后返回数据就稳定了。

问题只出在测试环境，在开发环境中完全不能重现。最开始分析认为是api的isolation level的问题，感觉是更新数据的事务遇到问题被回滚；而几乎应用层所有API的隔离级别被设为了read-uncommited。但是实际的测试和日志都表现为数据是被成功写入数据库了，并且读未提交理论上只能够读到一次脏数据，而不应该出现数据反复不定的情况。另，该应用不支持远程事务回滚。

不是数据库层面的问题，那么就应该是出在缓存上了，这又要遇到另一个疑问，假设是数据库缓存出错，那么每次读到的数据也都应该是缓存中的值，也应该是稳定的——除非存在多个缓存。后来对比开发环境和测试环境发现了区别，测试环境中的服务器有两个实例（开发环境只有一个），这样答案就有解了，从逻辑上来讲这两个服务器实例必然是对前面API查询的数据进行了不同的缓存。而后对持久层的配置文件的分析也证明了这一点，有人在hibernate配置中对某些持久化对象进行了缓存，TTL也正好是前面的120秒。

但是这种更新数据库后，hibernate难道不支持同步更新缓存吗？答案是可以的，程序员也可以在应用层端代码中对目的缓存进行强制清空，然而那不是违背了设置缓存的初衷么？并且，在分布式系统中这个就比较头疼，hibernate是不能够主动的去监视数据库变动的，也就是说，你调用服务器A上的API查询了数据后，就只有服务器A的hibernate缓存能够得到刷新。两台服务器就会出现两个结果，在生产环境更多的服务器的情况下，问题就变得更有趣了。当然，你也不能要求数据库系统去主动通知持久化层做刷新缓存的工作——哥不是干这个的。

好吧，hibernate的缓存本来就不是分布式缓存，常见的持久化技术也大多是针对单服务器的。这种情况下，就需要搭建另一个异步系统（例如JMS）在数据库更新的同时发消息通知到所有hibernate实例对应的应用系统，让他们自己去完成缓存的更新。公司的架构蛳们正在做分布式系统的二级缓存，很好奇他们的具体实现，后话。