低延迟获取多个DynamoDB表指定Item的最优实现方案

有两种成熟的方案可以大幅降低延迟，优化后总耗时可降至单次请求的12~15ms区间，比现有顺序调用的性能提升70%以上。

现有代码慢的原因 #

你当前使用的是同步阻塞调用方式，必须等前一个请求完全返回后才会发起下一个请求，总耗时是4次请求的耗时累加+线程上下文切换开销，所以单次12ms的请求总耗时达到50ms是正常情况。

方案1：异步客户端并行发起请求（更推荐） #

跨表查询单item的场景用异步并发实现灵活性更高，不需要处理批量接口的特殊限制，各语言的AWS SDK都提供了对应的异步客户端，以下是和你现有Java技术栈匹配的实现示例：

// 初始化DynamoDB异步客户端
AsyncDynamoDbClient asyncClient = AsyncDynamoDbClient.create();

// 同时发起4个异步请求，无阻塞
CompletableFuture<GetItemResponse> futureA = asyncClient.getItem(GetItemRequest.builder()
    .tableName("表A")
    .key(Map.of("主键名", AttributeValue.fromS("A")))
    .build());
CompletableFuture<GetItemResponse> futureB = asyncClient.getItem(GetItemRequest.builder()
    .tableName("表B")
    .key(Map.of("主键名", AttributeValue.fromS("B")))
    .build());
CompletableFuture<GetItemResponse> futureC = asyncClient.getItem(GetItemRequest.builder()
    .tableName("表C")
    .key(Map.of("主键名", AttributeValue.fromS("C")))
    .build());
CompletableFuture<GetItemResponse> futureD = asyncClient.getItem(GetItemRequest.builder()
    .tableName("表D")
    .key(Map.of("主键名", AttributeValue.fromS("D")))
    .build());

// 等待所有请求完成，总耗时仅等于最慢的一次请求的耗时
CompletableFuture.allOf(futureA, futureB, futureC, futureD).join();

// 提取结果转换为对应对象
ItemA a = convertToItemA(futureA.get());
ItemB b = convertToItemB(futureB.get());
ItemC c = convertToItemC(futureC.get());
ItemD d = convertToItemD(futureD.get());

其他语言实现逻辑一致：Python可以用aioboto3异步SDK，Go可以用goroutine同时发起4个请求即可。

方案2：使用DynamoDB原生BatchGetItem接口 #

DynamoDB提供的批量读接口支持一次请求查询跨表的多个item，最多支持单次查询100个item，实现示例如下：

BatchGetItemRequest batchRequest = BatchGetItemRequest.builder()
    .requestItems(Map.of(
        "表A", List.of(Key.builder().partitionValue("A").build()),
        "表B", List.of(Key.builder().partitionValue("B").build()),
        "表C", List.of(Key.builder().partitionValue("C").build()),
        "表D", List.of(Key.builder().partitionValue("D").build())
    )).build();

BatchGetItemResponse batchResponse = dynamoDbClient.batchGetItem(batchRequest);
// 从返回结果中按表提取对应item即可

注意：BatchGetItem有两个限制需要额外处理：单请求最多返回16MB数据，遇到表容量不足/部分请求失败时会返回未处理的Key，需要自行实现重试逻辑。

选型建议 #

如果你的场景是固定查询4个不同表的单item，两种方案延迟表现基本一致，优先选异步并行方案，代码逻辑更简单，不需要额外处理批量接口的异常重试。

内容的提问来源于stack exchange，提问作者potbelly