背景

实习的时候被问过一个问题,为什么 redis 会有 pipline,mysql 会有 batch,这些东西都具有批量操作的共性,是什么原因让我们在处理数据时需要批量操作?

这么说可能有些抽象,举一个和 API 调用有关的例子 🌰:

现有三个服务 service A、service B 和 service C。因业务需要,我们需要在 service A 中调用 service B 获取一组 id,然后根据 id 从 service C 中读取最终内容。然后组织成结果返回前端。由于 service C 只提供了单个 id 查询内容的 API,所以如果我们想要获取批量的信息,最先想到的办法是通过 for 循环多次调用 service C。但是这样的办法是极其不优雅的,接下来我们从以下两个方面来分析。

网络通信

鉴于现在的分布式架构,每个 service 都分布在不同的服务、不同的机器中,所以我们每次调用都要通过 RPC 来实现,这就要求我们不得不构造同等数量的请求来获取数据。这样就会导致了一些效率问题。如下图所示:

所以我们通常会通过在 service C 中提供一个批量查询的接口来解决多次通信的问题。如下图所示 👇

我们知道,并不是每一次网络传输都非常稳定,中途可能会遇到丢包等一系列问题,而用批量查询代替 for 循环单个查询,这样做的好处是,我们可以减少网络通信的次数,一定程度上可以增加整个系统的健壮性。

数据查询

解释完多次 rpc 调用可能造成的网络延迟的问题后,我们再往深一点的地方看。

一般情况下,数据都是存放在数据库中的,所以无论是单个查询还是批量查询,我们最终都是要访问到数据库的。

现假设,我们需要从数据库中查询一个 id 为 123 的用户信息,我们可以用类似下面这样的代码。

long id = 123;
Person p = serviceA.getPersonById(id);

那如果我们需要查询一组 id 为 123、456、789 的用户信息,在没有批量查询接口的情况下,我们可以用 for 循环的方式实现:

long[] ids = {123,456,789};
List<Person> ps=new ArrayList<>();
for(long id : ids){
	ps.add(serviceA.getPersonById(id));
}

这么看虽然符合逻辑,但在数据库查询时,会有一定的性能损耗。

以 MySQL 为例,不论是 MyISAM 存储引擎还是 InnoDB 存储引擎,锁这个概念一直都是贯穿其中的,MyISAM 存储引擎默认是使用表锁,InnoDB 存储引擎默认使用的是行锁,这就意味着,在查询数据时,mysql 会将相关记录“锁起来”,只有当结果查询完毕时才会释放锁。

相较于批量查询只有一次上锁、开锁这种情况,循环里的每次查询都要先拿到锁,然后再释放锁,这个操作自然会更加耗时。这也就是为什么 mysql 会提供 batch 操作的原因。

Redis 中的 pipline

这里我们再来扩展一下,为什么 redis 中会需要 pipline 这样一种实现机制。

pipline,中文翻译为管道,它可以将一组 redis 命令进行封装,一次性将多个命令传输到 redis 服务端,并将数据一次性带回。这样就可以通过一次 RTT (Round Trip Time 往返时间),将多个数据带回,减少了数据传输的 RTT 消耗。如下图所示 👇

redis 的命令执行是微妙级别的,这个速度相对于网络延时是非常小的,因此才有了 redis 的性能瓶颈在网络的说法。并且事实上网络确实已经是 redis 的性能瓶颈之一。

这就更凸显了批量操作的重要性了。

最后

回到这一篇的主题,为什么我们需要批量操作?

虽然现在已经是“云”的时代,在云内部的 rpc 请求几乎不消耗时间,但我们仍然需要意识到构造请求、解析请求、查询数据库等方面的时间和资源消耗。

如果不能批量操作,那么,需要操作的资源越多,操作执行的次数也会越多。这是一个线性上升的模型。就像数据库导入数据,一条两条,手写个 sql 完全没问题。那如果是,100 万+数据呢?一条一条手动导入?这显然是不合理的。

这就是批量操作的现实意义。