Splitter 助力解决“大集合参数”这个性能杀手

1. 概览

1.1. 背景

有一次，一个伙伴问我：“MySQL 主键查询那么慢吗，需要几秒才返回？” 对此我也很好奇，从理论上来讲不大可能，主键查询是最快的查询，没有之一。

带着疑问，查看系统日志，大多数请求非常快，基本都在 1、2 ms 内，个别请求可能超过 500ms，甚至有请求超过 3s，整体响应时间非常不均衡。

问题可能出现在哪呢？

1. 发生了类型转换，导致全表扫描？

2. 数据库压力过大，影响全局性能？

查看代码，是一个非常简单的 “select * from t where id in (…)” 语句，其中 id 为 Long 类型，无需进行类型转换。但，稍等 in 了多少，程序中没做限制，直接将参数进行拼接，这可能就是问题所在。

完善日志后，继续观察，果然，in 后的参数可能高达几万，甚至十几万，这就太过分了。随后，对其进行调整，将超限参数进行拆分，提升调用频次，降低入参数量，核心代码如下：

private int maxSize = 1000;
public List<Entity> getByIds(List<Long> ids){
    List<List<Long>> splittedIds = Lists.partition(ids, maxSize);
    List<Entity> entities = Lists.newArrayListWithCapacity(ids.size());
    for (List<Long> ids2Use : splittedIds){
        List<Entity> entities1 = this.dao.getByIds(ids2Use);
        entities.addAll(entities1);
    }
    return entities;
}

自此，伙伴们就 get 到了新技能，主动对大的参数进行拆分处理。随后公司制定了相应规范，对数据库参数进行限制，不允许过大参数的存在。

但，好景不长，一处小小的 bug 险些造成线上事故。

具体代码如下：

private int maxSize = 1000;
public List<Entity> getByIds(List<Long> ids){
    List<List<Long>> splittedIds = Lists.partition(ids, maxSize);
    List<Entity> entities = Lists.newArrayListWithCapacity(ids.size());
    for (List<Long> ids2Use : splittedIds){
        // 在调用方法时，没有使用拆分后的新参数，直接使用拆分前参数
        // 不仅没有解决大参数问题，而且对大参数进行了放大
        // 每遇到一个大参数，内存承压巨大，甚至引起 OOM
        List<Entity> entities1 = this.dao.getByIds(ids);
        entities.addAll(entities1);
    }
    return entities;
}

这种case，很难通过正常测试覆盖；由于过于细节，Code Review 也容易忽略，该怎么从根源上杜绝呢？

1.2. 目标

能力声明式，在不 Coding 的情况下，通过在方法上增加声明式注解，使其具备自动拆分的能力。

目标很明确，拒绝编码，只在方法中增加注解，在方法调用时，使其具备自动拆分和合并的能力。

这就是 splitter 的由来，如果你也遇到过相似问题，可以直接使用。

2. 快速入门

以 spring-boot 项目为例。

2.1. 添加 starter

首先在spring-boot 项目的pom中增加 splitter-starter，坐标如下：

<dependency>
    <groupId>com.geekhalo.lego</groupId>
    <artifactId>lego-starter-splitter</artifactId>
    <version>0.0.1-SNAPSHOT</version>
</dependency>

2.2. 为方法增加 @Split 注解

splitter 提供多种使用方式，可以根据方法签名进行选择。具体如下：

2.2.1. 单集合拆分

这是最简单的方式，其中 @Split 注解：

1. sizePrePartition。每个分区的参数数量；

2. taskPreThread。每个线程执行的任务数；

   </