最近在做头条/快手/广点通 marketing api 的对接工作，现在有个需求，实时获取帐号的余额，然后交给下游各个系统处理，由于账号多+API 限速，请问什么样的缓存策略比较好

[0x0208v0]

如题，头条 /快手 /广点通广告平台 提供了 marketing api 接口
调用这些接口，传入 access token 就能获得一些广告平台的功能
比如 “获取账户的实时余额”。


现在的情况是这样的，API 接口是有限速的，一秒最多调用 10 次
一个 access token 下面可能有几千个账号， 需要在规定时间内掉用 API 接口，拿到数据

比如 “每天早上 8 点，实时调用接口，1500 个账号需要在 1 分钟内拿到余额数据，把余额小于 200 的账户整理出来并发送给某人”

再比如 “每天下午 4 点，实时调用接口，1500 个账号需要在 1 分钟内拿到余额数据，对余额小于 5000 的账户充值 1000 元”


可以看到，按照这样的账户数量和接口限速，是达不到业务要求的
目前想到的解决方案有下面这么几个：

1. 全局统一维护一个数据表，里面存储实时的余额
这样能保证下游的功能随时获取当前余额，带来的问题是余额会有一定延迟，可能会漏掉数据，保证不了实时性，

2. 多申请几个 token,如果发现当前 token 被限速了，就换新的
这样相当于问题还是没有解决，依旧存在限速问题

3. 把业务逻辑换成移步的生产消费者模式，生产者随时调用 API 接口请求余额，
拿到数据发给订阅的下游。这样的方式能解决上述问题，但是相当于得改业务逻辑，
比如，每天早上 8 点把所有余额小于 200 的账户整理，发送 email 给对应人员，通过这种方式就很难实现

目前非常头疼，感觉自己太菜，也不知道类似这种问题业界是怎么处理的，求各位帮忙

[damai0419]

比较倾向 1 方法。
在项目中，再另外起一个线程，该线程专门用于请求 marketing api ，该线程每秒请求 9 个账户，下一秒再请求下轮的 9 个账户。
理论上，2000 个账户，大约 4 分钟左右可轮询完一遍余额。这个延时时间，业务方能接受么。。。。。

[Itoktsnhc]

pull 的模式，需求速度>接口吐数据的速度，巧妇难为无米之炊。需要做的是明确需求
1. 一定是实时吗，或者调用的窗口能不能延长。
2. 找 api 提供方，看能不能给放松一些限制(多 token 模式)
3. 如果请求数据是一个周期性的过程(比如每天早 8 点报表) 可以考虑在周期前做请求(当然得看是不是数据有时间属性)

需求是硬性的话，2 应该是一种比较好方式，比如对 token 和账户做好分区(贴着限速的要求)，10 个 token 对应 2000 个账户。保证某一个分区内的 token 不会被限速。账户增加 token 也要随之增加

[wutiaowy]

要是我的话， 会把 1 ，2 ，3 结合起来

[0x0208v0]

@damai0419 问了一下接受不了 :(

[0x0208v0]

@Itoktsnhc 把不同的账户划分在不同的 token 里面，这种方式确实可行。只不过实际情况比较复杂，多个 token 对应的账户很可能有重叠，比如账号 a, b, c, d ， 对应的 token 是 token1: a b token2: abc token3 acd token4 bd
。。。给我整不会了

[wolfie]

相同业务，拿 1 做的。
旁边提示一个上一次获取数据时间（有时候用户问题导致 token 失效，长时间拉不下来）

[gadfly3173]

做过巨量千川的一些业务对接，字节这些接口自己内部也很容易出现网关超时，而且他们自己超时报错之后 qps 照样扣，所以实际上 qps 到不了 10 。。。

[Ehco1996]

问头条要资金变动的后的 hook ，这种回调一般都是有的吧

[goofylp]

当然最好的方案是平台方提供批量接口

[suchasplus]

巨量不是有纵横么？ 不能批量获取？
要么 ratelimiter
要么让他们开发批量接口
还有就是 push 运营商务让媒体方给你提权， 你都几千个账户了，日耗不低了啊，或者反推你们的增长运营别特么新开那么多账户, 及时关停，多吐槽，很多事情纯技术搞不定的