解决亚马逊调用频率限制问题的sdk框架

先给急着用的人:项目地址:https://github.com/zhuzhenke/invoke-limit-api

针对调用亚马逊AWS服务,对于亚马逊针对每个接口有不同的频率调用限制,设计了这个对调用者可以同步和异步调用的sdk框架,把因为频率限制的错误进行重试的封装,调用调用者处理因频率限制出现的错误。

这里主要基于xMemcachedClient开源项目的一些设计优点,结合现有业务难点设计的基于线程池封装的sdk。



amazonRequest是一个正常的亚马逊请求,这个请求如果不走上面的框架调用,在一定时间内超过亚马逊AWS关于当前API调用量的话,就会报Request is throttled之类的异常,那么对于一个部门来说,如果是多个项目都会调用接口,且没有统一合理控制的话,那么这种情况肯定是会经常发生的。下面详细讲,如果使用上图的架构设计,解决这样的问题。

首先我们建立了一个频率统一控制中心的项目,这个跟sdk封装是没有关系的,但是sdk在真正发出请求时,需要对于amazonRequest,需要获取当前请求的执行时间,有可能是马上就能执行,有可能是还需要等几秒才能执行,因为可能是其他业务线的请求先来了好几个,占用了这个用户的这个请求。获取到amazonRequest的执行时间,封装成RequestCommand,同时用CountDownLatch来控制同步和异步调用,对于同步调用,一开始放入请求队列时,request则用CountDownLatch.await(),等待线程池使用该请求完成亚马逊API的调用后,调用CountDownLatch.countDown(),是当前客户端的request调用返回,得到相应的amazonResponse。而对于异步调用,得到执行时间且封装成RequestCommand,放入到队列则完成调用,其余事情交给线程池处理。线程池调用异步请求完成后,会进行一个InvokeCallBack的回调,将相应结果、异常信息和上下文信息返回。

那么,对于调用过程中,出现的异常情况,如调用超频率,那么则从ExceptionReInvokeProcessor会将异常信息进行分析,看是否需要重新调用,对于子类实现needReInvoke(Exception e)则可以,如果需要重新调用,那么就重新放到请求队列中,让线程池继续原有工作。


至此,sdk的框架图解释得差不多了,也比较简单易懂。上图中还有一点是比较关键的,就是“频率统一控制中心”。这个频率统一控制中心需要维护好每个用户每个请求的频率、上次调用时间,由此得到即将到来的request的执行时间,这里也比较简单,不做太多解释了。对于亚马逊的接口频率问题,要具体看是哪个请求,这里放其中一个链接出来,AWS上面写得也比较清楚。http://docs.developer.amazonservices.com/zh_CN/feeds/Feeds_SubmitFeed.html    另外亚马逊AWS提供有java的客户端,我们的sdk是需要依赖这个java客户端代码的,客户端代码按不同的业务分得比较细,这里也给出其中一个,另外的可以在相关页面中找到。https://developer.amazonservices.com.cn/doc/products/products/v20111001/java.html

希望能够帮到大家!该sdk框架已经放到github上,欢迎大家提出意见。

项目地址:https://github.com/zhuzhenke/invoke-limit-api

猜你喜欢

转载自blog.csdn.net/codingtu/article/details/79721191
今日推荐