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

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

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

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

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

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

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

@eason1874 #54 打错字，是“各区间”，不是“各区别”。补充一下，我说的动态调整包括系统自动调度和运营人员调度，比纯粹的人工干预的系统复杂度要高。

@justrand #33
@Raymon111111 #41

节假期放票应该是各区别有一定预设比例的，根据城市人口等因素，就像会照顾农民工专门给窗口留票一样。动态调整肯定也有。这种东西应该跟红绿灯调度一样，有预案，但运营人员也要跟踪流量作出更优的动态调整。

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

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

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

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

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

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

@woodensail #5 笑死人，成交量跟并发是一回事吗？

12306 高峰期单日 PV 能超过 1500 亿次，平均每秒超过 173 万次，你告诉我有哪个小电商秒杀能承受这个量级？别说余票这种复杂查询，就是你说的秒杀场景，全国能扛得起这个请求数的网站也屈指可数。

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

@mrchi #1 并发太高，后端处理不过来，高峰期前端把一部分请求扔掉了，没到后端所以就没有返回正确状态，高峰期过了，全部请求都能通过，就流畅。

@woodensail #2 你真的没见识，你随便去抓个刷票软件的包你就知道并发多大了，我敢说 12306 春运期间至少有 10 天时间超过双 11 天猫淘宝高峰。

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

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

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

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

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

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

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

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