#78 楼 @code4craft 如果可以严格的时间订票的话，八点开的车，七天前的八点订，下午两点的车，下午两点订。都不应该出现峰值

#72 楼 @cgyqqcgy #73 楼 @luliangshu 可以刷排队，但要卖出去票啊，怎么卖？

不统一放票公平性何以体现？你是鼓励用户今年就订明年春节的票？总有一个开始的时间点吧，比如什么时间可以开始买 15 年春节的票；

每过一天不就是多放一天的票么？需求没有变啊？

@zeeler

比如 9 点放票，一下 1000 万订单，你是要等收集到某个数量级订单后去捏合

为什么会有一个突然的放票呢？一个放票是因为新加了一天的票，另一个放票是因为重新分配以后预存不合用户需求的票。经过捏合后，第二个放票可以很大程度上避免。

还是计算时间，比如 5 分钟后开始捏合？捏合并且去数据库分配票时，肯定需要时间，这个过程中如果又有大量订单进入，是排队等下一次捏合怎么样？

以这个架构，是不需要维护管数据的唯一性的，捏合和订单处理完全不需要同一台机器。你就把捏合的过程看成一个超级后台任务就行。你后面可以再搭一堆机器处理这个后台任务

订单处理就更弱智了，接收用户的请求，给保存下来就行，也完全可以堆机器。

那用户买票基本上是一锤子买卖了，某车次订不上，等捏合处理完后才知道没订上，再换车次时，另外的车次可能都被卖没了。

为什么用户想换车次，因为用户想买到某个地方的票呗，一个车次买不到，换个车次买呗。多么简单的 ifttt 啊，捏合完成可以搞定这个问题。

@zeeler 看运算能力，什么时候能捏合就什么捏合呗

@zeeler 淘宝技术团队，IBM 技术团队又不是足下生风，头顶光环。。。

这个连接火的要死，肯定是看过了，但看过之后，没有感觉到这个解决方案有什么问题。。。如果你感觉那里有问题，可以单个问题的指出来。。。

而不是好像你骂 Matz，你的 ruby 写的像屎一样，然后他问你那里写的像屎，你扔他一本书《48 小时学会写编程语言》，说自己看吧。。。

我和你简单说一下，为什么这个方案可以：

不是因为排队会减少刷票，黄牛现象，这个只是最表层而已，最根本上是因为延迟的捏合不需要维持“数据一致性”，因此具有极佳的横向扩展能力，剩下只要堆硬件就够了。

@doun

排队还有个问题，窗口买票的兄弟怎么算？

上面有个例子讲：

所以这个捏合的过程就类似，我保留广州到杭州 50 张最低票，杭州到济南 50 张最低票，济南到北京 50 张最低票。其它的票都用来做捏合用。如果碰到几个人刚好满程，则捏合买出一张票。如果在领近火车要开了，则开始最大利益捏合。怎么捏合赚钱多，怎么捏合。

这 50 张预留票可以窗口买票，并且我看到好多类似的文章，窗口的票和网络的票本来也会分离的，应该是以一定的比例的发售的。以 12306 来说，以某个比例配票应该也是很简单的。

@hisea

12306 的问题 不是技术能解决的。图样图森破。

我们讨论的问题是在技术能解决的范围内解决 12306 的问题，非技术因素我们不在考虑范围内。

不以事实为凭据的一句“图样图森破”，在别人看来就像“靠工作买不起房子，所以就不用工作了“一样可笑。。。

首先你要想这些类似网络攻击式订票请求为什么会来：

1）刷票软件 2）某一个时间释放预留票。例如预留了 1000 张杭州到北京的票，结果没有人买。所以就拆分成 1000 张杭州到济南的票，济南到北京的票来买。这个甚至没有规律，可能在不同的时间段放票。所以大家就只能一直请求来查询了。。。

如果解决了上面这两个问题，这个网络攻击式订票请求会不会少很多呢？

就拿预约时间来说吧，怎么算，是提交时间还是服务器接收到的时间？车票的数据处理如何做的，是有几个大节点还是集中在某个数据中心？数据如何在高速变化中保持同步？每个不同地区的人订票指令到达时间是否有不同，靠近数据中心的是否更占便宜？数据中心带宽、交换机是否扛得住 (疯狂的订票请求相当于 DDOS 攻击了)？订票后大量的支付请求各银行的支付网关是否能扛得住？可以想象一下，订票指令在开票时间几乎是同时触发的，这并发量不光是服务器能否受得了，当地带宽是否足够也是问题，有些无法访问不一定是服务器出问题了，可能是带宽的问题，运营商也不可能因为每年一两次的订票而大动干戈把带宽重新分配

这些是问题么？肯定是服务器接收到的时间啊，服务器排队么，再说排队给你有点误差怎么了？你知道么？

又不是实时处理订单，所以甚至都不存在数据的一致性的问题，也不用担心超买，我保存到不同的机器上，再慢慢的同步数据，慢慢的处理就好了

各银行的支付网关是否能扛得住关我什么事，这也是 12306 的责任？

还是上面说的，完全这样子去掉黄牛的影响，让大家站在同一起跑线上买票，就是完全可以实现的，如果还有问题完全可以一个一个列出来，我也一个一个看看是不是真正的问题还是幻想中的问题。。。

@zeeler 欢迎指出那里不够。。。

@Peter 嗯，这样子肯定是有效的，不过在一个供小于求的前提下，黄牛仍然有盈利的基础

@shiny 所以我们搞技术的就是尽量给大家一个公平的环境来竞争而已，就像电商的秒杀一样，尽可能的封秒杀软件。

