前言

开放平台流控需求分析

对于开放平台来说，有一个功能是必须要有的，那就是API的流控。

对于每一个接入开放平台的应用，都会分配一个Appkey，这个Appkey下面会关联你申请了哪些API。然后接入的API有些是不限量，可以一直调用。有些是需要申请调用包，比如一天10万次的调用量。

除了总量的限制，还有对频率的限制。比如每秒每个API调用频率的限制，每秒每个Appkey调用频率的限制。

要实现这些流控的功能，最好的方式就是已经有一个流量治理平台，里面提供了限流的功能。像开放平台这种还不属于普通的系统限流，有点偏业务限流了，因为有具体的数量指标。

技术选型

这也就是前面文章里面跟大家讲什么时候要自研，什么时候可以直接用开源。当需求无法满足，就只能自研了。

自研可以在开源的基础上开发，增加业务限流的功能，支持租户的功能，可以多租户接入。支持按Appkey时间内的总量限流，支持API时间内的数量限流。

如果没有现成的治理平台可以接入，那么就需要业务方自己进行开发。自己开发一般都会使用MySQL+Redis去实现。

实现原理

MySQL用于存储基本配置信息，比如Appkey对应的流控信息，API对应的流控信息。

Redis用于数量扣减提高性能使用，使用这个方案必然会带来一个数据一致性的问题，就是MySQL里的数据如何跟Redis保持一致。

为什么要用Redis?

假设不用Redis也就意味着每次调用后都需要更新MySQL里面的调用次数。在高并发的情况下，性能肯定是需要优先考虑的问题。

用Redis还是为了扛高并发，而且这个业务场景也不复杂，就一个计数而已，Redis本身也支持原子操作。

Redis只是用来辅助使用的，并不是作为业务数据的存储系统。所以这里就涉及到数据一致性的问题。

如何保持一致？

这里我们再思考下，是否需要强一致性？

不需要，而且这个场景也不好做。所以只需要保证最终一致即可。

对于计数信息，可以采取提前同步到Redis中，也可以采用延迟加载的方式。比如对某个Appkey下的某个API进行计数，key可以这样设计 Appkey:API ，过期时间就是你要限制的时间段，比如按天来限制。

这里需要有个定时同步Redis里面的计数信息到MySQL里面的任务，时间间隔可以自行设置。假设Redis没做持久化，重启后数据丢失，这个时候会从MySQL里面查出计数信息进行初始化，如果你同步间隔是10分钟一次，那么只会有这10分钟的调用次数丢失。

我认为对于一般开放平台来说，丢了一些计数信息没啥大问题，无非就是让三方多调用一些数量的接口。但是具体业务具体分析，如果你们的API是按次计费的，那么本方案可能不适合，涉及到钱的还是得强一致。

单机还是集群？

这个话题，前面的文章《流量治理神器-Sentinel的限流模式，选单机还是集群？》里面我们也聊到过。

那么在开放平台的这个业务场景下，毫无疑问的是要选择集群限流。首先它是一个业务场景的限流，有明确的限流指标，单机限流没有全局的存储，无法反馈本身的结果给其他服务，就会导致业务结果不正确。

大家好，我是从古代穿越过来的美男子：架构摆渡人。我将把我的武功秘籍全部传授与你们，觉得有用请分享给身边的朋友。来个三连吧，感谢各位！另外我还在B站录制了《真实订单业务，亿级数据带你实战分库分表》的实战课程，记得去学习哦！