我实现过类似的需求，写一个 sh 文件，在 crontab 每分钟运行。

然后 sh 文件的代码就是：一个开始时间戳常量，运行的时候，先计算这个时间戳距离当前的分钟数，然后拿这个分钟数去除以 65，如果能被整除说明隔了 65 分钟，那就运行，不能整除就结束，等下一分钟。

我觉得我们就是做这行的，多从技术角度考虑能提升抢票成功概率。

余票充足但又要排队，应该是查到库存余票是够的，但后端忙不过，就让请求先排队，而且不是严格按余票数量限制排队人数，因为中途可能有人退出。

然后成功入库当然就出票成功了。如果排在比较后面呢，一旦前面大多入库成功了，就算没到你也干脆让你失败了，因为排队人数太多了，预计轮不到你就卖完了。

显示有余票，下单提示没票，返回查看又显示有票。这种情况呢，可能就是被非线上售卖系统（比如窗口售票）抢占了票，但余票数量没有及时更新。

显示余票多余排队人数但还是出票失败，可能也是这个原因，被其他售卖系统抢占了但还没同步数据，或者是错误显示了包括你所选区间的更大区间的余票数量（实际上这些票不在你选的区间出售，考虑这种可能的时候你就可以试试买短乘长，或者买长乘短）。

@pan569673372 #14 两点开始放年 28 的票，现在请求数肯定爆炸了

都是同行，多点理解吧。这么高请求还能用，还不出错票，就已经很难得了。

根本问题还是运力不足，供不应求，就算系统扩容到能处理全球 77 亿人抢票照样还是很多人抢不到票的，扩容意义不大，重点还在提升运力。

可以获得 MAC 地址，但现在新的安卓和苹果都是随机 MAC 了。

几年前还是固定 MAC，百度那些专门做广告的服务商根据这个特效提供了一个服务，叫“到店通知”，就是用户到你店面附近你马上会收到提示。

原理就是：百度 APP 根据 GPS 拿到定位，发现用户到店铺附近了就打开用户手机的 WiFi，然后当客户走到你店铺那一层的时候，他手机的 MAC 地址就会被你的路由扫描到，然后你的软件就会通知你有客户来了，方便你宰客。

先看成都支不支持个人缴纳，不支持再找公司挂靠。

我也觉得 Azure 很难用，但是有难到这个程度吗？

为啥我觉得官方文档说得还挺清晰的。

GET 也有上行流量啊，只是数据比较体积小，不然服务器怎么知道你的请求信息，比如我登录以后 V2EX 的 Request Headers 加起来 1KB 多。

我也是比较习惯说出流量、入流量，说上下行在不同人的理解中可能有歧义。

UV 追踪我懂很多，但我非常反感工贼的工作，我在此表示谴责

一般来说，用 Firefox 的话有 HTTPS 就够了，因为 Firefox 默认不用系统存储的证书，就算系统被福报那种插件安装了他们自签发的根证书，他们也劫持不了。

用其他浏览器的话，HTTPS 也不一定靠谱，因为根证书不可控。（总不能要求管理人员每次访问都看一下证书吧）

最可靠就是双向认证。退而求其次，可以做个浏览器扩展，必须安装扩展才能访问，而扩展负责确认当前连接的 HTTPS 证书正确，避免管理人员用了钓鱼环境而不自知。