40 lines
3.4 KiB
Plaintext
40 lines
3.4 KiB
Plaintext
调度：
|
|
1.目前需要对卡级别做平行数限制，默认有最大值，但是也可以对单独的卡做平行限制，有些好卡，应该多收，特别是 biz 卡，biz 卡的笔数并没有限制，原则上来说，一个健康的卡，应该是没有上限的，一个 biz 卡的额度每天是 20w
|
|
对于个卡的话，我们抓到今天一天的记录，我们可以统计出这个卡目前已经接了多少笔，用 个卡总额减去已经接的笔数，然后取这个余额值和平行的 max，比如这个卡最终每天只能接 3 笔，平行数是 6，那么平行数就是 3
|
|
我们目前的情况下，都是固定的 6 笔，假设其实最多可以收一笔了，那么平行数如果派 6，那么其他 5 笔是一定失败的
|
|
|
|
2.得加上统计每个人回款的平均时间，我们目前是采用大单优先的原则，有时候，可能第一的额度特别大，假设是 5w，第二个1w，容易造成这个后面排队的就一直排不到
|
|
加上等待时间加权，等待越久，权重就会越高，随着时间的推移，权重最终会超过第一，从而拿到单，拿到单
|
|
|
|
回款周期这里，很简单的比方，假设身上就 3000 块，1 小时回款的话，10 个小时，可以做 10 笔，就可以做到 3w 的任务，但是如果 10 小时回款，那么 就只可以做 3000 的任务
|
|
用户没有建立信任的话，他只会拿这一部分钱去做任务，回款慢的话，他会担心投进去的钱会回不来，
|
|
但是如果 1 小时就回来了，他肯定会继续做单，因为他想着我反正回来快，我拿原来的 3000 继续做就可以了，他就愿意去分享
|
|
|
|
3.计算当前可以收的额度，向 bestpay 去获取订单，可以收多少，bestpay 再放多少，自动处理（核心）
|
|
|
|
4.对卡3 笔就风控封禁的情况，我们加自动化处理
|
|
1.vpa 错误，直接给加速冻结
|
|
2.9 比冻结的，自动支付一笔，成功则自动解封，冻结清零
|
|
3.对于自助解封这里，总体问题不大，可以适当加大这个次数，间隔可以缩短为 30 秒
|
|
|
|
5.小额的用 biz 优先去接，用户设置的这个额度区间，是优先派，不是仅限
|
|
|
|
技术方面：
|
|
1.自动补单的时候，如果是掉绑了，自动发rebind 通知，拉活，对于任意需要查单的地方，只要掉绑了，只要触发了，就要自动发，增加拉活几率
|
|
2.增加拉流水限频，防止被风控（已经在测试）
|
|
3.代理模式查看和修改
|
|
|
|
|
|
客户端：
|
|
1.加入打点，分析一下用户的行为，看下到底是哪里跳走了（分析后才可以知道目前转化差的原因）
|
|
2.界面参考 AAPay，最大的问题是我们的任务不太可见，需要滑动才能看到，参考 AAPay，横向滚动就可以，把收益给标出来，奖励的地方，把奖励的数额都要加特殊颜色
|
|
3.消息悬浮球，增加触达率，有消息立马可以知道
|
|
|
|
产品方面：
|
|
1.现在用户慢慢起来了，我们发功能一定要做灰度，比如最开始最 userId 尾号是 0 的灰度，出功能，一定可以有开关，后台随时开关，不行就撤掉，行就加大灰度，前面几次的问题导致用户反馈很多，影响大，有灰度的话
|
|
波及面不大，可以快速回滚，遇到有问题我们后台先关，技术可以游刃有余的去找问题
|
|
|
|
2.IP 代理池，找备案，定期测试备着的 IP 是否 OK
|
|
|
|
|