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) |
测试 | 大概一个星期 |