一次核心业务的接口优化

背书包的老男孩

已于 2023-03-04 17:05:34 修改

阅读量85

点赞数

分类专栏：工作杂谈文章标签： redis 缓存性能优化 java Powered by 金山文档

于 2023-02-09 21:09:42 首次发布

本文链接：https://blog.csdn.net/weixin_42459814/article/details/128960326

版权

工作杂谈专栏收录该内容

8 篇文章 0 订阅

订阅专栏

注：记录开发，自己总结，随便写写，不喜勿喷。

问题描述

在近期的凌晨，第三方业务方由于活动等因素会对我们团队业务接口进行大量调用，造成流量的突增。接口的缓存依赖于Redis，热key的数据结构是Hash，由于流量的激增和凌晨key发生过期，导致该key中数据触发大量的写请求，进而出现线上的告警，表示相应的key获取不到数据，从而造成系统异常。

凌晨redis流量突刺

日志报错

该接口是基础服务的接口，每天调用量非常大，对于单集群，存在6台实例，一天接口调用量在4亿左右，单台实例的平均QPS在700左右，在一天流量请求量最大的时候，单台实例QPS在2500左右，平均耗时在6.7ms，另一个集群平均耗时在17.46ms

调用统计

问题分析

通过分析接口的调用链，发现该接口存在9次调用读redis的命令，结合接口的请求量，我们可以预估一天会有起码40亿次请求redis，这无形中加大了中间件团队的运维压力，因此减少调用的次数可以是我们进行优化的方向。

作为基础服务其中调用最频繁的接口之一，高可用低耗时是其必须具备的基本属性，但明显此时该接口并不完全满足这些条件，因此对于该接口的优化迫在眉睫。

接口的优化思路，可以分为业务逻辑优化和层级优化，分析过代码后，发现业务逻辑为顺序模型，不存在通过多线程并行执行来优化。因此只能从层级方面进行优化。

对调用链中触发的个层级进行具体分析，对redis的请求次数最多，涉及的具体key有6个。对于该接口涉及的业务进行分析，发现需要从redis获取的数据变更基本是以周为单位，即数据变化频率较低，业务场景对可用性要求较高，一致性要求较低，因此可以考虑采用本地缓存优化层级数量，减少redis请求。

问题解决

本地缓存采用Google团队开源的Guava，Guava是一款优秀的本地缓存中间件，具备以下特点：

1. 很好的封装了get、put操作，能够集成数据源。

2. 与ConcurrentMap相似，是线程安全的本地缓存。

3. 提供了三种基本的缓存回收方式：基于容量回收、定时回收和基于引用回收。满足各种场景的使用。

此接口涉及到的6个key中，有4个key的数据结构为Hash，因此设计相应的缓存数据结构为LoadingCache<String, Map<String, String>> ，在服务初始化的时候，向redis中读取相应数据，并在后台管理系统进行插入、更新、删除和定时任务刷新的时候，对本地缓存进行一次refresh。