下面的案例来自笔者的实际工作经历，涉及到的系统是笔者负责开发和维护的，一个国外的电商平台。

如果你对电商系统有所了解，将有助于你理解下面提到的业务。

如果你没有相关的知识背景，也没有关系，我会尽可能简化地将业务讲给你，并且只要求你理解关键概念即可。

背景

事情的起因是平台的某位高级主管的一封邮件，其中提到商品全量库存的实时性太低，需要各个部门的人协力解决。

库存同步相关概念

先介绍一下电商平台的一些基本概念。

库存就是仓库中某个SKU(最小库存单元)在仓库中实际有量。

比如某型号灰色8核16G内存的笔记本电脑就是一个SKU，在仓库中这个SKU有100台，那么它的库存量就是100。

全量和增量库存

仓库每天都会把自己实际的库存量统计出来，这就是全量库存，仓库把库存量发送给各个销售终端，这就是全量库存同步。

同时，为了保证库存的实时性，防止超卖(卖出比实际库存量更多的商品，仓库无法发出货品，有可能导致客诉)和仓库有货但客户买不到的情况，仓库会把库存的变化量也实时分发到各个终端，这个库存的变化量就是增量库存。

举例来说，上面的那个SKU笔记本电脑有一台送到摄影棚去拍照了，那么这台就无法销售了，仓库就会推送一个-1的增量库存到销售终端；而如果它收到了消费者的退货，退货入库以后，将会推送一个+1的增量库存。

多店铺与分盘

电商平台一般都会有多个店铺入驻，例如3C这个分类下面，可能有苹果、华为、三星、小米等店铺。

不同店铺的库存是独立的。

有时候一个SKU在多家店铺都有售，iPhone X/太空灰色/256GB 在 XXX苹果平台旗舰店 、XXX手机大世界店、 XX苹果折扣店 就是三个不同的库存记录。

这就是多店铺库存。

作为分销商，它的仓库中放着不同平台、不同品牌的商品。例如上面的手机，在深圳、广州、上海三个地区仓库都有货，并且是分别卖给天猫和京东的，那么它的库存记录就有6条，分别是：

No.	仓库	渠道
1	深圳	天猫
2	深圳	京东
3	广州	天猫
4	广州	京东
5	上海	天猫
6	上海	京东

这就是分盘库存。

库存清点时间和最后更新时间

在实际操作中，为了保证数据的准确性，平台会对库存的时间进行校验。

例如，仓库在凌晨 01:00 清点出某SKU库存量为100，则这条库存记录的库存清点时间就是01:00。

仓库在01:00清点完以后，在02:00收到了一个退货，那么就会推送一个+1的增量到平台。

一般情况下，全量先发出，平台应该先收到全量100，再收到增量+1，最后为101。

但如果由于某个中间环节出了问题，先收到增量+1，在收到全量100，那么最终的库存量将是100。全量库存会直接覆盖平台现在的库存量。

因此，如果有一个最后更新时间，记录是02:00收到的增量，那么当01:00的全量过来的时候，由于比增量时间要早，将被平台视为作废。

库存流转过程

实际的库存数据流转过程往往不是「仓库——>平台」这么短的链路，实际链路总是很长的：

不同系统的性能不同，实现方式不同，越长的链路时延问题就越严重。

方案

问题分析

想要解决问题，首先要分析问题。作为平台技术负责人，我先统计了平台最近一个月的库存同步时间，大约是150分钟，并且每隔几天会延长几分钟。

然后我统计了最近一段时间全量库存的数据变化量，仅仅10天就增加了5w。

问题定义：目前看来，从平台角度来讲，随着库存数据量的增加，处理时间不断延长，再加上整个链路很长，造成全量库存数据的实时性很差。

头脑风暴

分析完问题，我立即召开了团队的人员讨论解决方案，经过大家讨论，可以优化的环节是下面几个：

提升硬件配置

当你拼命练跑步避免迟到的时候，也许给你一辆车就解决问题了。

部门服务的资源紧张，配置极低。

修改消息处理逻辑

目前库存数据拆分粒度很细（分店铺分仓库分门店），加上网络时延，会造成处理时间延长。

优化消息处理的逻辑

库存数据由消息中心统一处理，消息中心会处理订单、商品、价格、会员、库存等等多种类型的数据，效率不高。

优化全量库存同步