@small_fish__ 黄牛怎么混，他们会一个人骂，肯定会煽动一批不明真相的群众骂。。。做为普通用户来说，我买了票，不让我退，我不骂你。。。哪怕扣我点手续费呢。。。。。

可是扣手续费就又出来黄牛转移成本的问题了。。。

@small_fish__ 那又要变成一个新骂点了。。。。

@shiny 嗯，这个民营铁路应该也是货运的，

我刚刚看了几篇日本铁路民营化的文章，上面也有偏远的路线，因为亏钱民营不想做的问题，所以民营来竞争的也就是些赚钱的事情，但如果你是铁道道的人，你会怎么做？现在铁路部门毕竟也是个公司了，也要从公司的利益出发。

不知道靠出租部分线路建设的铁轨，会不会赚到钱。或者有其它更好的思路。。。不过这个不在我们技术人员考虑的范畴。。。。

双层火车车厢是个好主意。。。。。。不过不知道隧道的高度够不够。。。

@shiny 民营又不是傻子，其它时间亏钱的活谁干，也就和铁道部来竞争他们能赚钱的话了，铁道部又不是傻子，赚钱的话都给你了，我怎么赚钱补贴不赚钱的活。。。毕竟铁道部还是有社会责任的，要不就所有的车票和机票一样市场化就好了，价高者得。。。那估计铁道部被骂的更惨

@ChanceDoor 撒欢的买，看看是不是最后有人买不到票，有人买不到就是动力不足呗。。。。动力不足应该很明显，因为春运的车上都是超级满吧！

@Peter 嗯，这个应该可以，退票扣钱，不过不知道这部分成本会不会转移到用户身上。。。应该是肯定会的。。。。

@shiny SSL 证书这个。。。。。fuck

@ChanceDoor 12306 这多用访问量，估计连联网校验身份证信息都来不及。。。。如果不连网校验，黄牛还是可以用自动生成的身份证号来买票。。。

所以要想想怎么从技术上来杜绝黄牛抢票，卖票，上面的解决方案应该可以解决这个问题

@ChanceDoor 肯定是动力的问题，只是这个动力的问题有没有必要修复而已，目前来看修复的成本太高，这里也不谈论各种区域经济发展不平衡的问题，只谈 改进 12306 这个网站而已。

@luikore +12306

当然上面也不是纯瞎扯蛋。。。

我也是看了好多有关 12306 的文章，总结的我想象中的最佳方案，欢迎更有建设性的意见。。。

@jjzxcc @ChanceDoor

运力问题不是技术能解决的，但是保证用户浪费最少的时间来买火车票，这是他们可以解决的，而不是几天全花在买车票上。

关于用户喜欢不喜欢有一定延迟但不需要再抢的订票方式，这个只有广大的订票的大众最有发言权的，当然我个人是倾向于这样子的。

@bhuztez 然后那个高水平的黄牛也要有 VIP 收费用户了。。。然后其它这个黄牛其实是 12306 的一个子公司么？

@bhuztez 很明显，这是不对的，黄牛更多之后，对黄牛的要求也更多了。你可以把现在每一个买票的人都看成黄牛，结果因为有的黄牛技术高，所以能买到票，有的黄牛技术低买不到。

这样子还是不公平的。因为你可以认识的黄牛水平太低了！XD

@miclle 其实我乐观的认为 12306 还是想解决这个问题的。

现在不是已经退票后，延迟放票了么 ...

这个也不是最佳解决方案啊，因为黄牛有客户后，他们再用真实的身份证开抢。。。还是无解

明显一个人写代码就能解决的问题，要改的不就订票查票的功能

不解决黄牛的问题，明显无解。因为大众和他们的技术水平不在同一起跑线上。

还是抢不过他们，最后找他们买票

不用捏合啊，不保留票，直接放开抢就完了，反正肯定能卖完的

现在的问题是你抢不过黄牛，他们不断的抢票，退票买给其它人

退票就导致不是最佳啊，前面都白搞了

不是所有人买票都是为了退票啊，退票也有退票率的啊。

并且可以参考上面 或者细节上做些优化，例如提供几个火车票的线路备选方案，优先买某个票之类的，约定一段时间内订单有效，超出时间买不到票自动退款，大家用起来应该也都挺爽的，12306 也挨少些骂。。。。

这个也可以解决 前一张票买到了，后一张买不到的问题

其实不用那么多废话，建仓库，写代码，跑起来看看到底能不能撑住不就得了

这个明显不是一个人可以写代码解决的事情，但是这个方案应该是可以行的通的

还不如抢票，这个等于是所有票放一起来一次 constraint solving 求最佳，估计不可行

这个不是一次 constraint solving，举个例子，广州到北京有 1000 张票，中间经过杭州，济南。

因为 12306 要保留一个路段的票，例如济南到北京 200 张，而现实情况是，可能是杭州到北京的票没有那么多人买，反而杭州到济南，济南到北京的人很多。这个捏合就是为了解决这个问题。

所以这个捏合的过程就类似，我保留广州到杭州 50 张最低票，杭州到济南 50 张最低票，济南到北京 50 张最低票。其它的票都用来做捏合用。如果碰到几个人刚好满程，则捏合买出一张票。如果在领近火车要开了，则开始最大利益捏合。怎么捏合赚钱多，怎么捏合。

当然这个过程也可以考虑一些其它的因为，例如上面说的：

其实对于火车票来说捏合订单应该是一个难点，怎么在最大的收益的情况下拉最多的人/或者说拉最多最需要火车票的人（因为近的人还有备选方案，例如汽车，发达地区如上海到北京之间可以选择飞机）

不过这不过是细节了

而且有的人前一张票买到了，后一张买不到也很悲剧

可以退票啊

顶，终于有支持多音字的了！