1、前言

这事情还得从两天前说起...

1.1 服务链路

话说迭代上了个接口，该接口横跨多个应用服务，链路如下图所示：

1.2 问题定位

问题来了：通过 skywalking，我们的监控到 dev 环境的该接口偶尔请求耗时很长，且抛异常了：

1.3 初步方案

接口 503 的报错原因查明：

1、外部系统 D 应用接口响应慢，导致上游 C 服务的接口超时；

2、上游服务 C 最终做了降级处理，返回了空串内容给 B 服务；

3、B 服务最终抛了 NPE，导致最终接口 500；

因此我们也定下了解决目标：

1、提供多级缓存来实现 API 加速优化

2、降级服务处理要做好一点，确保缓存一致性

2、基于 Redis 和 Cos 的二级缓存

API 优化方案涉及了 COS 和 Redis。

2.1 Redis

Redis 自然不用过多介绍，这是缓存的主流中间件；基于内存的访问可以大大提高数据读取效率，这里也主要用于数据缓存。

2.2 Cos 对象存储

COS 对象存储（Cloud Object Storage，COS）是腾讯云提供的一种存储海量文件的分布式存储服务，具有高扩展性、低成本、可靠安全等优点；这里也是用于数据缓存。

基于 Redis 和 Cos 的二级缓存，如下图所示：

- Redis：提供基于内存的数据存储

- Cos：提供基于云的对象存储

- 远端数据源：跨集群的数据提供方

3、API 优化方案

基于 Redis 和 Cos 的二级缓存，API 的优化方案如下：

【1】优化后的读 API 流程图：

（1）优先从 redis 读

（2）redis 读不到，从 cos 读，写入 redis

（3）cos 读不到，从 sca 读

（4）写入 redis、写入 cos

【2】我们在 Redis 和 Cos 的缓存数据预处理上，采用了“存量预热”+“增量缓存”的策略：

（1）存量预热：目标存储到 COS

（2）增量缓存：参考【1】优化后的读 API 流程图

4、FAQ

Q1：存量预热为什么没有写入 Redis？

A1：有些同学问，为什么只有增量缓存时，数据才写入 Redis 呢；存量预热为什么没有写入 Redis？

从缓存穿透的角度看：只有主动读取 API 访问到的，该数据下次被访问的概率会更高，因此可以写入 Redis，以使得下次访问获得更快的性能。虽然提前写入 Redis 存量预热的数据，在访问量不大的情况下，会造成大量的缓存浪费；Redis 是非常宝贵的资源，虽然性能高但是价格昂贵，非必要不过渡使用它。

从缓存击穿的角度看：预热写入 Redis 的数据，都会配置 EXPIRE 生存时间，在高并发的情况下，同一批缓存有大概率一起过期失效，这将导致所有请求打到第三方系统 D 服务上。严重情况下，甚至出现缓存雪崩，导致下游服务过载重启，影响服务 SLA。

Q2：存量预热会有什么风险呢？

A2：在迁移数据过程中必然遇到问题，参考下面的“DB 告警和监控”这 Part。

Q3：COS 的使用手册有吗？

A3：参考文档（https://cloud.tencent.com/document/product/436/6222）

Q4：COS 的收费贵不？

A4：降本增效的背景下，我们开发资源很多时候受限于成本预算，下面我给出一部分的计费价格，大伙参考使用（1TB 的存储大小）。

Q5：COS 的 QPS 是多少？

A5：使用了云服务商的产品，自然要进行性能评估了，我参考了文档的内容，其实每个存储桶的读 QPS 是可以达到 30000 的，应该是可以满足大部分业务需求（https://cloud.tencent.com/document/product/436/14518）

其实，cos 存储成本并不高的，实际上的花费主要都是在流量上。

Q6：COS 的读取比第三方系统的 API 读取快很多吗？

A6：是的，COS 的读取在腾讯云内部会更加有网络保障；而第三方 API 接入相对来说，系统稳定性更加不可控。从最后的实现比对来看，COS 读取大都在 200ms 左右完成，大大优于第三方 API 的性能表现。

5、DB 告警和监控

在存量数据预热的过程里，我们选择业务低峰期执行迁移任务。

不出意外的出现了意外，云数据库很快给出了告警：CPU 使用率超过了 80%（虽然不会对线上业务造成影响，但着实惊出一身冷汗）。

这里给出几点启示：

（1）批量同步数据，千万要记住多线程执行小任务（减少出错概率互相影响）；

（2）留下足够的时间间隔，让 CPU 任务使用率在多线程下摊分，降低 CPU 瞬时负载。

6、总结

以上是我们的一次 API 优化总结，最后还是给出 2 点提示：

- 数据预热过程可能很慢，我们其实可以跟产品，一起沟通下，能否可以按小项目维度去进行灰度功能（让预热数据及时跟上灰度范围）

- 迁移过程会产生非常大的 DB 查询，建议业务低峰期执行预热操作

欢迎关注我的公众号：后台技术汇，🏆InfoQ 首批签约作者 & 最佳社区内容创作者 🏆 鹅厂后台开发，旨在分享原创技术知识，提升核心竞争力。我们一起进步