用脚本帮朋友抢个专家号居然没抢到

[tracymcladdy]

拿到微信 h5 页面的 token ，chrome 控制台拿到请求参数，postman 模拟了几个不用抢的专家号通过了。。

然后写了个循环 100ms 请求一次 7 点放号的专家号，之前一直返回 7 点开抢。然后 7 点直接请求卡了 2 秒返回没号了。。

感觉要不是别人也是脚本，要不就是后台有手脚。。

[sadfQED2]

你都能用脚本，别人也能用呀

[linil]

感觉你要并发执行才能提高成功率吧

[chairuosen]

别人写的 10ms

[gujuji]

这个应该说明有同行

[moult]

1 、先确定服务器与标准北京时间时差，不是所有服务器时间都是准的。
2 、在快到点的时候，每 20ms 开一个线程去发送请求，总共发两三十个请求。直接发，不要关心是否有返回数据，千万不要等上一个请求响应之后再发下一个。

[x86]

厉害的都走协议抢的，你这个太慢了

[gransh]

你的对手有可能是一家百人技术团队的大公司

[tracymcladdy]

@moult 我主要怕把他搞跨了，毕竟 token 有用户信息，参数也有朋友的身份证号...
明天七点用多线程不等返回来试试..

[INW017bzMfgkkYGn]

专业抢票的不会有这么多顾虑

[cruzzz]

还是太礼貌了，嘻嘻。

[BaiLinfeng]

脚本放出来学习下，看看怎么玩的

[rekulas]

抢购其实没程序员想的那么简单,很多时候是经验问题而不是纯粹的技术问题
以前帮人抢购场馆,同一 token 下将并发控制到了极限-刚好不被拦截的地步,为了尽量低延迟将程序部署到腾讯云同机房同网段遍历到了内网地址直接发请求,记得当时单请求响应已经到了 2-5 毫秒级别,我以为稳了,结果还是抢不赢别人
后面复盘,怀疑对方已经将请求优化到了微秒级别,简单来说,假设平台放号是 1700000000.000000 这个时间点, 竞争对手有可能在选择 1699999999.999594 这个时间点发出请求,到达服务器的时候就能刚好抢到一张,而我的请求.000000 才开始发出,已经严重落后了,后面我又进行了小范围的提前请求,也没有成功,这种情况的话就需要长期的测试积累了,通过估算精确到一个极致才能保证领先,因为嫌麻烦就放弃了

当然还有个可能平台直接内定了,这种情况更加不是技术能搞定的..

[jeeyong]

某国内知名大厂的某部门, 大概 5 年前是近 2000 部手机在爬某个公共事业部门网站, 抢某资源.
一堆高级技术人员在维护这套系统...

[spacezip]

正常 给孩子挂号 连挂上几天都试一个套路不让支付 哈哈 研究技术都多余

[moult]

别怕搞垮，你找黄牛他们请求发的更狠。开挂之前跟朋友沟通好就行。
你不要收你朋友钱，不要盈利，就不是黄牛，不会有大问题的。
找到你的时候礼貌性道个歉，再打打感情牌，诉诉苦，疾病困扰，彻夜难眠，求医无门，才选此下策。

[moult]

再写一个脚本，一分钟查询一次剩余号源数据，捡漏那些退号的，尤其是次日就诊的。

[moult]

对了，如果有幸抢到，让你朋友千万不要对外说，更加千万不要给你揽活。
病友追问就说找黄牛的，病友要黄牛联系方式，就说黄牛进去了或者洗手不干了。

[kuanat]

对于你的这个目标，没有什么风控措施的，最理想的方案就是用上你最大的资源，短间隔高并发请求。

对于有风控和频率控制的目标，那就是个技术活了。

[chapiom]

@moult 这个时间差有什么好办法精确获取吗

[v2vip]

我每天抢别的，刚开始三十多毫秒都没抢到，就知道也有人抢，后来调整定时任务执行时间在-30 毫秒范围就开始发起任务，定时任务开始执行-->我的应用系统-->再发起请求，我看过日志都有小几毫秒时差，后来就开了 3 个线程+异步，成功率高了很多。还写了监控每十分钟扫一次我监控中添加的列表。需求都是类似的。请求对方服务器也可能也有时差，所以综合就是前后几十毫秒多线程多次调用，再周期监控是否有放弃的名额。