1、技术前提:现需要提供一个查询商品标签的RPC接口(响应时间50ms以内,2W+QPS);数据已分库分表(8库65表);
2、业务特性:商品标签最多一天变更一次;大部分查询请求是不会命中标签的;
3、解决思路:需要缓存的帮助,全部打到db上是不现实的。
1)商品标签值不常变,缓存时间可以长一些(一小时),数据量较大,考虑使用redis缓存;
2)如果这个商品有秒杀等活动,经常被访问,考虑使用本地缓存。
3)缓存内容:缓存所有命中标签的商品,大部分商品是不会命中标签的,且数据量压力过大,不是首选;缓存商品查询结果,方案较为合理,采用试试。
4、最终解决方案:本地guava缓存(解决秒杀等热点商品查询问题) + redis缓存(缓存查询结果,减轻数据库压力)+ db查询;这样最坏的情况是一个小时内同一个商品只会查询一次数据库,db压力大大减轻;
5、细节优化:
1)预发环境发现查询接口有时会存在300多ms的查询延迟,经检查属于redis、db、leo首次连接问题。 解决方法:在项目启动时,进行redis和db等资源预热。
2)资源预热后存在60ms以上的查询延迟,经检查属于db查询问题,预发多次验证,业务代码无法再进行优化,找中间件技术人员协助排查问题,经检查属于db建立连接耗时过久。 解决方法:开启db连接池预热,db操作耗时降为10ms以内,整个接口max耗时15ms左右。