线上BUG定位及修复（MQ处理商品信息，实体商品与虚拟品处理逻辑）

背景：

    1.MQ消费处理集群
        负责整个项目中相同/相似逻辑的统一处理，降低冗余代码，提高API响应效率 进行异步处理
    2.业务API 集群
        本次涉及API内主体流程仅有请求参数校验，成功后发送MQ进行处理
    3.定时任务
        扫描数据库内需要更新的数据
    4.涉及表
        预售商品信息表、商品表、预售变更记录、商品信息变更记录

涉及流程：

    电商产品分为：预售、在售、虚拟品等多种状态 
        预售：商品正在生产或送货途中，预计在指定时间会送到待售仓库，由于预期会到达所以提前进行发售，降低仓库饱和度和售卖周期
        在售：已在仓库中存在随时可发货的商品
        虚拟品：类似于礼包，一个虚拟品为一组随意组合的商品的父商品，降低商品售卖时的过多商品信息传递时造成的数据风险

问题场景：

    业务系统调用AP对预售商品数量及状态进行修改，修改完成后，定时任务此时检索到此预售商品现在已开始售卖，并进行数据同步。
    按照正常流程这些都是没问题的，但是却造成了这个商品在定时任务运行后商品数量回退，并且状态没有变更为可售物品。

问题定位：

    1.查询商品变更记录，发现以上调用均有MQ处理，并且都已处理成功。
    2.商品预售数据已变更，但是在售信息还是修改前的数据。
    3.日志查询：由于业务反馈的是操作的API和时间，所以初步仅查询了这个API和消费处理这个API的相关日志，未发现问题 一切正常，然后去查询可能会涉及到此部分数据的相关API和JOB的日志。
                发现相关API都没有对这一条数据的操作，JOB在日志中查询到了这条数据的操作，但时间点不同，JOB对这条数据的同步操作在API调用结束10秒以后。所以当时并未多想。
                查看其他日志也都没有发现这个到底为什么会产生这样的情况，于是将相关日志copy到了一个文件方便后续查找。
                这个时候突然发现如果这个API和job的日志放到一起就发现其中的问题了。按照正常逻辑这个job同步数据的商品数量应该与API设置的一致，但是此时这个数量却是设置前的数量。
                然后继续查看后续具体日志发现两条数据查询数据的商品不一致，然后查看代码进行分析，发现job只有当预售开始时才会发送同步消息，但是才消息处理时却没有开始预售，
                这个是否开始的判断就是时间。由于MQ处理时集中处理，所以在job查询并发送MQ之后，MQ自己还会进行二次查询进行校验，此时MQ服务器中的时间晚于job所以产生了case不一致，将原有数据更新了回来。
    4.结论：查询两台服务器系统时间，发现时间相差1秒，导致判断商品状态不一致。

问题修复：

    MQ不在通过时间进行判断商品是否开始预售，仅通过商品表中的商品类型来进行校验。
    说到这里好像跟虚拟品没有任何关系，但是永远不要小瞧一个老系统中会留给你多少惊喜（坑）。
续：
    当此部分修改并进行问题复现后，发现问题已修复，并且商品表这种重要数据状态肯定不会有问题，于是上线了。
    第二天上午发现突然出现了一个ERROR日志，这个ERROR就是昨天修复的部分产生。
    这个部分仅为预售同步操作没有其他业务逻辑进行干扰，所有校验流程走完进行更新预售数据，这个预售数据居然不存在，返回update=0，逻辑校验失败打印errorr。
    由于虚拟品业务不多很少会出现预售数据，并且虚拟品相关逻辑之前没有接触过，导致这部分逻辑校验不全面。
    本次修改先查询预售信息，预售信息存在并且商品表为预售状态，才进行预售逻辑处理。

总结：

    永远不要以为你做的一定是没问题的，尤其是当你对它/他/她不是完全了解的时候。