目录
- 背景
- 库存同步相关概念
- 库存流转过程
- 方案
- 问题分析
- 头脑风暴
- 确定方案
- 细化方案
- 实施
- 业务精简和标准化
- 优化消息处理的逻辑
- 队列操作高性能
- 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
作为一个工程师,要知道自己能力的边界在哪里,利用有限的资源让方案落地。
这里优化的经历,是想让大家对电商相关的业务有所了解,另外对处理问题的解决思路有所借鉴。
网友评论