美文网首页Java 杂谈技能图谱
从一个电商平台的库存同步谈性能优化和方案落地

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

作者: 西召 | 来源:发表于2019-04-16 18:25 被阅读1次

    目录

    • 背景
      • 库存同步相关概念
      • 库存流转过程
    • 方案
      • 问题分析
      • 头脑风暴
      • 确定方案
      • 细化方案
    • 实施
      • 业务精简和标准化
      • 优化消息处理的逻辑
      • 队列操作高性能
      • CPU使用过高
    • 总结

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

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

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

    背景

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

    库存同步相关概念

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

    image

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

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

    • 全量和增量库存

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

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

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

    • 多店铺与分盘

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

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

    有时候一个SKU在多家店铺都有售,iPhone X/太空灰色/256GBXXX苹果平台旗舰店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. 提升硬件配置

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

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

    1. 修改消息处理逻辑

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

    1. 优化消息处理的逻辑

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

    1. 优化全量库存同步

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

    确定方案

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

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

    细化方案

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

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

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

    实施

    业务精简和标准化

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

    1. 全增隔离

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

    1. 剥离日志

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

    1. 剥离新建

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

    由于随着数据量的增加,新建的记录(每天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

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

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

    相关文章

      网友评论

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

        本文链接:https://www.haomeiwen.com/subject/gbhiwqtx.html