缓存小技巧--NullObject模式&&表识cache

在我们的应用中，有一张表的查询量非常之大，高峰期时6000次/second查询，而且更新很少，于是我们的改造来了：

 

第一次优化：

方法：每次从cache中读取，如果cache中没有命中，则从DB读取，如果有值将此值放入cache中。

效果：上线后效果并不是特别明显，高峰期仍有3000次/second的查询，原因在哪里呢？此表只有700w的数据量，但是对于3亿用户，每个用户都要查询此表，就是说，只有700w/3亿=2.33%可以命中cache，间接导致每次从cache中取数据为空后，仍有97.67%的数据仍然会查询DB。

 

第二次优化：

方法：每次从DB中查询后，如果是空，则在cache中放入一个NullObject，用于区分null的数据。如果结果是NullObject或者此表的对象模型，则直接从cache中返回，不再从db中查询。

效果：这次优化后，相信可以减少对宝贵的db资源大量的浪费。

 

第三次优化：

方法：有一个背景，我们的3亿用户基于读多写的业务已经放入分布式cache，我们可以将业务看做是是用户的一个属性（一个假设的例子：网银的硬key），可以把此业务和客户模型绑定在一起，即在用户的客户模型表中增加一个字段，每次查询客户模型时，即将此字段查询出来；如果此属性有值，外围系统可以在第二步的基础上，继续查询具体表的缓存去完成自己的业务。

效果：客户模型的表识cache+具体业务的cache，即可以避免大部分业务二次查询的问题；又充分利用了cache的功效