Skip to content

Order查询方案

order迁移到mysql的查询方案

改到mysql之后,因为分库分表的原因,不带时间或者order_id的查询会有问题

前置:当一次查询夸5张表(暂定),需要直接返回错误

类型1

带receive_time的

{
    'customer.receive_begin_time': {'$gte': query_start_time.strftime('%Y-%m-%d %H:%M')},
    'customer.receive_end_time': {'$lte': query_end_time.strftime('%Y-%m-%d %H:%M')},
    ...
}

解决方案1:
从产品了解到,理论上这个收货时间是可以和创建时间直接的间隔打到无限大的。
但是从使用上,发现基本都在1个月之内
所以暂时用收货时间减去31天得到的创建时间来查询

解决方案2:
和下面的解决方式一样,把收货时间加入到二级索引表,先查询得到id,再用id去各张表查询

类型2

带station_id或者customer_id的

{
    'station_id': {'$in': station_ids},
    'customer.uid': str(customer_id),
    '$or': [
        {'settle_way': SettleWay.PAYFIRST.value, 'pay_status': OrderPayStatus.PARTPAY.value},
        {
            'settle_way': SettleWay.GOODSFIRST.value,
            'pay_status': {'$in': [OrderPayStatus.UNPAY.value, OrderPayStatus.PARTPAY.value]},
            'status': {'$ne': OrderStatus.DELETED.value}
        }
    ]
}


解决方案:
设计一张二级索引表。

tbl_order_second_index

id
order_id
station_id
group_id
user_id
shop_id
time_config_id
settle_way
create_time             用于排序获取这个商户最新订单数据
modify_time
以下是需要同步更新的字段
receive_begin_time
receive_end_time
status
pstatus
pay_status

接口设计

order接口
通过二级索引表得到排序好的order_id
URL: 
        /order/order_id/list
Method
    POST
请求
    station_id      O       str 
    group_id            O       str
    user_id             O       str
    shop_id             O   str
    status              O       str
    pstatus             O       str
    pay_status      O       str
    settle_way      O       str
    pay_status      O       str
    time_config_id O    str
    receive_begin_time
    receive_end_time

    limit           O       int     
    offset          O       int     
    count           O       int    
响应

{
  "code": 0,
  "msg": "ok"
  "data": [
    "BDE1201900001",
    "BDE1201900002",
    "BDE1201900003",
    "BDE1201900004",
  ],
  "pagination": {               
        "count": 0  O
    },
}
order接口
新增接口,不能在原来的list接口上面改,否则正在灰度的需要都和一下代码
URL: 
        /order/list_new
Method
    POST
请求
    _id                         O           str 
    create_time         O           str _id和create_time至少传一个
    其他参数以及返回和/order/list接口一致

查询逻辑要调整

1类:receive_time转换成create_time,或者统一从二级索引查询

2类:先查二级索引表得到id,再根据id查具体数据

在调用order list接口的web工程地方,做上面逻辑的统一处理
处理逻辑:
1. 先按照二级索引表查询出所有订单id,返回给web层
2. web层按照order_id和其他过滤条件,去查询订单主表,返回具体信息

其他

先按照上面的方案走,后续如果碰到查询特别慢的接口,需要重构查询逻辑。

时间

计划 时间
二级索引表写入,和查询接口 2天(5-28~5-29)
新的订单查询接口,把mongo查询改到mysql 3天(5-30~6-3)
修改各工程公共调用查询的逻辑 3天(6-4~6-6)
测试 大概一个星期