从平台处理数据的代码流程着手优化。

确定方案

对于方案1需要金主批钱，方案2需要多个系统修改，这些不好谈；方案3需要改动整体架构，工作量巨大。

对于解决燃眉之急，方案4的可行性最高，改动量和影响范围最小。

细化方案

方案4优化全量库存同步，具体细化为下面三个方面

业务精简和标准化
数据处理高性能
队列操作高性能

下面在实施的时候一一详细说明。

实施

业务精简和标准化

业务精简和标准化分为下面几个方面：

全增隔离

目前全量和增量库存同步使用同一个队列名，通过字段判断是全量还是增量。这样增加了代码的复杂度，而且原子性不好。全量库存单独队列，与增量同步隔离。

剥离日志

修改库存以后需要记录详细变更日志，日志的实时性要求不高，将改操作剥离为单独的队列进行处理。

剥离新建

目前同步库存之前先判断该商品是否存在，如果存在再判断该商品在库存表是否有记录，如果没有则新建记录，有则更新库存。

由于随着数据量的增加，新建的记录(每天1k到3k之间)所占的比重越来越小，因此将新建的操作也单独剥离为一个队列进行处理。

优化消息处理的逻辑

平台为分布式系统，消息处理需要从注册中心调用远程Dubbo服务，首先将数据处理移动到Dubbo服务中完成，避免了频繁调用Dubbo服务，另外使用多线程处理消息，最大限度利用多核心的优势。

关于线程池的使用，可以参考这篇文章：使用ThreadPoolExecutor构造线程池

//构造线程池
private static ExecutorService executorService = new ThreadPoolExecutor(
16,
32,
10L,
TimeUnit.MINUTES,
new LinkedBlockingQueue<Runnable>(
                2048),new ThreadFactoryBuilder()
                     .setNameFormat("BatchSyncFullInventory-Pool-%d").build(),
                     new ThreadPoolExecutor.CallerRunsPolicy());

经过上面的优化，目前处理的时间有了大幅度降低:

队列操作高性能

经过上面的优化，发现每处理2k条消息，处理时间在1s以内，但出队时间接近15s。

因此，下面的优化重点是提高队列的操作性能。

由于Redis频繁的操作，会造成RTT（网络时延）不断延长，可以使用管道来降低RTT。

下面是Spring Data Redis使用管道的方式：

//从队列中循环取出消息, 使用管道, 减少网络传输时间
List<Object> msgList = redisTemplate.executePipelined(new RedisCallback<Object>() {
    @Override
    public Object doInRedis(RedisConnection connection) throws DataAccessException {
        for (int i = 0; i < batchSize; i++) {
            connection.rPop(getQuenueName().getBytes());
        }
        return null;
    }
});

理论上是这样的，需要有实际的数据支撑，因此需要通过做实验来验证方案的效果。

首先，在测试环境对比了三种不同的出队方式的性能，分别是单线程循环出队、多线程循环出队和单线程管道出队。

测试发现使用管道出队两千次，只需要70毫秒左右。

最终，使用了管道+多线程，库存消息的处理时间降到了30分钟左右：

关于管道的使用，可以参考这篇文章：Redis管道技术

CPU使用过高

虽然发布到生产以后，处理时间有了大幅度降低，但是经过监控发现，Redis的CPU使用率一直居高不下。

对于监听队列的场景，一个简单的做法是当发现队列返回的内容为空的时候，就让线程休眠几秒钟，等队列中累积了一定量数据以后再通过管道去取，这样就既能享受管道带来的高性能，又避免了CPU使用率过高的风险。

//如果消息的内容为空, 则休眠[10]秒钟以后再继续取数据，防止大批量地读取redis造成CPU消耗过高
if (CollectionUtils.isEmpty(messageList)) {
    Thread.currentThread().sleep(10 * 1000);
    continue;
}

总结

方案设计：头脑风暴与可行性评估
逻辑精简化 : 剥离不必要的操作
流程标准化 : 梳理统一业务的流程
线程池实现高性能并发 : Executor Service
管道实现高性能队列 : Redis Pipelining

作为一个工程师，要知道自己能力的边界在哪里，利用有限的资源让方案落地。

这里优化的经历，是想让大家对电商相关的业务有所了解，另外对处理问题的解决思路有所借鉴。

从一个电商平台的库存同步谈性能优化和方案落地

背景