问题背景
情景分析服务，老版本里会每次查询/翻页，均会重新请求一次。每次请求都会涉及到重新查询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，较能缓解重复查询的问题。
标签：02,缓存,huatai,56,27T15,Caffeine,ResourceServiceHandler,案例,faneDataService From： https://www.cnblogs.com/frankcui/p/17160592.html