【贴代码】开发从贴代码开始！

『贴代码』

技术分享

精选作品

优选问答

成长笔记

登陆/注册

【本期话题】更多

                            我们在开发中经常遇到对方的接口请求有频率限制，比如当前接口每秒的请求不能大于100，不能大于1000，对于这样的，我们作为请求方，如何做限定？

相关推荐

话题列表

关于有QPS限制的接口的请求

我们在开发中经常遇到对方的接口请求有频率限制，比如当前接口每秒的请求不能大于100，不能大于1000，对于这样的，我们作为请求方，如何做限定？

尘埃

1.区分目标地址是按照什么时间单位计算的x/s x/min x/h /d是不一样的 2.然后按照分区建立缓存key,超过数量的，执行等待，或者重新放回队列中，这个要看时间差是多少 3.关键在于排重，然后是执行顺序，是否丢失数据等！具体的要看实际情况
每①天都是开始

不好搞，不好搞

重发机制

一般用于消息的通知

这一块在三方开发的时候比较常见，比如支付成功后，支付商推送通知给开发者，如果开发者没有按照要求返回特定信息，则支付商会按照规则继续执行多次推送，比如5s 1min 10min 30min 1h 4h 12h 24h等

延时队列的解决方案

有时候我们有个需求，比如在某个点再执行某些任务，这就涉及到延时任务的需求

比如订单的关闭，在客户建立订单后，我们就可以设定比如说1小时后，如果这个订单没有成交，则主动关闭他，如果有成交则移除这个任务！这里要考虑的是这个订单的数量有多少，然后是时效性，允许多少时间的误差？

长连接消息闪断的追补方案

有时候我们的方案需要使用到长连接，一般的是初始化的时候一次读取数据，比如读取需要获取的对象，或者最后一页数据，然后是链接长连接等待最新的数据下发，短线后重连...

有时候我们的方案需要使用到长连接，一般的是初始化的时候一次读取数据，比如读取需要获取的对象，或者最后一页数据，然后是链接长连接等待最新的数据下发，短线后重连,如果消息足够频繁，或者时间点刚好，就会发生消息错漏的问题，由此你有什么好的想法解决这个问题？

巷口酒肆

可以设定一个消息ID，主要是还有消息Label,那就是双key设定断层，重连后发送最后的id给服务端，服务端根据队列，补发其他的信息！
不曾罢休@

要看啥消息，有些消息要考虑断层问题，有些不需要，区分后再处理
底层的框架本身有队列机制的，比如你网络波动了，你在这个波动间发送了3条消息，网络好了后，这3条消息是会发送出去的！

第1页下一页

快捷注册

热门推荐更多

PasteBuilder

;