商品状态升级&重构 - MrLining/project GitHub Wiki
##商品状态
| goods_status | 备注 |
|---|---|
| 0 | 风控下架or删除 |
| 1 | 上架 |
| 2 | 下架 |
| 3 | 删除 |
##方案 业务视图
原文件，下载
##简单逻辑视图
##同步数据说明
-
上架、下架、删除共有的： a、更新商品表其他关联数据（如最后上下架时间等） b、记录商家操作日志（表log、文件log） c、统计上下架信息，更新站外 ----->（取消）
-
上架： a、同步店铺每小时上新数 ------>如果是店铺维度转化的商品维度goods_id,不处理
-
下架： a、删除橱窗关联关系（物理删除调整为逻辑删除） ------>如果是店铺维度转化的商品维度goods_id,不处理 b、通知cpc、pfp（hand：2；status：2） c、取消预售属性，是活动预售的踢出活动
-
删除： a、删除橱窗关联关系（物理删除调整为逻辑删除）------>如果是店铺维度转化的商品维度goods_id,不处理 b、通知cpc、pfp（hand：3；status：3） c、删除库存系统里的库存 ----->（取消） d、删除商品关联分类的关联关系（物理删除，不包含风控） e、更新删除推的主表 ----->（改为使用批量接口，包含风控：风控删除,主站商品显示404（show_type=0）；风控非删除，要恢复推的主表show_type=7；商家删除，不予恢复） f、 通知审核 (不包含风控) g、删除分销商品 (不包含风控) h、删除该商品下的所有sku缓存 i、同步删除sku商品状态--更新 表brd_goods_sku_base和表brd_goods_sku_info (不包含风控) ------>如果是店铺维度转化的商品维度goods_id,不处理 j、取消预售属性，是活动预售的踢出活动
##注意
- 以goods_id为维度的，商品的上下架时间，第一次上架时间要注意控制（包含风控） 以shop_id为维度的只会统一修改商品的最后上下架时间（包括删除）
- 以goods_id为维度的在接口层直接处理缓存，以shop_id为维度的异步处理（需要先查出这个店铺下的商品，分批处理）--注意缓存是跨机房的
- 更新redis goods_status状态的是否需要在接口层直接处理还是异步处理的好？ 答：商品维度直接调用package方法，店铺维度入MQ异步处理（-MQ消耗队列时，根据shop_id查询出店铺下的商品，分批再入MQ处理，然后以商品维度更新）
- 店铺维度，统一先搜索出所有非删除的商品，然后重新入到MQ，变为商品维度处理 （注意是非删除，而不是根据传的goods_status来判定过滤条件；因为商品表商品状态是先被更新的）
- 被风控商品状态为0的只允许风控操作 下架到仓库中；允许商家删除
- 注意下架、删除时，是预售商品的取消预售属性、踢出预售活动: a、预售商品在预售活动开始前下架、删除 同步取消预售属性(brd_goods_presale),不管什么类型的预售，均需要废弃预售， 同步踢出预售活动属性 b、复审通过后——活动开始前,售完自动下架的，踢出活动，废弃预售； 活动中售完下架的 ,保留预售、保留活动（在单宝页可看到定金、尾款的信息） c、活动结束后，这类商品自然不在活动里，不需要踢出，活动结束后，预售标记自动失效。活动结束后商家再上架或预售，就相当于按普通商品设置预售来处理了，与新预售无关。此时上架后的再下架不做踢出预售,踢出活动的动作
goods层接口日志分析（/goods/）
#####接口【/goods/goods_status_update_sys】的响应耗时分析情况 [rd@dfz-nx-01 zxlie]$ sh api-analytics.sh /home/service/nginx/logs/goods.mlservice.access.2016010714.log "/goods/goods_status_update_sys"
|区间(ms)|采样数|总占比|平均耗时(ms)| |:-:|:-:|:-:|:-:| |0
50 | 2 | 0.81% | 11.5 |100 | 244 | 99.18% | 64.45 |
|50
[rd@dfz-nx-01 zxlie]$ sh api-analytics.sh /home/service/nginx/logs/goods.mlservice.access.2016010715.log "/goods/goods_status_update_sys"
|区间(ms)|采样数|总占比|平均耗时(ms)| |:-:|:-:|:-:|:-:| |0
50 | 6 | 2.48% | 11.33 |100 | 235 | 97.51% | 64.42|
|50
[rd@dfz-nx-01 zxlie]$ cat /home/service/nginx/logs/goods.mlservice.access.2016010714.log | grep '/goods/' | awk '{print $6}' | awk '{split($0,request,"?");print request[1]}' | sort | uniq -c | sort -nr
|调用数量|接口路径| |-| |115716| /goods/goods_info| | 28557| /goods/campaign_info| | 3101| /goods/query_goods_sph| | 1407| /goods/query_goods| | 1395| /goods/goods_sale_num_add| | 1291| /goods/goods_status_update| | 1271| /goods/goods_sph_update| | 932| /goods/Query_goods_sph| | 450| /goods/cargo_info| | 407| /goods/goods_save| | 349| /shop/shop_set_and_can_goods_window_info| | 246| /goods/goods_status_update_sys| | 159| /goods/Goods_info| | 138| /goods/goods_status| | 82| /goods/Goods_sph_update| | 77| /shop/shop_update_goods_window| | 37| /goods/Cargo_info| | 11| /goods/perhour_new_goods_num_set| | 11| /cache/clean_goods| | 5| /goods/sku_info|
vmall层接口日志分析（/brdgoods/）
cat /home/service/nginx/logs/mall.mlservice.access.2015121812.log | grep '/brdgoods/' | awk '{print $6}' | awk '{split($0,request,"?");print request[1]}' | sort | uniq -c | sort -nr
|调用数量|接口路径| |-| |319|/brdgoods/Get_goods_info_extend| |223|/brdgoods/batch_set_goods_status| |156|/brdgoods/Batch_set_goods_status|
#####接口【/brdgoods/batch_set_goods_status】的响应耗时分析情况 [rd@dfz-nx-01 zxlie]$ sh api-analytics.sh /home/service/nginx/logs/mall-be.mlservice.access.2016010514.log "/brdgoods/batch_set_goods_status"
|区间(ms)|采样数|总占比|平均耗时(ms)| |:-:|:-:|:-:|:-:| |100
150 | 135 | 59.73% | 133.06 |200 | 47 | 20.79% | 164.1 |
|150
|200+ | 44 | 19.46% | 888 |
[rd@dfz-nx-01 zxlie]$ sh api-analytics.sh /home/service/nginx/logs/mall-be.mlservice.access.2016010515.log "/brdgoods/batch_set_goods_status"
|区间(ms)|采样数|总占比|平均耗时(ms)| |:-:|:-:|:-:|:-:| |100
150 | 144 | 61.27% | 131.47 |200 | 39 | 16.59% | 168.23 |
|150
|200+ | 52 | 22.12% | 907.46 |