最近在做头条/快手/广点通 marketing api 的对接工作，现在有个需求，实时获取帐号的余额，然后交给下游各个系统处理，由于账号多+API 限速，请问什么样的缓存策略比较好
0x0208v0 · 2021-12-21 11:18:29 +08:00 · 1739 次点击这是一个创建于 847 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，头条 /快手 /广点通广告平台 提供了 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 给对应人员，通过这种方式就很难实现
目前非常头疼，感觉自己太菜，也不知道类似这种问题业界是怎么处理的，求各位帮忙
调用这些接口，传入 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 给对应人员，通过这种方式就很难实现
目前非常头疼，感觉自己太菜，也不知道类似这种问题业界是怎么处理的，求各位帮忙
第 1 条附言 · 2021-12-23 13:48:29 +08:00
谢谢各位的回答！目前该问题的解决方案是：
1. 准备用全局 ratelimiter 的方式，保证各个业务模块调用 API 是可控的
2. 和业务方说，实时性没办法保证，让他们接受现实
3. 后期需要一点点重构该业务，支持接入多个 token
1. 准备用全局 ratelimiter 的方式，保证各个业务模块调用 API 是可控的
2. 和业务方说，实时性没办法保证，让他们接受现实
3. 后期需要一点点重构该业务，支持接入多个 token
 |
1
damai0419 2021-12-21 12:34:02 +08:00
比较倾向 1 方法。
在项目中，再另外起一个线程，该线程专门用于请求 marketing api ，该线程每秒请求 9 个账户，下一秒再请求下轮的 9 个账户。 理论上，2000 个账户，大约 4 分钟左右可轮询完一遍余额。这个延时时间，业务方能接受么。。。。。 |
 |
2
Itoktsnhc 2021-12-21 12:51:46 +08:00
pull 的模式，需求速度>接口吐数据的速度，巧妇难为无米之炊。需要做的是明确需求
1. 一定是实时吗，或者调用的窗口能不能延长。 2. 找 api 提供方，看能不能给放松一些限制(多 token 模式) 3. 如果请求数据是一个周期性的过程(比如每天早 8 点报表) 可以考虑在周期前做请求(当然得看是不是数据有时间属性) 需求是硬性的话，2 应该是一种比较好方式，比如对 token 和账户做好分区(贴着限速的要求)，10 个 token 对应 2000 个账户。保证某一个分区内的 token 不会被限速。账户增加 token 也要随之增加 |
 |
3
wutiaowy 2021-12-21 13:05:13 +08:00  1
要是我的话， 会把 1 ，2 ，3 结合起来
|
 |
5
0x0208v0 OP @Itoktsnhc 把不同的账户划分在不同的 token 里面，这种方式确实可行。只不过实际情况比较复杂，多个 token 对应的账户很可能有重叠，比如账号 a, b, c, d ， 对应的 token 是 token1: a b token2: abc token3 acd token4 bd
。。。给我整不会了 |
 |
6
wolfie 2021-12-21 15:18:25 +08:00
相同业务，拿 1 做的。
旁边提示一个上一次获取数据时间（有时候用户问题导致 token 失效，长时间拉不下来） |
 |
7
gadfly3173 2021-12-21 15:34:11 +08:00
做过巨量千川的一些业务对接，字节这些接口自己内部也很容易出现网关超时，而且他们自己超时报错之后 qps 照样扣，所以实际上 qps 到不了 10 。。。
|
 |
8
Ehco1996 2021-12-21 15:39:09 +08:00
问头条要资金变动的后的 hook ，这种回调一般都是有的吧
|
 |
9
goofylp 2021-12-21 17:35:56 +08:00
当然最好的方案是平台方提供批量接口
|
 |
10
suchasplus 2021-12-21 18:21:55 +08:00 1
巨量不是有纵横么？ 不能批量获取？
要么 ratelimiter 要么让他们开发批量接口 还有就是 push 运营商务让媒体方给你提权， 你都几千个账户了，日耗不低了啊，或者反推你们的增长运营别特么新开那么多账户, 及时关停，多吐槽，很多事情纯技术搞不定的 |
Select Language