本文共 1256 字，大约阅读时间需要 4 分钟。

先给急着用的人：项目地址：

针对调用亚马逊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上面写得也比较清楚。    另外亚马逊AWS提供有java的客户端，我们的sdk是需要依赖这个java客户端代码的，客户端代码按不同的业务分得比较细，这里也给出其中一个，另外的可以在相关页面中找到。

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

项目地址：