从一个电商平台的库存同步谈性能优化和方案落地
目录
- 背景
- 库存同步相关概念
- 库存流转过程
- 方案
- 问题分析
- 头脑风暴
- 确定方案
- 细化方案
- 实施
- 业务精简和标准化
- 优化消息处理的逻辑
- 队列操作高性能
- CPU使用过高
- 总结
下面的案例来自笔者的实际工作经历，涉及到的系统是笔者负责开发和维护的，一个国外的电商平台。
如果你对电商系统有所了解，将有助于你理解下面提到的业务。
如果你没有相关的知识背景，也没有关系，我会尽可能简化地将业务讲给你，并且只要求你理解关键概念即可。
背景
事情的起因是平台的某位高级主管的一封邮件，其中提到商品全量库存的实时性太低，需要各个部门的人协力解决。
库存同步相关概念
先介绍一下电商平台的一些基本概念。
image
库存就是仓库中某个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的全量过来的时候，由于比增量时间要早，将被平台视为作废。
库存流转过程
实际的库存数据流转过程往往不是 「仓库——>平台」 这么短的链路，实际链路总是很长的：
InventoryDataSystemFlow
不同系统的性能不同，实现方式不同，越长的链路时延问题就越严重。
方案
问题分析
想要解决问题，首先要分析问题。作为平台技术负责人，我先统计了平台最近一个月的库存同步时间，大约是150分钟，并且每隔几天会延长几分钟。
然后我统计了最近一段时间全量库存的数据变化量，仅仅10天就增加了5w。
InventoryDataAmount
- 问题定义：
目前看来，从平台角度来讲，随着库存数据量的增加，处理时间不断延长，再加上整个链路很长，造成全量库存数据的实时性很差。
头脑风暴
分析完问题，我立即召开了团队的人员讨论解决方案，经过大家讨论，可以优化的环节是下面几个：
- 提升硬件配置
当你拼命练跑步避免迟到的时候，也许给你一辆车就解决问题了。
部门服务的资源紧张，配置极低。
- 修改消息处理逻辑
目前库存数据拆分粒度很细（分店铺分仓库分门店），加上网络时延，会造成处理时间延长。
- 优化消息处理的逻辑
库存数据由消息中心统一处理，消息中心会处理订单、商品、价格、会员、库存等等多种类型的数据，效率不高。
- 优化全量库存同步
从平台处理数据的代码流程着手优化。
确定方案
对于方案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());
经过上面的优化，目前处理的时间有了大幅度降低:
InventoryDataAmount
队列操作高性能
经过上面的优化，发现每处理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毫秒左右。
image
最终，使用了 管道+多线程，库存消息的处理时间降到了30分钟左右：
InventoryDataAmount.png
关于管道的使用，可以参考这篇文章：Redis管道技术
CPU使用过高
虽然发布到生产以后，处理时间有了大幅度降低，但是经过监控发现，Redis的CPU使用率一直居高不下。
image
对于监听队列的场景，一个简单的做法是当发现队列返回的内容为空的时候，就让线程休眠几秒钟，等队列中累积了一定量数据以后再通过管道去取，这样就既能享受管道带来的高性能，又避免了CPU使用率过高的风险。
//如果消息的内容为空, 则休眠[10]秒钟以后再继续取数据，防止大批量地读取redis造成CPU消耗过高
if (CollectionUtils.isEmpty(messageList)) {
Thread.currentThread().sleep(10 * 1000);
continue;
}
总结
- 方案设计：头脑风暴与可行性评估
- 逻辑精简化 : 剥离不必要的操作
- 流程标准化 : 梳理统一业务的流程
- 线程池实现高性能并发 : Executor Service
- 管道实现高性能队列 : Redis Pipelining
作为一个工程师，要知道自己能力的边界在哪里，利用有限的资源让方案落地。
这里优化的经历，是想让大家对电商相关的业务有所了解，另外对处理问题的解决思路有所借鉴。
