Caffeine - 实际案例：为什么要引入Caffeine本地缓存

问题背景

情景分析服务，老版本里会每次查询/翻页，均会重新请求一次。每次请求都会涉及到重新查询permission的工作。

permission信息，是scenarioService通过grpc调用faneDataService获得的。

然而发现，每次请求都很慢，大约6s。通过arthas发现,就是grpc请求那一步，消耗了98%的耗时导致的。

 

 

 

问题分析

scenario发送grpc请求的log:

 

 

faneDataService接收到grpc请求的log：

2023-02-27T15:56:25,765 [ForkJoinPool.commonPool-worker-6] INFO  com.huatai.quant.handler.ResourceServiceHandler - 收到resource查询请求: requestId: "xbridge-1-62178@168-63-70-238"2023-02-27T15:56:25,765 [ForkJoinPool.commonPool-worker-6] INFO  com.huatai.quant.handler.ResourceServiceHandler - 收到resource查询请求: requestId: "xbridge-1-62178@168-63-70-238"resourceType: "R_SCENARIO_DEF"appName: "ScenarioService"operateUserId: "xtryaozhongbing"

2023-02-27T15:56:25,810 [ForkJoinPool.commonPool-worker-6] INFO  com.huatai.quant.handler.ResourceServiceHandler - 完成对[ScenarioService,R_SCENARIO_DEF]资源节点原始数据查询：3938

2023-02-27T15:56:28,576 [ForkJoinPool.commonPool-worker-6] INFO  com.huatai.quant.handler.ResourceServiceHandler - 完成资源数据权限校验：权限校验后资源树列表: 39502023-02-27T15:56:28,576 [ForkJoinPool.commonPool-worker-6] INFO  com.huatai.quant.handler.ResourceServiceHandler - 生成resource查询响应: 39502023-02-27T15:56:28,577 [ForkJoinPool.commonPool-worker-6] INFO  com.huatai.quant.handler.ResourceServiceHandler - 调用grpc获取完整资源树：3950

 

详细解释：

• 根据上方scenarioService截图：情景服务发起grpc调用faneDataService时间为：2023-02-27T15:56:24,810 
• 根据上方faneDataService log：faneDataService收到请求的时间为：2023-02-27T15:56:25,765，网络损耗大约1s
• faneDataService自身运行大约 3s（中间还牵扯到faneDataService调用其他服务）
• faneDataService将响应返回给情景分析服务，网络预计损耗大约1s

大约能够解释耗时6s的原因。

 

引入Caffeine原因

由于scenarioService和faneDataService本身自己的逻辑处理，耗时都在预期之内。

叠加两个服务间通讯损耗也有2s,占比33%。

因此自身能控制的方面，调优范围较小。

 

因此引入本地缓存——caffeine，较能缓解重复查询的问题。

 

 

引入前后效果对比

 

引入后：0.026s

 

 

引入前：6.392s