流量充值项目

作为流量充值的中间商，赚取差价。月流水最高8百万元。

 

项目一分为二，一个是接收客户订单，一个是根据客户订单下单给供应商。我主要负责的是接收客户订单部分。

 

用户鉴权模块

用户申请

校验请求

校验请求数据、token 以及签名

生成 token

根据 app_id, app_secret 找到用户

根据用户 id 生成 token

　　使用 jwt，参数有 user_id, timestamp, secret_key, algorithm

用户根据请求参数生成签名

将请求参数字典按照 key 排序，并拼接:

key1=value1&key2=value2

拼接好后加上 app_key，使用 SHA256 签名 (其中 app_key 不需要放入请求参数)

校验 token

1. 使用 jwt.decode 解码 token 信息，不能解码则拒绝
2. 校验 token 的 user_id 是否有效
3. 校验 token 是否过期

校验签名

将请求的参数按上述规则签名，然后比较签名与传递来的是否相同。

 

创建订单及再次校验

根据手机号等信息获取套餐，没有套餐，返回失败(读库1次)

根据用户传递的参数以及套餐信息创建订单(写库1次)

将订单 id 放入 worker 中处理

返回用户下单成功

 

下单到另一项目

校验用户余额是否足够（余额存放在 redis 中，定期同步到 mysql）

不够

足够

 

获取设定好的供应商

根据流量包大小以及手机供应商、省份获取供应商列表。

下单给另一部分。

 

下单到供应商

下单给供应商，如果失败则重试。重试的顺序是发送过去的供应商列表的顺序。

有结果后，回调给接收客户请求的项目。

 

接收回调

充值成功

更改数据库状态，回调用户

 

充值失败

退款，更改数据库状态，回调用户

 

回调的处理

使用了 grequests 以及 celery 的 -P gevent -c 100

问: 使用 GRequests 的原因

GRequests 使用 Gevent 发送异步 HTTP 请求。通过复用网络 IO 来保持大量连接。

 

-P gevent -c 100

 

 

实现多次回调

使用 celery 的 retry

参考: Celery best practices