客户提供的短信接口没有批量发送短信的接口..目前是在循环里去直接 http 请求(根据返回状态判断短信是否发送成功).这样做肯定不行的.目前项目还未上线..所以还没有想到一个比较好的解决办法...使用 CompletableFuture 虽然不会阻塞...但是对面的 api 肯定会防止刷 api 限流...有老哥解决过类似需求吗?

这个。。。既要大量请求，又要防限流。。。。矛盾了。还是问问对面吧。

另外 CompletableFuture 提供的只是异步接口，但是 io 会不会阻塞主要看用的是 bio 还是 nio 还是 aio

换接口？

我开发经验不足.谢谢老哥回复解答.

额..我也想.客户提供的,没法改...

他们设计的接口有问题啊。

根据现在的情况，你只能开启多线程去调用然后 get 阻塞？？？这样子好难
应该他们回调你们接口，会好一点，，，这样子阻塞太难了，，建议他们改接口，他们的错误，我们不背锅

感谢老哥回复. 我以为会有排队请求 api 这种方案的...

延迟队列？

排队请求不久是队列吗

不行就自己维护队列呗

问清楚对面这个功能是不是要循环调用这个接口。是的话就这样调咯，有限流就卡着限制做呗，慢慢循环完就是了。他们不急你急啥，是吧
引入队列中间件 rocketmq 之类的？

DelayQueue?

你们的接口太辣鸡，就现在发广告的速度，大规模短信接口不是问题，经费没到位

先把请求接收进来，然后数据丢到 redis 里面慢慢处理。丢进去之前先看看 10 分钟以内有没有发送过，如果有就直接丢错给前端，如果没有，那就进队列慢慢排队。

用队列排队发送请求啊

我有批量的接口，但是只能相同内容

对方要针对 app id 和 IP 双重限流你玩出花儿也没效果， 而且你也没法保证对方不偷量啊

找对方商务谈再开个限制放开的接口啊

没得谈就再引入一个供应商

短信供应商遍地都是的。。。你偏偏吊死在一个连大量发短信都做不到的供应商上。。。

但是你这个肯定会限流的结论怎么得到的？是客户说的？还是你猜的？人家就不能收到一个请求，自己放自己队列里么。。。为啥会不行？我们连 aws 和阿里云发短信都是循环循环里面直接调 sdk ，同样是一条一条发的，他限不限流和你没关系，你要做的只是限流的时候你别崩溃和出现其他问题。你压根就不用考虑他会不会挂

可以了解下时间轮能不能满足你们的需求

感谢老哥回复.必须使用客户提供的(他们自己公司内部的短信接口)..这个是内部系统.没办法.要不然就上阿里云之类的了. 另外是客户自己的说的不支持.不然我也不会折腾了.

哪家短信供应商这么垃圾？我用的批量通知，接口参数本身就支持电话数组，短信供应方会合适处理。

换提供商啊，还能在一棵树上吊死

自己维护一个队列,简单点就把要发的短信存数据库.
根据对方的 API 的限流一条条发.超过限流了就等一会再发.

qps 很高的话个人认为可以做 mq ，请求的时候 http 做连接池等之类的优化~
ps: ＃19 说了半天是在说明“限流”相关的问题，您这＃21 为啥全程在解释为啥不能用阿里云…？

如果公司短信很多的话，就应该有使用多家短信服务，不然短信平台出问题了，短信相关的功能全挂了