在我们的应用中,有一张表的查询量非常之大,高峰期时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的功效