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

阅读目录(Content)

问题背景
问题分析
引入Caffeine原因
引入前后效果对比

回到顶部(go to top)

问题背景

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

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

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

回到顶部(go to top)

问题分析

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的原因。

回到顶部(go to top)